critiques of DPP ontology

[VladimirAlexiev]

https://jargon.sh/user/unece/DigitalProductPassport/v/working/artefacts/jsonld/render.jsonld vs https://untp-ontologies.s3.ap-southeast-2.amazonaws.com/dpp.jsonld:

• @ashleythedeveloper which is the authoritative one?
• @nissimsan is the idea to map to existing ontologies as in traceability CG, or to use own classes and props?

While these are workable, here are some suggested fixes:

• [ ] Fix the namespace as described in #67

• [ ] Party is nested in the DPP namespace (DigitalProductPassport:Party). But presumably Party is used in many other parts of the UNTP so should be at top level

• [ ] Don't use plural prop names (eg identifiers), always use singular, even for multi-valued props

• [ ] Render prop descriptions in markdown rather than preformatted. Currently https://uncefact.github.io/spec-untp/docs/specification/DigitalProductPassport#unitofmeasure has

  Code values for this table can be found here:
  https://vocabulary.uncefact.org/UnitMeasureCode

  but it would be more useful as

  Code values for this table can be found here: https://vocabulary.uncefact.org/UnitMeasureCode

• [ ] There is a conflict between https://uncefact.github.io/spec-untp/docs/specification/DigitalProductPassport#identifier (only for Party) and https://uncefact.github.io/spec-untp/docs/specification/Identifiers (the description says it can be used for anything, but there is no data model)

• [ ] unlike schema:domain,rangeIncludes, these cannot be multi-valued: rdfs:domain,range. Is this the reason why they are missing for some of the props?

• [ ] dpp:Classification has scheme (anyURI), classifierValue (notation), classifierName (string), classifierURL (anyURI). It doesn't allow concept hierarchies and doesn't describe the "scheme" explicitly (eg who made it, when was it published, what is its topic). Consider using SKOS and don't be afraid to make an own URL for the ConceptScheme. Link to the external classification using dct:source (at both ConceptScheme and Concept level).

• [ ] Dimension is a parasitic class that only has incoming link dpp:dimensions and outgoing links height, width, etc. It's unclear:

  • Why not use height, width, etc directly on Product
  • Whether a Product should have multiple Dimension (thus multiple parasitic nodes) or just one

• [ ] There is confusion between Metric (has value, accuracy, unitOfMeasure) vs Measure (relates to Product)

• [ ] Using specific props like height, width etc is not extensible (what if it's very important to track eg "thickness" or "pattern grid distance" for a product?) and allows inconsistencies (because there's no relation between the prop and the allowed units of measure; consider this):

  <product/1> dimensions <product/1/dimension>.
  <product/1/dimension> a Dimension; height <product/1/dimension/height>.
  <product/1/dimension/height> a Measure; value 12.3, unitOfMeasure "KGM".

  I think you should consider SOSA/SSN measurement representation, and QUDT for quantityKind vs unit.