Modeling patterns and/or gist updates for a magnitude range

[rjyounes]

We recommend the following two patterns for modeling a range of magnitudes. Note that the class gist:Magnitude is not used, because a magnitude represents an exact value, whereas a range is a specification.

Pattern 1

:_Specification_1 
    a gist:Specification ; 
    gist:hasAspect gistd:_Aspect_length ;
    gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;
    :valueGreaterThan 40 ;
    :valueLessThan 50 ;
    .

To implement this model, define in your own namespace the predicates you need for greater than, less than, greater than or equal to, less than or equal to, equal to. Note that gist:numericValue, which is used for actual amounts, should not be the superproperty of these properties, else a reasoner will generate the following false inferences from the triples above:

:_Specification_1 
   gist:numericValue 40 ;
   gist:numericValue 50 ;
.

While gist:numericValue is not formally defined as a functional property, it is typically used that way, and therefore these inferences would likely wreak havoc with your data.

You might consider defining a subclass of gist:Specification such as :SpecEntry, roughly as follows:

:SpecEntry a owl:Class ;
    owl:equivalentClass [
        a owl:Class ;
        owl:intersectionOf (
            gist:Specification ;
            [
                a owl:Restriction ;
                owl:onProperty gist:hasAspect ;
                owl:someValuesFrom gist:Aspect ;
            ]
            [
                a owl:Restriction ;
                owl:onProperty gist:hasUnitOfMeasure ;
                owl:someValuesFrom gist:UnitOfMeasure ;
            ]
            # If you have defined a superproperty above:
            [
                a owl:Restriction ;
                owl:onProperty :specifiedValue ;
                owl:someValuesFrom rdfs:Literal ; # or see the range of gist:numericValue
            ]
        )
    ] ;
.

Pattern 2

ex:_Specification_1 # or SpecEntry
   a gist:Specification ; # or SpecEntry  
   ops:hasValueGreaterThan :mag_1 ;
   ops:hasValueLessThan :mag_2 ;
.

:mag_1 a gist:Magnitude ;
   gist:hasAspect gistd:_Aspect_length ;
   gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;
   gist:numericValue 40 ;
.

:mag_1 a gist:Magnitude ;
   gist:hasAspect gistd:_Aspect_length ;
   gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;
   gist:numericValue 50 ;
.

This pattern uses predicates defined in Semantic Arts' Operators Ontology. Note that this ontology is entirely independent of gist and does not import it.

Pros and Cons

• Pattern 1
  • Pro: Aspect and unit of measure are attributed to the specification and thus common to both amounts.
  • Con: Requires entirely new predicates defined in your namespace. (The Operators Ontology predicates are object properties and thus cannot be used here.)
• Pattern 2
  • Con: Allows the aspect and unit of measure to differ between the two amounts.
  • Pro: Predicates are already defined in an Operators Ontology that can be imported. No additions to extension ontologies are required.

Introducing the SpecEntry class is already under consideration for gist 13.1.0. (Note that this issue is outdated, using old predicate names and the gist 12 and earlier definition of Magnitude. It would be updated to align with the current definition.)

We will also consider introducing into gist the datatype properties used in pattern 1. In this case we would consider renaming gist:numericValue to gist:valueEqualTo so that numericValue can become the superproperty. We would consider this a major change, despite no formal change to the definition, due to the shift in the meaning in the skos:definition and the use of the property in current implementations.

Pattern 2 is supported by gist out of the box along with the Operators Ontology.

[MichaelSullivanArchitect]

[like] Michael J. Sullivan reacted to your message:

…

