Remove gist:decimalValue and replace with gist:numericValue

[uscholdm]

If there is ever a need to connect a number to something else it cannot be a literal, it has to have a URI (it might be called NumberValue). It makes sense to use the same property, decimalValue to point to the number. Currently, this falsely implies that the NumberValue is an instance of gist:Magnitude.

SUGGESTED FIX: remove the domain from gist:decimalValue.

This is a response to a current requirement for Platts, it is not a theoretical exercise. It underscores the caution we need to take when using domain and range.

See also: #172

[uscholdm]

This just bit us again for the IBB Project. Peter and I wanted to reuse decimalValue for things that are not magnitudes. New proposal:

1. deprecate gist:decimalValue which is misleadingly named in the first place (See decimalValue misleadingly suggests that the range would be xsd:decimal #172)
2. add new property called gist:numericalValue with no domain and whose range is the union of all the datatypes that are numbers i.e. (xsd:decimal or xsd:double or xsd:integer or owl:real or ...)
3. as explained in decimalValue misleadingly suggests that the range would be xsd:decimal #172, if there are special cases requiring a specific range, then a new subproperty can be created such as gist:doubleValue, gist:integerValue. This is a bit of an ant-pattern though, better to use SHACL. If we did create a decimalValue then it definitely should not have any domain. To have a separate property for use only with Magnitudes whose value is always double is an even worse anti-pattern (antier pattern?).

[rjyounes]

I like your suggestion. There may be cases where semantics rather than just expected usage requires a specific numeric type, in which case it might be appropriate to mint some of those more specific properties. Hypothetically, hasNumberOfChildren is an integer, for example. We may well not define those in gist but leave them to client ontologies.

[uscholdm]

@rjyounes Yes, exactly!

[rjyounes]

Address with #172 - may be a duplicate.

[Jamie-SA]

Any interest in addressing this for v10 release?

I am wondering because we are about to start baking the current definitions into new shapes for SA internal systems. Would be nice (for us) to make any changes now rather than later.

This might be a bigger change than just removing the range (see #172). There are several terms in gist that have owl:restriction onProperty gist:decimalValue. But that also makes it a good candidate to go into a major release like v10.

[uscholdm]

I'm interested!

[rjyounes]

Let's sort out whether the correct term is "numeric" or "numerical." I'm unclear on the difference, or whether there is a difference. The answers I get from a search do not help to clarify it.

[rjyounes]

@Jamie-SA I've put this into the June project so we can consider it for that release.

[uscholdm]

Let's sort out whether the correct term is "numeric" or "numerical." I'm unclear on the difference, or whether there is a difference. The answers I get from a search do not help to clarify it.

I think numericValue sounds better, the other one sounds al funny (so to speak).

[rjyounes]

DECISION:

1. deprecate gist:decimalValue which is misleadingly named in the first place (See decimalValue misleadingly suggests that the range would be xsd:decimal #172)
2. add new property called gist:numericValue with no domain and whose range is the union of all the datatypes that are numbers i.e. (xsd:decimal or xsd:double or xsd:integer or owl:real or ...)
3. as explained in decimalValue misleadingly suggests that the range would be xsd:decimal #172, if there are special cases requiring a specific range, then a new subproperty can be created such as gist:doubleValue, gist:integerValue. This is a bit of an ant-pattern though, better to use SHACL. If we did create a decimalValue then it definitely should not have any domain. To have a separate property for use only with Magnitudes whose value is always double is an even worse anti-pattern (antier pattern?).