problems in the modeling of Dimension, specific measure props, Measure

[VladimirAlexiev]

• untp-core:Dimension is currently a parasitic node because it has no payload except some outgoing relations: ProductPassport - dimension - Dimension - (weight, height, etc) - Measure
• The modeling of Measure is doubtful because its specific incoming props (weight, height, etc) can be contradicted by unit. There's nothing stopping data from looking like this:

  <passport/1> a ProductPassport; height <passport/1/height>.
  <passport/1/height> a Measure; value 1; unit <unitOfMeasure#kilogram>.

  IMHO it's better to roll the specific prop (called quantityKind in QUDT) into Measure, eg:

  <passport/1> a ProductPassport; measure <passport/1/height>.
  <passport/1/height> a Measure; quantityKind <quantityKind/height>; value 1; unit <unitOfMeasure#meter>.

  It's still possible to have a contradiction in quantityKind and unit but:

• the contradiction is now in the same node so easier to detect
• UoM ontologies like QUDT have the allowed combinations quantityKind-units. (UNCEFACT Rec20 is not an ontology because it doesn't have these combinations, and the dimensionVector for each quantityKind)

[onthebreeze]

It's true that, under the schema, an issuer could say "length":{"value":10,"unit":"KGM"} which would technically valid (because KGM is a valid Rec20 code) but semantically nonsense because you obviously don't measure length in kilograms. But whilst I agree, I also dont think it's UNTP's job to define an entire ontology that defines which units can be used for what kind of measure. This argument applies everywhere. For example an issuer might define an address with country code "NZ" and state "NSW" which would also be technically valid but semantically wrong because New South Wales in in Australia not New Zealand. Where do we stop?

I think we have to assume that issuers will put sensible data within reason.

[VladimirAlexiev]

I'm not asking you to make a UoM ontology but to use one properly.

• If you declare distinct props weight, height etc then use a straight number, and add the unit in the prop, eg:

  dpp:weight a owl:DatatypeProperty; dpp:unit "KGM".

• If you use a Measure node then have only one incoming prop, and put all measure details inside the node
  • The details include kind and UoM, but can also add qualifiers like gross vs net; nominal vs actual; wet vs dry, etc
  • I like this approach better, since the few quantity kinds you've captured as distinct props are not enough (so you need the generic measure prop): then why duplicate it partially by using the specific props?

New South Wales in in Australia not New Zealand

Well then, don't use text fields like countryCode, stateCode. Use a class Place and a world gazetteer like Geonames.