Feeback (2/3) from Thomas Schmidt on dps-meta-prov CSDPR01

[sthagen]

CSDPR01 feedback (second of three parts in total) from Thomas Schmidt ( @tschmidtb51 ) received May 23, 2026 5:09 PM per and relayed by Kelly Culiname:

• Section 5.3 Type Provenance (Record): (→ issue # 96)

  • origin-geography: From the description, I guess source-geography would be a better term as it is in my understanding independent from origin. However, I'm not sure - the description might be misleading. Please clarify whether the geography of the data source is the question here (aka "Where was the data originally stored that was collected?"; source-geography) or of the data collection service (aka "Where were the servers located that collected that data?"; origin-geography - assuming that the data originates from the same entity).

  • previous-date: the phrase "last version of the dataset" is IMHO misleading as it is not fully clear that is talks about the previous version. It is also unclear, how the field should be filled, if it is the initial version.

  • sub-provenance: The count differs from the one in Figure 1. Also, the description does not describe the recursion.

• The sorting of the types makes it hard for the reader, as types are used that are defined in later sections. E.g. Timestamp is used in 5.3 but introduced in 5.4 which does not make sense to me as it is not used there. (→ issue # 97)

• Section 5.4 Type Use (Record): (→ issue # 98)

  • data-risk-reducing: The description implies it is a boolean but the type and cardinality indicates otherwise.

  • storage: The description mixes two things: the actual location and constraints. It is unclear to me, which one was intended. (We can't assume that the actual location is included in the constraints...)

  • 8, 9 and 10 follow the same pattern. However, the description should be improved to clarify, e.g. for 9 that the field must hold the patent number, if there is a patent included. Also, the standard should provide more details about the format: there are multiple authorities around the world that grant patents and I doubt that there is a common numbering scheme. (If there is one, please explicitly mention that - and there might be additional constraints that should be enforced here.)

  • The table does not add up with Figure 1: e.g. processing-excluded and storage-forbidded are not mentioned. Also the privacy-enhancing is not there.

• Section 5.4 Type IntendedAndAcceptableUsages (Record): (→ issue # 99)

  • This type is never referred to.

  • But the IntendedUse type is missing.

  • The descriptions should clarify what the fields describe, e.g. "Provides a set of intended and acceptable use by (Non-) AI systems."

• Section 5.4 Type ProcessingGeography (Record): (→ issue # 100)

  • It is unclear to me, which data takes precedence if same-as-origin and countries are set but contradict.

  • It is unclear to me, why countries are not a unique type.

  • The description for countries is missing.

• Section 5.4 Type StorageGeography (Record): (→ issue # 101)

  • It is unclear to me, which data takes precedence if same.-as processing and countries are set but contradict.

  • It is unclear to me, why countries are not a unique type.

  • The description for countries is missing.

• Section 5.4 Type Geography (Record): (→ issue # 101)

  • The type "geo:CountryName" is not defined.

  • The type "geo:StateName" is not defined.

  • The descriptions are missing

• Section 5.4 Type UID (Choice(anyOf)): (→ issue # 103)

  • It is unclear to me, what the type Binary is.

  • The description is not helpful here. Also no recommendation regarding the type of UUID are made.

• Section 5.4 Type DataRiskReducingTool (Record): (→ issue # 104)

  • The descriptions are mostly missing. Therefore, it remains unclear what the intended information is.

• Section 5.4 Type ToolID (String): (→ issue # 105)

  • A classic identification of a tool needs at least 'vendor, product_name, product_version`. Other identifiers as upid/CPE/purls/SBOM_urls etc. might be helpful.

  • The description is missing.

• Section 5.4 Type Confidentiality (Record): (→ issue # 106)

  • The descriptions are missing.

  • It is unclear to me, what the purpose of the ToolID is here.

• Section 5.4 Type Timestamp (DateTime): (→ issue # 107)

  • The description is missing.

  • Please state the standard the DateTime definition should be extracted from (e.g. RFC3339) and which rules apply.

• Section 5.4 Type URL (String): (→ issue # 108)

  • Is the intention to allow all URIs that locate a resource, e.g. also data-URLs?

  • The double type of String /uri is unclear to me.

• Section 5.4 Type Method (Enumerated): (→ issue # 109)

  • The descriptions are missing.

• Section 5.4 Type ModalityFormat (Enumerated): (→ issue # 110)

  • The descriptions are missing.
  • This type seems to be never used. It could be used as MediaType in section 5.3.
  • I wonder whether it makes sense to use a fixed list or compare it against the latest Media Type definitions.

• Section 5.4 Type ConfidentialityClassification (Enumerated): (→ issue # 111)

  • It looks like the definitions used here are unclear - especially, what counts into that? E.g. SPI is potentially something different in US vs. EU.

• Section 5.4 Type DataTechnology (Enumerated): (→ issue # 112)

  • The descriptions are missing.

• Section 5.4 Type License (Enumerated): (→ issue # 113)

  • This looks still a lot of individual work as it seems to be unstructured data.
  • At least for those, that are somewhere documented (e.g. SPDX/AboutCode list) , the official (as in SPDX 3.0.1) license expression should be stated.Section

• Section 5.4 Type NonAIUse (Enumerated): (→ issue # 114)

  • The descriptions are missing.

• Section 5.4 Type AIUse (Enumerated): (→ issue # 115)

  • The descriptions are missing.