General review of document as EN candidate

[mcdittmar]

I'm looking at this in the context of being "something attached to recommendation which represents some agreed upon solution for some function".

Doc: DataOrigin v1.2 - 2025-10-31

Appendix:

• says 'specifies a set of metadata items that define basic provenance information'. The items are all pulled from existing standards.. ( VOResource, DataCite, etc ), so this document is really all about the “representation in documents produced by Virtual Observatory (VO) services”.
  • perhaps ‘identifies’ would be a better term than 'specifies' which is closer to 'defines' in my interpretation.

Section 3:

• references VOTable 1.4 (2019).. the current REC is 1.5 (2025)
• HiPS reference (2017) say 'is a more recent protocol' but has an older date than many of the cited standards (from version updates).

Section 3.3:

• DALI, has ‘bespoke names for INFO elements used to convey Data Origin-type metadata', and states that this document is extending this mechanism.
  • this is good, but since the serialization is the core of this document, Section 5 should be more specific about constructing the INFO item.

Section 5:

• Table 2 drops down to 'Appendix A', which seems a bit too far.
• As the core of this document, the description of how to create the ITEM node is pretty light.
  • Perhaps users are expected to support any form of the ITEM node that VOTable defines.
    • That is fine, but I think at least a pointer to that VOTable section is in order
    • and maybe specific instructions that the 'key' shown in Tables 1,2 is to populate the 'name' attribute of ITEM
    • and the recommendation to use the Description in the ITEM node body
    • there are several other attributes to ITEM not used in the examples.. are they allowed in this context?
• Structure
  • The paragraph about the description, "As a service to human readers..." should be just after the basic serialization paragraph since it relates to constructing the node.
  • The multiplicity paragraph is good, and should follow this since it is relevant to implementors.
  • The paragraph regarding 'Complex queries' is about something that is in-the-works / not supported, so probably does not belong in a normative section.

Hierarchy:

• I feel like there is something missing about this... perhaps it doesn't come into play with the existing use cases?
  • The ITEM nodes are flat, and Section 5 says multiplicities are not constrained.
    • do they need to be clumped? or can they be randomly distributed? (e.g. if there are multiple 'contacts')
  • Section 3.2 talks about a Provenance Graph, and it feels like there can be multiple groupings of metadata involved.. yet there is no mechanism for identifying the start/stop of a bundle. Especially with open multiplicities it will be VERY difficult to associate the items which belong together.