________________________________ From: Rebecca Younes ***@***.***> Sent: Thursday, August 8, 2024 6:58:50 PM To: semanticarts/gist ***@***.***> Cc: Subscribed ***@***.***> Subject: [External] : [semanticarts/gist] Modeling patterns and/or gist updates for a magnitude range (Issue #1145) We recommend the following two patterns for modeling a range of magnitudes. Note that the class gist:Magnitude is not used, because a magnitude represents an exact value, whereas a range is a specification. Pattern 1 :_Specification_1 a gist:Specification ; gist:hasAspect gistd:_Aspect_length ; gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ; :valueGreaterThan 40 ; :valueLessThan 50 ; . To implement this model, define in your own namespace the predicates you need for greater than, less than, greater than or equal to, less than or equal to, equal to. Note that gist:numericValue, which is used for actual amounts, should not be the superproperty of these properties, else a reasoner will generate the following false inferences: :_Specification_1 gist:numericValue 40 ; gist:numericValue 50 ; . You might consider defining a subclass of gist:Specification such as :SpecEntry, roughly as follows: :SpecEntry a owl:Class ; owl:equivalentClass [ a owl:Class ; owl:intersectionOf ( gist:Specification ; [ a owl:Restriction ; owl:onProperty gist:hasAspect ; owl:someValuesFrom gist:Aspect ; ] [ a owl:Restriction ; owl:onProperty gist:hasUnitOfMeasure ; owl:someValuesFrom gist:UnitOfMeasure ; ] # If you have defined a superproperty above: [ a owl:Restriction ; owl:onProperty :specifiedValue ; owl:someValuesFrom rdfs:Literal ; ] ) ] ; . Pattern 2 ex:_Specification_1 # or SpecEntry a gist:Specification ; # or SpecEntry ops:hasValueGreaterThan :mag_1 ; ops:hasValueLessThan :mag_2 ; . :mag_1 a gist:Magnitude ; gist:hasAspect gistd:_Aspect_length ; gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ; gist:numericValue 40 ; . :mag_1 a gist:Magnitude ; gist:hasAspect gistd:_Aspect_length ; gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ; gist:numericValue 50 ; . This pattern uses predicates defined in Semantic Arts' Operators Ontology<https://urldefense.com/v3/__https://github.com/semanticarts/operators-ontology/tree/develop__;!!ACWV5N9M2RV99hQ!KBc0skSrSx6lLiFAFhg1ZOBaXj1BwLEcp0-cpGkBBfGViMcshY8JkglaalA0LlGVdlpCKEnPPcNJVR0uPEDZTObcW_n4Zs4$>. Note that this ontology is entirely independent of gist and does not import it. Pros and Cons * Pattern 1 * Pro: Aspect and unit of measure are attributed to the specification and thus common to both amounts. * Con: Requires entirely new predicates defined in your namespace. (The Operators Ontology predicates are object properties and thus cannot be used here.) * Pattern 2 * Con: Allows the aspect and unit of measure to differ between the two amounts. * Pro: Predicates are already defined in an Operators Ontology that can be imported. Introducing the SpecEntry class is already under consideration<https://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/527__;!!ACWV5N9M2RV99hQ!KBc0skSrSx6lLiFAFhg1ZOBaXj1BwLEcp0-cpGkBBfGViMcshY8JkglaalA0LlGVdlpCKEnPPcNJVR0uPEDZTObcqCiEc1Q$> for gist 13.1.0. (Note that this issue is outdated, using old predicate names and the gist 12 and earlier definition of Magnitude. It would be updated to align with the current definition.) We will also consider introducing into gist the datatype properties used in pattern 1. Pattern 2 is supported by gist out of the box along with the Operators Ontology. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145__;!!ACWV5N9M2RV99hQ!KBc0skSrSx6lLiFAFhg1ZOBaXj1BwLEcp0-cpGkBBfGViMcshY8JkglaalA0LlGVdlpCKEnPPcNJVR0uPEDZTObcy_tRBCQ$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTHY4NS4X5LR4X3KLFZTZQO5WVAVCNFSM6AAAAABMHCHLGOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ2TMNBTHAZTGMI__;!!ACWV5N9M2RV99hQ!KBc0skSrSx6lLiFAFhg1ZOBaXj1BwLEcp0-cpGkBBfGViMcshY8JkglaalA0LlGVdlpCKEnPPcNJVR0uPEDZTObc2YxWIH8$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[philblackwood]

As I suggested in the meeting, we could use numericValue, maxNumericValue, and minNumericValue to economize on the number of concepts used.

valueGreaterThanOrEqualTo 40 would be the same as minNumericValue 40.

Also, do we want a more specific name for the class of things that represent a required range of magnitudes, such as SpecifiedMagnitude?

[rjyounes]

Also, do we want a more specific name for the class of things that represent a required range of magnitudes, such as SpecifiedMagnitude?

Yes, @Jamie-SA proposed this as well: "I would probably give a different name to the class that you defined as :SpecEntry because it currently only works for a Specification of numeric values. There are other specifications that are not related to Magnitudes (such as types of allowed metal alloys) that I would still consider a SpecEntry. So maybe :MeasurementSpecEntry or something else that qualifies it compared to other possible sub-classes."

And in fact, the original definition of SpecEntry from Michael does include category values as well as magnitudes. MagnitudeSpecification is another option.

As I suggested in the meeting, we could use numericValue, maxNumericValue, and minNumericValue to economize on the number of concepts used. valueGreaterThanOrEqualTo 40 would be the same as minNumericValue 40.

What about valueGreaterThan 40? We don't know the min value unless we know the precision; e.g., with precision of 1 the min value is 41, with precision of 0.1 the min value is 40.1. Perhaps specifications should always have precision, though.

Is there a concern about asymmetry in modeling a range specification and a single value that's part of a specification? For example, a product specification might specify a length of exactly 40 inches and a width between 20 and 30 inches (not a great example, but you get the idea). In the first case we have a magnitude, in the second a magnitude specification. I'm not claiming there's a problem with that, just raising the question.

[philblackwood]

Let's consider what queries should look like.

If a Thing has a magnitude and a specification for magnitude, a SPARQL ASK query could pull the data about both and check for conformance to the spec with a few statements like:

filter(?numericValue <= ?maxAcceptableValue)
filter(?numericValue >= ?minAcceptableValue)
filter(?numericValue = ?requiredValue)

A slight refinement is needed to adjust for different units of measure (multiple values by conversion factors, or in the case of temperatures convert to Kelvin using conversionOffset and conversionFactor).

maxAcceptableValue, etc. also make sense for any comparable non-numeric values like release versions, alphas, etc.

Sketching out the query, it seemed to make sense to have a property hasRequiredMagnitude. It is somewhat specialized, but Magnitudes are a high-value, high-volume use case for any Enterprise.

[rjyounes]

Sketching out the query, it seemed to make sense to have a property hasRequiredMagnitude. It is somewhat specialized, but Magnitudes are a high-value, high-volume use case for any Enterprise.

Maybe more generally requires? I've used that often.

[uscholdm]

As I suggested in the meeting, we could use numericValue, maxNumericValue, and minNumericValue to economize on the number of concepts used.

valueGreaterThanOrEqualTo 40 would be the same as minNumericValue 40.

Also, do we want a more specific name for the class of things that represent a required range of magnitudes, such as SpecifiedMagnitude?

Its true than min is the same as greater or equal to and max means less or equal to.
Just different names, not more economy. What do you propose to call the properties for strictly greater than and strictly less than that users may need?

[MichaelSullivanArchitect]

FWIW, we will probably be leaning towards pattern #2 as it aligns nicely with our current (GIST11) implementation -- our pipeline will validate the shape of the data so having the possibility of conflicting _Aspects and _UOMs is a non-issue.

[rjyounes]

Jamie: Pattern 2 allows specifying hasAccuracy on each value.
Michael: the operators ontology includes variance

Perhaps we don't need accuracy on the specification. Instead of 40-50 inches plus or minus 1/16 inch you would say 39 15/16 - 50 1/16 inches.

Jamie: add a note saying that if needed you could use the operators ontology with 2 magnitudes.

Do we want to introduce the predicates into gist, or just recommend a modeling pattern.

Proposals:

• Add 4 (5?) datatype properties to gist
• Do nothing in gist, offer both patterns as recommendations depending on use case

[philblackwood]

Attached are diagrams of examples from the current gitHub repository for operators (option 2), and the same diagrams refactored to use data properties (option 1). Using data properties makes the diagrams simpler for spec entries and also for version dependencies. For version dependencies, it eliminates some blank nodes.

spec entry and version dependency.pptx

[philblackwood]

Could we use existing SHACL properties to define SpecEntries?

sh:minExclusive
sh:minInclusive
sh:maxExclusive
sh:maxInclusive

They have literal as an object. The SHACL spec does not say what the subject can be, so why not a spec entry?

Note: in SHACL, properties like sh:lessThan have properties as subject and object, e.g. ex:birthDate sh:lessThan ex:deathDate. So we would not want to use these for defining the values in a SpecEntry.

If we do want to "define our own" in gist, it might be helpful to people who use SHACL to use the min/max style instead of lessThan/greaterThan style so they don't have to switch contexts too much when going between gist and SHACL.

[rjyounes]

@philblackwood We cannot use SHACL in gist because it makes gist non-DL compliant. See #1001 and the issues referenced there. I would also argue that your proposal is a misuse of the intent of the SHACL terms, but I don't need that to make my case.

[rjyounes]

I am leaning towards Pattern 2, using Magnitude objects rather than datatype properties. It is more consistent to always represent amounts using a Magnitude, rather than sometimes using magnitudes and sometimes something else. A magnitude in a specification is still an amount, it is just an amount specified rather than an actual amount. I don't believe the specified vs actual difference should change the modeling.

[MichaelSullivanArchitect]

[like] Michael J. Sullivan reacted to your message:

…

________________________________ From: Rebecca Younes ***@***.***> Sent: Thursday, August 29, 2024 11:33:52 AM To: semanticarts/gist ***@***.***> Cc: Michael J. Sullivan ***@***.***>; Comment ***@***.***> Subject: [External] : Re: [semanticarts/gist] Modeling patterns and/or gist updates for a magnitude range (Issue #1145) I am leaning towards Pattern 2 using Magnitude objects rather than datatype properties. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145*issuecomment-2317389843__;Iw!!ACWV5N9M2RV99hQ!IyCM3NNCqz2Z2aL1leZuILMUWZZqmPeGJy4EjPmnSzJKuTjNeEjzwl9WgYNkD3H6RTH5G9hdu02rMCqHKK0gU1qqtGUvy6c$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTH4PIJAWTIIU23YUSMLZT4BKBAVCNFSM6AAAAABMHCHLGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXGM4DSOBUGM__;!!ACWV5N9M2RV99hQ!IyCM3NNCqz2Z2aL1leZuILMUWZZqmPeGJy4EjPmnSzJKuTjNeEjzwl9WgYNkD3H6RTH5G9hdu02rMCqHKK0gU1qq51CUPIw$>. You are receiving this because you commented.Message ID: ***@***.***>