Handling non-numeric quantity values - feedback requested by QUDT.org

[steveraysteveray]

QUDT.org has been requested to provide more support for qudt:Quantity instances that have non-numeric values, such as enumerations, either ordinal or non-ordinal. While the QUDT ontology set does not maintain vocabularies of qudt:Quantity (that is up to the user's application), we do want to provide the needed relations.

The current situation is that:

1. qudt:value is defined as an owl:DatatypeProperty without any constraint on the type of value.
2. qudt:numericValue is defined as an owl:DatatypeProperty with a range of dtype:numericUnion.

We are considering the following adjustments, but would like input from the user community:

1. Constrain the range of qudt:value to instances of qudt:valueUnion (allows both numeric and non-numeric values)
2. Define qudt:nonNumericValue as an owl:DatatypeProperty with a range of a newly defined qudt:NonNumericUnion
3. Define qudt:NonNumericUnion with a range of (qudt:valueUnion minus dtype:numericUnion)

Variation 1: 1. Broaden qudt:value to be an rdf:Property to allow both literals or objects (such as instances of a defined enumeration class)

These three changes would allow applications to use any of the following relations for values of qudt:Quantity:

1. qudt:value for any kind of value (backward compatible with existing uses)
2. qudt:numericValue for numbers
3. qudt:nonNumericValue for textual and enumerated values

Please comment on the above.

We realize some of the range description names are not consistent, but we are concerned about breaking your existing implementations:

• qudt:valueUnion would be named qudt:ValueUnion
• dtype:numericUnion would be replaced with qudt:NumericUnion

Your thoughts on making these two changes are also solicited.

[stuchalk]

I think this is a great idea, although I don't have any implementations that this would break (so maybe I am not thinking about this deeply enough as a result). I especially like this in the context of better support for scales.

[MichelBohms]

I can see three types of value (compare rdfs:Resource): lexical-numeric (rdfs:Literal) lexical-nonnumeric (rdfs:Literal) reference/uri

so, maybe there could be 3 subtypes of the generic qudt:value than... (unless qudt:value already has the semantics of lexical...)

[dr-shorthair]

Hmm. I'm concerned that this is a rather large expansion of scope. Quantities and Units are convertible using arithmetic procedures using information available in QUDT (possibly supplemented by molecular weight information for mol units). As soon as we move into nominal scales then that clean goal and scope evaporates.

If you do head in this direction, I strongly suggest that it be implemented in a separate service, and not embedded in the QUDT databases.

[MichelBohms]

I see your point, maybe we can just better clarify existing usage:

• is qudt:numericValue a subproperty of the generic qudt:value?
• how does qudt:value differ from the existing rdf:value?
• will we use the generic one whenever we need something beyond numeric (reference or nonNumeric)? more like that....

[nicholascar]

I agree with the point from @dr-shorthair that caution is needed for a scope change, however I suggest that this particular change can be made, pending a resolution to the points about qudt:value range values etc., and that QUDT provides the properties as described but indicates that calculates with this nominal scale values are, and should remain, out of scope for core QUDT: QUDT sub-communities should be encouraged to make non-core handing mechanics, if they wish.

My reasoning is that if you don't supply direction here, people will do (and do do) all kinds of incompatible things. QUDT can sensibly supply the properties so things are "handed off" to nominal scales in the same way every time but the particular calculation mechanisms for every nominal scale are/can be a lot of work.

It is extremely valuable to have standard metrology properties for ontology work, even if all the calculation elements are not/can not be supplied. GeoSPARQL benefits greatly for following the QUDT patterns for scalar spatial values even though most GeoSPARQL users are unlikely to use QUDT-supported numerical calculations (they calculate area etc in spatial tooling!) since the way scalar spatial values are referred to by Features is now common with all other QUDT-using systems and thus well known and easily understood.

[jhodgesatmb]

It should be noted that what is being discussed is not an expansion of scope in QUDT but a clarification and an associated nomenclature. As Steve noted, at the present time a quantity value is not constrained to be numeric and this is ambiguous.

Unit conversion multipliers 'are' numeric.

QUDT was never intended to be limited to vocabulary lookup and I have always bristled at the implication that it is. When I was at Siemens the vast majority of use cases we applied QUDT to were engineering contexts where we used both numeric and nonnumeric quantity values and nonscalar datatypes that were defined in the early days of QUDT.

The clarification being discussed does not impact unit conversion but does provide a path for those who need to describe quantity values using nonumerics, such as enumerations. In some respects the best examples to use do not even have numeric values. I suppose that numeric equivalents could be applied as is often the case with enumerations, but it is sometimes the case that nonnumeric values don't take the form of enumerations.

Jack

Sent from my iPad

On Jul 4, 2022, at 9:10 PM, Simon Cox @.***> wrote:

 Hmm. I'm concerned that this is a rather large expansion of scope. Quantities and Units are convertible using arithmetic procedures using information available in QUDT (possibly supplemented by molecular weight information for mol units). As soon as we move into nominal scales then that clean goal and scope evaporates.

If you do head in this direction, I strongly suggest that it be implemented in a separate service, and not embedded in the QUDT databases.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[steveraysteveray]

What we are currently proposing, after this discussion, is:

(I'm not showing all the properties, for clarity.)

qudt:value
  a rdf:Property ;
  dcterms:description "A property to relate an observable thing with a value that can be of any simple XSD type" ;
  rdfs:isDefinedBy <http://qudt.org/2.1/schema/qudt> ;
  rdfs:label "value" ;
.
qudt:numericValue
  a owl:DatatypeProperty ;
  rdfs:label "numeric value" ;
  rdfs:range qudt:NumericUnion ;
.
qudt:enumeratedValue
  rdf:type owl:ObjectProperty ;
  rdfs:label "enumerated value" ;
  rdfs:range qudt:EnumeratedValue ;
.

...with the ranges:

qudt:NumericUnion
  a owl:Class ;
  rdfs:label "Numeric union" ;
  rdfs:subClassOf qudt:Concept ;
  rdfs:subClassOf dtype:numericUnion ;
.
qudt:EnumeratedValue
  rdf:type owl:Class ;
  rdfs:subClassOf qudt:Datatype ;
  rdfs:subClassOf dtype:EnumeratedValue ;
.

Bottom line, we want to allow users to specify either "numbers" (NumericUnion) via the numericValue relation, or instances of a defined enumeration (EnumeratedValue) via the enermeratedValue relation. For those who want to be less disciplined, they can use qudt:value which is just an alternative to rdf:value.

[stuchalk]

This covers the bases for me. +1

[steveraysteveray]

This has been addressed in Release 2.1.20, described here.