rjyounes commented 3 months ago

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 commented 3 months ago

[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 Ontologyhttps://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 considerationhttps://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 GitHubhttps://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145__;!!ACWV5N9M2RV99hQ!KBc0skSrSx6lLiFAFhg1ZOBaXj1BwLEcp0-cpGkBBfGViMcshY8JkglaalA0LlGVdlpCKEnPPcNJVR0uPEDZTObcy_tRBCQ$, or unsubscribehttps://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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

[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 GitHubhttps://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145*issuecomment-2317389843__;Iw!!ACWV5N9M2RV99hQ!IyCM3NNCqz2Z2aL1leZuILMUWZZqmPeGJy4EjPmnSzJKuTjNeEjzwl9WgYNkD3H6RTH5G9hdu02rMCqHKK0gU1qqtGUvy6c$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTH4PIJAWTIIU23YUSMLZT4BKBAVCNFSM6AAAAABMHCHLGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXGM4DSOBUGM__;!!ACWV5N9M2RV99hQ!IyCM3NNCqz2Z2aL1leZuILMUWZZqmPeGJy4EjPmnSzJKuTjNeEjzwl9WgYNkD3H6RTH5G9hdu02rMCqHKK0gU1qq51CUPIw$. You are receiving this because you commented.Message ID: @.***>

philblackwood commented 2 months ago

Looking at the predicates ... here is an argument for using the min/max style rather than the lessThan/greaterThan style.

We want to be able to say that a certain aspect of a thing needs to fall within a range of values.

For example:

[set of "good" values] [some predicate] [highest acceptable value]

The predicate should relate a set of values to a specific value.

hasValueLessThan would typically mean "has a value that is less than" (but that's not what we want).

hasValuesLessThan would typically mean "has some values less than" (but that's not what we want).

As a statement about the set of good values, the predicate hasMaximumValue has a clearer meaning:

[the set of good values] [has a maximum of] [highest acceptable value] expresses the desired relationship between a set of values and a specific value.

In other words, the min/max style makes a clear statement about the set of values, while the lessThan/greaterThan style seems to require giving the predicates a meaning that is different from the typical plain English meaning we use with other predicates that start with "has".

uscholdm commented 2 months ago

@philblackwood

Looking at the predicates ... here is an argument for using the min/max style rather than the lessThan/greaterThan style.

We want to be able to say that a certain aspect of a thing needs to fall within a range of values.

That is correct. The operators ontology was designed to be used with an object whose meaning is: "A specification of values for a particular aspect indicating what it means to be in spec for that aspect." Conceptually, there are two parts. The aspect, and the specification of the set of acceptable values. The latter is not a thing unto itself with an IRI, rather it's specified by one or more triples that collectively define the range for the aspect, i.e. LE, LT, EQ, GE, GT and a few others. So there might be an IRI that means 'the width is less than 10 inches' :_SpecEntry_WidthLt10inches or :W_Lt_10in for short .

For example:

[set of "good" values] [some predicate] [highest acceptable value]

The predicate should relate a set of values to a specific value.

No, there is no IRI that corresponds to the set of good values on its own. The triple that expresses that the width must be LT 10 inches is :W_Lt_10in :hasValueLessThan :_Magnitude_10inches. there might also be a triple that expresses that the width must be GE 4 inches. :W_Ge_4in :hasValueGreaterOrEqualTo :_Magnitude_4inches

Less than is sometimes called max exclusive. In mathematical as well as everyday terms greater than or equal to is identical in meaning to minimum. It was hard to come up with good definitions, but the current definition of hasValueLessThan is: "Relates a specification to a value that an aspect must be less than."

:W_Lt_10in :hasValueLessThan :_Magnitude_10inches. says that the specification for the aspect width must have a value less than 10in in order to be regarded as being in spec (in the allowable range).

hasValueLess would typically mean "has a value that is less than" (but that's not what we want).

Why not? It is exactly what I want. 'Less than' is much more friendly than 'min exclusive'.

As a statement about the set of good values, the predicate hasMaximumValue has a clearer meaning: [the set of good values] [has a maximum of] [highest acceptable value] expresses the desired relationship between a set of values and a specific value.

In other words, the min/max style makes a clear statement about the set of values, while the lessThan/greaterThan style seems to require giving the predicates a meaning that is different from the typical plain English meaning we use with other predicates that start with "has".

It is true that the use of 'has' is not great, I could not think of a better alternative. Two more things. First, max has the same meaning as 'less than or equal to' but a different meaning from 'less than'. Second I am not wanting to say something about the set of good values, there is no IRI that corresponds exactly to that set. I am specifying what it means to BE a good value. This may be where we are talking across purposes.

philblackwood commented 2 months ago

An aggregate relates a set of values to a single value, e.g. the average of the scores is 87 or the max of the scores is 96.

We don't say "the scores less or equal to 96". The comparison relations <, <=, >, >= are used to compare two things of the same type, and we shouldn't use them in place of the aggregate relations that are defined as relating a set of values to a specific value.

philblackwood commented 2 months ago

rewritten Oct 1, 2024 -- includes issue #527

No attempt is made to propose what belongs in gist vs. a submodule like the versioning ontology. (even if the examples might look like it)

General pattern:

Queries can compare the actual value against the acceptable values for the given common element. The common element is used to find the set of acceptable values that the actual value should be validated against.

The common element snaps together when the actual_value and the acceptable_values are created and both refer to it.

Case 1: values of a category

The way we typically represent categorical data is like this:

We want to specify the list of acceptable or available colors for a given thing.

We want to be able to see if the color of a thing is one of the acceptable colors. To do this we need a way to find the correct set of acceptable values. What the actual color and the list of acceptable colors have in common is that they are both related to color.

In this pattern, we expect the thing to have a single set of acceptable colors.

In this simple scenario, if the thing has two colors, say red and green, we can infer that they are both valid. (if we want color combinations, we would have to create a different category)

Since each category has a finite list of members, the simple approach is to always list the acceptable values using gist:isMemberOf.

Case 2: magnitudes

A thing can have many different magnitudes, each represented as:

We want to specify the acceptable or available magnitudes for a given thing.

If the specification is used as guidance to create something, we want to be able to say what the magnitude of the created thing should be.

If we want to identify a list of magnitudes a thing may have, we could perhaps list multiple targets. (tbd)

We want to be able to identify a range of acceptable values for the magnitude of the thing. Since the specification is a set of values, the most descriptive properties to identify the range are max and min (for example, min relates a set of values to a single value).

A magnitude specification may have any combination of target, max, and min (at least one of these).

In this approach, a validation should be done to ensure that all of the specified magnitudes have the same aspect.

The presentation layer can translate the max and min to percentages or to a tolerance (if the max and min are equally distant from the target value).

We want to be able to see if the magnitude of a thing is one of the acceptable values. To do this we need a way to find the correct set of acceptable values. What the actual magnitude and the set of acceptable magnitudes have in common is that they both are related to the same aspect.

In this pattern, we expect the thing to have a single actual magnitude and a single set of acceptable magnitudes.

Case 3: versions

It is common for a versioned thing to use another versioned thing:

The predicate "uses" will cover the case of imports for ontologies and also versions of software that may be related to other software in many different ways. It implies there is a dependency.

In this example, we want to specify which versions of gistCore are compatible with version 6.3.0 of the disease taxonomy.

The versions of gistCore are ordered, so we can define the compatible versions as:

In this example, version 12.1.0 and all it successors up to but not including version 13.0.0 are compatible.

We want to be able to see if the version being used by a thing is one of the compatible values. To do this we need a way to find the correct set of compatible versions. What the actual version being used and the set of compatible versions have in common is that they both are related to the same underlying ontology.

In this pattern, we expect that there should be a single set of compatible versions of gist for the given version of the taxonomy.

It might be possible to extend this to say that a range of versions of the disease taxonomy is compatible with a range of versions of gist.

These patterns are equally applicable to versioned software.

Note that in some organizations, governance is done by directly relating compatible versions (instead of creating ranges). We could use :isCompatibleWith to handle that case.

MichaelSullivanArchitect commented 2 months ago

This is great work Phil. We will be leveraging these patterns for sure as our use-cases are all engineering oriented.

MichaelSullivanArchitect commented 2 months ago

Does this suggest that gist:MagnitudeSpec will be a new class in the next release?

MichaelSullivanArchitect commented 2 months ago

also, does this pattern preclude using gist:hasAccuracy in addition to the ranges and target?

philblackwood commented 2 months ago

@MichaelSullivanArchitect Accuracy is best thought of as a characteristic of the measurement method, e.g. the scale is accurate to within a pound.

It can also be thought of as the accuracy of a measurement, e.g. the scale says I weigh 180 and it's accurate to within a pound, so I weigh somewhere between 179 and 181.

However, when specifying a required amount I think it's better to just set hard limits. It's fine to set a requirement on the accuracy, but I don't think there is a notion of accuracy of a required range because the required range is not a measurement.

MichaelSullivanArchitect commented 2 months ago

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

From: Phil Blackwood @.> Sent: Thursday, September 26, 2024 2:57:52 PM To: semanticarts/gist @.> Cc: Michael J. Sullivan @.>; Mention @.> Subject: [External] : Re: [semanticarts/gist] Modeling patterns and/or gist updates for a magnitude range (Issue #1145)

@MichaelSullivanArchitecthttps://urldefense.com/v3/__https://github.com/MichaelSullivanArchitect__;!!ACWV5N9M2RV99hQ!N9mkaP8DWROfTV-xTfMW60QK5t-QellmZFtQ_snWJh21cF1t4KojBLm3QrAd78CFnKW8HLvqLkJcRvPTeq3jij66K1p6-Bc$ Accuracy is best thought of as a characteristic of the measurement method, e.g. the scale is accurate to within a pound.

It can also be thought of as the accuracy of a measurement, e.g. the scale says I weigh 180 and it's accurate to within a pound, so I weigh somewhere between 179 and 181.

However, when specifying a required amount I think it's better to just set hard limits. It's fine to set a requirement on the accuracy, but I don't think there is a notion of accuracy of a required range because the required range is not a measurement.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145*issuecomment-2377216377__;Iw!!ACWV5N9M2RV99hQ!N9mkaP8DWROfTV-xTfMW60QK5t-QellmZFtQ_snWJh21cF1t4KojBLm3QrAd78CFnKW8HLvqLkJcRvPTeq3jij66S8Uw_KU$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTH6QUHU5C5MLYA5O4T3ZYQOHBAVCNFSM6AAAAABMHCHLGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGIYTMMZXG4__;!!ACWV5N9M2RV99hQ!N9mkaP8DWROfTV-xTfMW60QK5t-QellmZFtQ_snWJh21cF1t4KojBLm3QrAd78CFnKW8HLvqLkJcRvPTeq3jij66CHb6PKg$. You are receiving this because you were mentioned.Message ID: @.***>

uscholdm commented 2 months ago

An aggregate relates a set of values to a single value, e.g. the average of the scores is 87 or the max of the scores is 96.

That sounds right.

We don't say "the scores less or equal to 96".

Correct.

The comparison relations <, <=, >, >= are used to compare two things of the same type, and we shouldn't use them in place of the aggregate relations that are defined as relating a set of values to a specific value.

I agree that they are two different things, but they are closely related. The operators ontology uses comparison operators to define a set of values implicitly without having an IRI that denotes that set of values. E.g. 6 <= x <= 8 defines the set of numbers between 6 & 8 including 6 & 8.

uscholdm commented 2 months ago

Does this suggest that gist:MagnitudeSpec will be a new class in the next release?

@MichaelSullivanArchitect It is a proposal. This is tightly linked with issue #1161 which calls the class SpecEntry. Other proposed names are: ValueSpec and ValueSpecification.

rjyounes commented 2 months ago

This is tightly linked with issue https://github.com/semanticarts/gist/pull/1161 which calls the class SpecEntry

The classes are actually different. I would say this model uses MagnitudeSpec where the other uses SpecEntry (or ValueSpec(ification). The latter allows for categorial values as well. Refer to issue #527 and especially this comment from our internal gist meeting for comparison.

semanticarts / gist

Modeling patterns and/or gist updates for a magnitude range #1145

If you have defined a superproperty above: