Add class gist:SpecEntry

[rjyounes]

A SpecEntry is a Specification that has a magnitude and an aspect; for example, the specification of a particular furnace has an entry specifying weight (aspect) of 107 lbs (magnitude). This seems to be useful in a number of domains. Proposed definition:

gist:SpecEntry 
    a owl:Class ;
    skos:prefLabel "Spec Entry" ;
    skos:definition "A sub-specification consisting of the aspect being measured and a magnitude." ;
    skos:example "The specification of a particular furnace includes, among others, spec entries specifying a weight of 107 lbs and a maximum overcurrent protection of 15 amps. In the first entry, the aspect is weight and the magnitude is 107 lbs. In the second, the aspect is maximum overcurrent protection and the magnitude is 15 amps. (Each magnitude consists of a numeric value and unit of measure.)" ;
    owl:equivalentClass [
        owl:intersectionOf (
            gist:Specification 
            [
                a owl:Restriction ;
                owl:onProperty gist:hasMagnitude ;
                owl:someValuesFrom owl:Thing ;
            ]
            [
                a owl:Restriction ;
                owl:onProperty 
                                       [ owl:inverseOf gist:aspectOf ] ;
                owl:allValuesFrom gist:Aspect ;
            ]
            [
                a owl:Restriction ;
                owl:onProperty 
                                       [ owl:inverseOf [ gist:aspectOf ] ;
                owl:cardinality "1"^^xsd:nonNegativeInteger ;
            ]   
            [
                a owl:Restriction ;
                owl:onProperty gist:partOf ;
                owl:onClass gist:Specification ;
                owl:minQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
            ]           
        ) ;
    ] ;
    .

Details negotiable. E.g, is it always part of a larger Specification, or could it occur on its own?

Question regarding the first restriction: are two magnitudes expressed in different units of measure and numeric values but which equal the same amount the same thing or two different things? Assuming the latter, I've used a someValuesFrom restriction on hasMagnitude. Assuming the latter we could specify cardinality of 1.

Notice also that aspectOf doesn't specify domain Aspect; thus the allValuesFrom restriction on the inverse of aspectOf.

[rjyounes]

Related issue: in the case of concrete objects, as opposed to specifications, we suggest, I guess, that different predicates would be used to indicate the aspect being measured: hasWidth, hasHeight, hasCoolingCapacity, etc. It seems to me we should have a single approach to both specifications and real objects, and that the aspect model is preferable because it avoids defining a plethora of predicates in the domain ontology.

[uscholdm]

I'd love to have a sub-gist for specifications to include something like this. We have modeled this sort of thing for many clients. However, as described in this wiki article, each situation is different enough so that the model usually needs to be tweaked in some way. I'd have to give careful thought to what we might be able to use as a stable core model.

[uscholdm]

@rjyounes This should be discussed in the context of #800. I think it is a good idea, especially now that we are creating the operators ontology. The above definition seems overly complicated. Below is more like what we have used for past clients.

gist:SpecEntry
    a owl:Class ;
    owl:equivalentClass [
        a owl:Class ;
        owl:intersectionOf (
            gist:Specification
            [
                a owl:Restriction ;
                owl:onProperty gist:ofCharacteristic ;
                owl:someValuesFrom gist:Characteristic ;
            ]
            [
                a owl:Restriction ;
                owl:onProperty gist:specifiedValue ;
                owl:someValuesFrom [
                    a owl:Class ;
                    owl:unionOf (
                        gist:Category
                        gist:Magnitude
                    ) ;
                ] ;
            ]
        ) ;
    ] ;
    skos:definition "Specifies values for a particular characteristic indicating what it means to be in spec for that characteristic. Often this will be what is required, allowed or promised, but it could also be used to specify what is not allowed.  The values will typically be numerical with some unit of measure specified."^^xsd:string ;
    skos:prefLabel "Spec Entry"^^xsd:string ;
    skos:scopeNote "Sets of allowed values may also come from a Nominal or Ordinal scale of measure."^^xsd:string ;
    .

[rjyounes]

Closing - this will be handled by the new units and measures model.

[uscholdm]

There was not completed. There was no decision or even a discussion about whether/how to have SpecEntry in the context of the new units model. Once that is settled, we should come back and consider how it would work.

[rjyounes]

Closing due to implementation of new units and magnitudes model.

[rjyounes]

Reopening due to the question of how to handle a range of values (greater than, greater than or equal to, etc.) accommodated in spec entries. It remains to be seen how the new units and magnitudes model will model this, as it was built on the pre-gist13 Magnitude consisting of unit of measure + numeric value, without an aspect built in.

One approach would be to define several subproperties of gist:numericValue, such as lessThanOrEqualTo etc. to connect the gist13 Magnitude to one or more numeric values. This is different from the original SpecEntry relation which points the SpecEntry at two or more gist12 Magnitudes. This model would be more compact, though it's an open question whether it gains or loses semantic correctness. It's also not clear whether we would want any of this in gistCore.

@philblackwood any thoughts on this?

[rjyounes]

Given that gist 13 magnitudes include aspect, a class for SpecEntry = ((uom + numericValue) + aspect) doesn't seem necessary.

However, SpecEntries have also been used to model aspect + category, as in color: green.

Should characteristics whose values can be expressed either numerically or categorially be one aspect or two?

Rebecca: Should be one aspect. There are mappings between the two - e.g., European shoe size 40 (a numeric value measured in cm) = US women's shoe size 9 (arguably a category) which can be mapped to, say, medium. It depends on use case. Notably, manufacturers typically need precise numeric values where the customer value is categorial. Amplitude might be measured in decibels while others may only need high, medium, low - it's still the same aspect.

Phil agrees, Michael thinks they are distinct.

Allowing for either magnitude or categorial values with an aspect would complicate queries, though. Users might implement SHACL constraints to limit the values, just as they might require that length be expressed in inches rather than centimeters.

We ascertained that Aspect and hasAspect are not definitionally limited to scalar values, though some annotation changes should be made, depending on the decision we reach above:

• Aspect is defined as "A measurable characteristic such as length, weight, cost, cycle time, or defect rate." If it can include non-scalar aspects we should make this clear at least with examples or a scope note.
• hasAspect is defined as "Relates a magnitude to its aspect (measurable characteristic)." If it's meant to apply beyond magnitudes we should loosen up the definition. (Note that there's no domain.)

Do we need a class for Aspect + category (color: green)? What would we call it?

[rjyounes]

I propose the following model:

• SpecEntry is a subclass of Specification that has an aspect and a magnitude, range of magnitudes, or a category for a value. (This is its original definition as implemented at various clients.)
• This aligns with my suggestion on issue #1145 that a range should point at two magnitudes rather than literals. We can use the predicates defined in the Operators Ontology, with no need for additional predicates.
• By stating the aspect on the SpecEntry, we get the benefit of pattern 1 and satisfy our intuition that each magnitude in a range would have the same aspect.
• It is not necessary to assert the aspects on the magnitudes (though by definition of Magnitude we know that they exist). The aspect can be inferred via SPARQL from the SpecEntry onto the Magnitudes.
• By stating the aspect on the SpecEntry, we can have a uniform model for categorial and scalar SpecEntrys.

Sample triples:

:_ProductSpecification_1 a gist:ProductSpecification .

:_SpecEntry_1 
   a gist:SpecEntry ;
   gist:isDirectPartOf :_ProductSpecification_1 ; # not sure if this is the proposed predicate
   gist:hasAspect gistd:_Aspect_length ;
   ops:hasValueGreaterThan :_Magnitude_1 ;
   ops:hasValueLessOrEqualTo :_Magnitude_2 ;
   .

:_Magnitude_1 
    a gist:Magnitude ;
    gist:numericValue 50 ;
    gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;
    # inferred: gist:hasAspect gistd:_Aspect_length ;
   .

:_Magnitude_2 
    a gist:Magnitude ;
    gist:numericValue 60 ;
    gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;
    # inferred: gist:hasAspect gistd:_Aspect_length ;
   .

:_SpecEntry_2
    a gist:SpecEntry ;
    gist:isDirectPartOf :_ProductSpecification_1 ; # not sure if this is the proposed predicate
    gist:hasAspect gistd:_Aspect_color ;
    ops:hasValueEqualTo :_Color_red ;
    .

:_Color_red a :Color .

It is open to discussion whether we make modifications to the operators predicates as proposed above.

[uscholdm]

I like this a lot, well done! It's very straight-forward with minimal disruption to how we do things now - and it allows for categories. How cool is that? Very elegant, (though maybe not quite in the league with e = mc-squared). I was hoping a solution like this would emerge.

I do think that using isPartOf is correct and aligns with what we have been doing all along.

[MichaelSullivanArchitect]

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

---

From: Rebecca Younes @.> Sent: Friday, August 30, 2024 6:00:53 PM To: semanticarts/gist @.> Cc: Subscribed @.***> Subject: [External] : Re: [semanticarts/gist] Add class gist:SpecEntry (#527)

I propose the following model:

• SpecEntry is a subclass of Specification that has an aspect and a magnitude, range of magnitudes, or a category for a value. (This is its original definition as implemented at various clients.)
• This aligns with my suggestion on issue #1145https://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/1145*issuecomment-2317389843__;Iw!!ACWV5N9M2RV99hQ!LqfQg4q7sGOQZJ5ggTG6ljlT-Wvl621s_pyCjt7mKIQWfNDkQwhthZBRTlOQDHR9qmj5h4r7lyiNYNhozaq0JzmqkPHJjEI$ that a range should point at two magnitudes rather than literals. We can use the predicates defined in the Operators Ontologyhttps://urldefense.com/v3/__https://github.com/semanticarts/operators-ontology/__;!!ACWV5N9M2RV99hQ!LqfQg4q7sGOQZJ5ggTG6ljlT-Wvl621s_pyCjt7mKIQWfNDkQwhthZBRTlOQDHR9qmj5h4r7lyiNYNhozaq0JzmqHjgspp0$, with no need for additional predicates.
• By stating the aspect on the SpecEntry, we get the benefit of pattern 1 and satisfy our intuition that each magnitude in a range would have the same aspect.
• It is not necessary to assert the aspects on the magnitudes (though by definition of Magnitude we know that they exist). The aspect can be inferred via SPARQL from the SpecEntry onto the Magnitudes.
• By stating the aspect on the SpecEntry, we can have a uniform model for categorial and scalar SpecEntrys.

Sample triples:

:_ProductSpecification_1 a gist:ProductSpecification .

:_SpecEntry_1 a gist:SpecEntry ; gist:isDirectPartOf :_ProductSpecification_1 ; # not sure if this is the proposed predicate gist:hasAspect gistd:_Aspect_length ; ops:hasValueGreaterThan :_Magnitude_1 ; ops:hasValueLessOrEqualTo :_Magnitude_2 ; .

:_Magnitude_1 a gist:Magnitude ; gist:numericValue 50 ; gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;

inferred: gist:hasAspect gistd:_Aspect_length ;

.

:_Magnitude_2 a gist:Magnitude ; gist:numericValue 60 ; gist:hasUnitOfMeasure gistd:_UnitOfMeasure_inch ;

inferred: gist:hasAspect gistd:_Aspect_length ;

.

:_SpecEntry_2 a gist:SpecEntry ; gist:isDirectPartOf :_ProductSpecification_1 ; # not sure if this is the proposed predicate gist:hasAspect gistd:_Aspect_color ; ops:hasValueEqualTo :_Color_red ; .

:_Color_red a :Color .

It is open to discussion whether we make modifications to the operators predicates as proposed above.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/527*issuecomment-2322073886__;Iw!!ACWV5N9M2RV99hQ!LqfQg4q7sGOQZJ5ggTG6ljlT-Wvl621s_pyCjt7mKIQWfNDkQwhthZBRTlOQDHR9qmj5h4r7lyiNYNhozaq0JzmqaYlyn6k$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTHYQGU5AFZ6PH6EOES3ZUCXNLAVCNFSM5BURPCGKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGIYDOMZYHA3A__;!!ACWV5N9M2RV99hQ!LqfQg4q7sGOQZJ5ggTG6ljlT-Wvl621s_pyCjt7mKIQWfNDkQwhthZBRTlOQDHR9qmj5h4r7lyiNYNhozaq0Jzmqcf4tCfo$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MichaelSullivanArchitect]

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

---

From: Michael Uschold @.> Sent: Tuesday, September 3, 2024 6:15:28 PM To: semanticarts/gist @.> Cc: Subscribed @.***> Subject: [External] : Re: [semanticarts/gist] Add class gist:SpecEntry (#527)

I like this a lot, well done! It's very straight-forward with minimal disruption to how we do things now - and it allows for categories. How cool is that? Very elegant, (though maybe not quite in the league with e = mc-squared). I was hoping a solution like this would emerge.

I do think that using isPartOf is correct and aligns with what we have been doing all along.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/semanticarts/gist/issues/527*issuecomment-2327140385__;Iw!!ACWV5N9M2RV99hQ!JLhf0x9Gm67LtmVNGvCanUUZOGgBWTDtq1NGcCd5BKR97IUf8xqyL34bq_hqxQvi_xDhvTbiEQ7HoF22FR_N6U-S31cwl6M$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOMYTH52VX45ZCZJNBIQWVLZUX4EBAVCNFSM5BURPCGKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSG4YTIMBTHA2Q__;!!ACWV5N9M2RV99hQ!JLhf0x9Gm67LtmVNGvCanUUZOGgBWTDtq1NGcCd5BKR97IUf8xqyL34bq_hqxQvi_xDhvTbiEQ7HoF22FR_N6U-Sq4THEKc$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[philblackwood]

The definition should also cover the case of version IDs, as in the versioning ontology.

That makes 3 use cases: magnitudes version IDs categorical values

Looking at all the use cases, the spec entry seems to be used to specify a set of values, so perhaps we should call it ValueSpec or ValueSpecification.

[rjyounes]

The versioning ontology doesn't import gist, it defines its own terms, so I'm not convinced that gist must consider the needs of that ontology. It defines its own class VersionRangeSpec, which does not have an aspect. The defining characteristic of what we're calling SpecEntry is that it has an aspect plus a value, either a magnitude or a category, so in any case I don't think it's a SpecEntry.

We may also want to add a restriction on SpecEntry that it be part of a Specification, but we should discuss that.

[uscholdm]

Looking at all the use cases, the spec entry seems to be used to specify a set of values, so perhaps we should call it ValueSpec or ValueSpecification.

INteresting point, a SpecEntry defines a range of acceptable values, which is a set, strictly speaking. When we first modeled this in 2011, Dave cintroduced the term AllowableRange - however, SpecEntry is not a pure range of values, it is tied to an aspect. An instance of SpecEntry always refers to a range of values for a particular aspect. A group of spec entries is collectively a specification for something.

If we wanted just the range, SpecEntry would have one, but I am not proposing that.

[uscholdm]

The defining characteristic of what we're calling SpecEntry is that it has an aspect plus a value,

Not just a value, but a set of acceptable values (which could be just one value).

[uscholdm]

The versioning ontology doesn't import gist, it defines its own terms, so I'm not convinced that gist must consider the needs of that ontology.

We don't want to be forced to align them, but I am strongly against having different ways to do the same thing, just because we did not give enough thought to it.

[rjyounes]

I don't see that VersionRangeSpec is sufficiently similar to SpecEntry that they should coincide.

[uscholdm]

We may also want to add a restriction on SpecEntry that it be part of a Specification, but we should discuss that.

That is too strong, by analogy, engine bolts are created and intended to be part of actual engines. But they might not be so for a while, if ever. I can create a spec entry saying that width is between 1 and 2 inches intending it to be used for furniture. In practice it will almost certainly be part of a specification, but not in principle.

[uscholdm]

I don't see that VersionRangeSpec is sufficiently similar to SpecEntry that they should coincide.

They are very close in meaning. Each has:

1. an aspect (e.g. width, version number)
2. a specification of a set of acceptable values for the aspect using the operators: EQ, GE, GT, LE & LT

Ignoring ontology modularity issues regarding, gist and the operators and versioning ontologies one could define version range spec to be a subclass of spec entry with three additional restrictions.

1. `hasAspect value :_Aspect_versionNumber
2. isVersionRangeOf some owl:Thing
3. `hasSpecifiedValue some SemanticVersionNumber

In fact, defining version range spec as an explicit subclass would be optional.

I'll work out an example to clarify this.

[uscholdm]

Ignoring ontology modularity issues regarding, gist and the operators and versioning ontologies one could define version range spec to be a subclass of spec entry with three additional restrictions.

Having taken a closer look at the versioning ontology, which imports the operators ontology, I have a sense of what it would take to explicitly make VersionRangeSpec a subclass of SpecEntry. I conclude that there is little if any benefit in doing so, given the design goal to keep the versioning and operators ontologies independent from gist. As it is, to keep that independence, we had to recreate separate versions of a few classes and properties that were needed. There is no need for SpecEntry in the versioning ontology, so it's a bit moot to consider creating it just to subclass off it. I thought of having a skos note about it, but that hardly seems worthwhile.

[rjyounes]

We deliberately wanted to keep the operators/versioning ontologies independent of gist. I therefore don't see that the subclassing is an option. gist should not inherit a concept as fundamental as SpecEntry from the versioning ontology, and as you say it's not needed there.

[uscholdm]

We deliberately wanted to keep the operators/versioning ontologies independent of gist. I therefore don't see that the subclassing is an option. gist should not inherit a concept as fundamental as SpecEntry from the versioning ontology, and as you say it's not needed there.

Agreed. However, this does bring into focus how we implement SpecEntry in gist. Specifically, given that the operators ontology properties were designed to be used with SpecEntry in the first place with client ontologies, it would be nice to just use them w/o reinventing the wheel. Two approaches are:

1. import the operators ontology into gist
2. recreate them in the gist namespace

The first is straight-forward - I had a close look and did not see any issues. The second would be unfortunate duplication.

[dylan-sa]

We may also want to add a restriction on SpecEntry that it be part of a Specification, but we should discuss that.

That is too strong, by analogy, engine bolts are created and intended to be part of actual engines. But they might not be so for a while, if ever. I can create a spec entry saying that width is between 1 and 2 inches intending it to be used for furniture. In practice it will almost certainly be part of a specification, but not in principle.

To me the term "entry" implies that it is actually entered in (or part of) a specification. (See, for example, 4b--"something entered.") For this reason I'm in favor of the restriction.

[dylan-sa]

@rjyounes -- At one client we've seen a use case for composite aspects. If drawer size is represented as '20in x 10in x 30 in' in the data, it is helpful to be able to model which of those is the height, which is the width, and which the depth.

Should the definition of SpecEntry accommodate this use case?

[uscholdm]

@rjyounes -- At one client we've seen a use case for composite aspects. If drawer size is represented as '20in x 10in x 30 in' in the data, it is helpful to be able to model which of those is the height, which is the width, and which the depth.

Should the definition of SpecEntry accommodate this use case?

That is very interesting, but seems highly specialized - not the sort of thing that we normally include in gist.

[uscholdm]

To me the term "entry" implies that it is actually entered in (or part of) a specification. (See, for example, 4b--"something entered.") For this reason I'm in favor of the restriction.

An airplane engine is so called because it is intended to be part of an airplane, just like SpecEntry is intended to be part of a specification. We don't need to give 'airplane engine' because sometimes is it not part of an actual airplane.

[rjyounes]

@rjyounes -- At one client we've seen a use case for composite aspects. If drawer size is represented as '20in x 10in x 30 in' in the data, it is helpful to be able to model which of those is the height, which is the width, and which the depth.

No, that got very messy and we ended up not using it anyway.

[rjyounes]

To me the term "entry" implies that it is actually entered in (or part of) a specification. (See, for example, 4b--"something entered.") For this reason I'm in favor of the restriction.

I think maybe the problem is with the word choice - I.e., can we call it something other than SpecEntry? I never understood the use of "entry" here. How about ValueSpecification?

[uscholdm]

I think maybe the problem is with the word choice - I.e., can we call it something other than SpecEntry? I never understood the use of "entry" here. How about ValueSpecification?

In long form, a spec entry is

• a specification of a set of acceptable values for a particular aspect

So ValueSpecification is accurate and reasonable. Main downside is it's a bit long. I don't particularly like ValueSpec either even if we did go for abbreviated forms for names, which is against our general guidelines, AFAIK.

[rjyounes]

I prefer ValueSpecification but could live withValueSpec. We occasionally use abbreviated forms (the geo terms, not to mention SpecEntry itself), and ValueSpecification is not out of place with terms such as SubCountryGovernment, DegreeOfCommitment, ElectronicAddressType.

[uscholdm]

I just drafted a PR with a detailed example which is based on @rjyounes 's proposal. It directly imports the operators ontology https://github.com/semanticarts/gist/pull/1161

[rjyounes]

Goal: Specify a set of acceptable values for an aspect.

Requirements:

1. Handle categories and magnitudes uniformly.
2. Handle a range of values, either categories or magnitudes.
3. Handle single values (a single target)
4. Handle a set that isn't a range (discrete values).
5. Ability to set a target value with a range of variation (could be expressed in the max and min, or as a separate percent). gist could provide max and min only, extensions can add a percentage property.

TODOs for next meeting:

• Michael: account for requirement 4.
• Phil: account for requirement 1.

[philblackwood]

Getting to be long thread, but it's not clear SpecEntry is necessary.

Just relate the specification to an individual magnitude or range of magnitudes.

It looks like it would be helpful to add a class for Range.

[NaoualSmaili]

1. Versions may include additional qualifiers like alpha, beta, RC (Release Candidate), or build metadata. Ignoring these can lead to misrepresentation of compatibility and dependencies.

2. Also, for version range representation, simply using ranges may not suffice. For instance, a software might be compatible with versions 2.0.x but not 2.0.5 due to a known bug. The model should allow for specifying such exceptions within version ranges.

[rjyounes]

@philblackwood

...it's not clear SpecEntry is necessary. Just relate the specification to an individual magnitude or range of magnitudes. It looks like it would be helpful to add a class for Range.

I agree that since magnitudes include aspect, SpecEntry (or Characteristic) doesn't add anything, though would still be needed for category values and collections. Were you thinking a Range itself would have an aspect or not? Example:

# Range with aspect
:_Range_gas_mileage_31_39_mpg
    a gist:Range ;
    gist:hasAspect :_Aspect_gas_mileage ;
    gist:hasMinInclusive :_Magnitude_gas_mileage_31_mpg ;
    gist:hasMaxInclusive :_Magnitude_gas_mileage_39_mpg .

:_Magnitude_gas_mileage_31_mpg
    a gist:Magnitude ;
    gist:hasAspect :_Aspect_gas_mileage ;
    gist:hasUnitOfMeasure :_UnitOfMeasure_mpg ;
    gist:numericValue 31 .

:_Magnitude_gas_mileage_39_mpg
    a gist:Magnitude ;
    gist:hasAspect :_Aspect_gas_mileage ;
    gist:hasUnitOfMeasure :_UnitOfMeasure_mpg ;
    gist:numericValue 39.

Or:

# Range without aspect
:_Range_gas_mileage_31_39_mpg
    a gist:Range ;
    gist:hasMinInclusive :_Magnitude_gas_mileage_31_mpg ;
    gist:hasMaxInclusive :_Magnitude_gas_mileage_39_mpg .

In the first case we duplicate the aspect on both the range and the magnitudes, as we talked about with my proposed Characteristic class.

[philblackwood]

This comment is for creating specifications with categorical data ...

Note added 11/6/2024: if our subclasses of gist:Category are actually aspects (as they appear to be), then we need to pick one pattern ... either model them as aspects and stop using subclasses of Category, or continue using subclasses of Category and make it the standard pattern (leave aspects as is, representing only measurable characteristics).

The convention we use to model categories is a pattern like:

Some issues with this pattern are:

• Exterior color is an aspect, so now we have two ways to represent aspects (gist:Aspect or subclass of category) • Every time a new subclass of category is needed, the ontology needs to be changed. • Only annotation properties can have the class ex:ExteriorColor as an object, limiting expressiveness.

Note that we could also have an interior color red; since it has a different IRI than the exterior color red, it does not have to represent the same shade of red as the exterior color (which is a good thing). In this representation there is no stand-alone “red”.

IRIs: ex:_ExteriorColor_red ex:_InteriorColor_red

Also note that ex:_ExteriorColor_red is an instance of the gist:Category class.

Now suppose we want to use aspects instead of subclasses:

Old: ex:_ExteriorColor_red New: ex:_Category_exterior_color_red

With this pattern, there is a one-to-one correspondence between the “old” representation and the “new” representation of categorical data. Also, with this new representation:

• New aspects can be added without changing the ontology • We have only one way to represent aspects • User-defined properties can relate things to the aspect

With this new representation, we might model categorical specifications as:

The fact that thing 1 is categorized by a category that is part of the specification means it conforms to the specification.

[arguably there might be a better way to say that the specification includes exterior colors red, blue, gray, and white]

Note added 11/6/2024: the example is not correct. See additional comment showing 3 cases.

Note that in either representation, we might want to be able to say that the interior and exterior red are the same [method tbd].

[uscholdm]

This is very interesting.

• Are you proposing that all instances of gist:Category are to have an aspect, just like all Magnitudes do?
• Are you proposing to never have subclasses of gist:Category?

[philblackwood]

@uscholdm if we want to expand the definition of aspect from "measurable characteristics" to "characteristics" then I think we want to use those aspects instead of creating subclasses of category so that there is a single way to represent them.

e.g. pick one of these styles:

using categories: ex:_ExteriorColor_red (requires updating the ontology to include ExteriorColor) using aspects: ex:_Category_exterior_color_red with aspect ex:_Aspect_exterior_color

Actually, either style can be used to define specifications, so we can treat the question separately if we agree that we should pick one of these and not use a combination of aspects and subclasses of category.

[philblackwood]

Comment about how we use specifications ...

Consider the simple case of a specification with two aspects, with a single fixed acceptable value for each one.

rectangle specification: length 3 inches, width 8 inches. actual rectangle measurements: length 3 inches, width 8 inches.

In this simple case we define the specification exactly the same way we describe the actual.

Variation: specification says the width may be either 8 inches or 10 inches. We should cover this case as well, since many specifications come with a choice of values.

The concept of SpecEntry really isn't needed in either case.

See next comment for how this applies to "categorical values".

[philblackwood]

Specifying things with categorical values using our convention of subclasses of categories.

Case 1: within each category a thing and its specification are single-valued.

Thing 1 conforms to its specification. In general, check to see if there is an exact match between the actual values and the values in the specification.

Variation: choice of colors. First introduce the collection of acceptable colors.

Now see if the value for thing 1 is one of the acceptable colors:

Thing 1 conforms to its specification because its value is one of the acceptable colors in the specification.

To specify that a thing can have multiple colors, either create a category for each color combination (explicit) or create a new property (not as useful because it might require one property for a pair of colors, one for any 3 colors, one for any 4 colors, etc.)

Note that the examples still work if _ExteriorColor is replaced by _Category_exterior_color (1-to-1 correspondence).

[uscholdm]

Interesting, so it seems you are proposing that it is not necessary to have subclasses of Category, one could use aspects instead. Is that correct?

[uscholdm]

On property naming... Thing 1 may well be a thing with a red exterior color, and thus saying that it gist:isCategorizedBy :_ExteriorColor_red makes sense. However the specification does not have an exterior color, as it is not a physical object. In longwinded terms, the specification specifies that the exterior color is red. Not easy to come with a good property name for this that conforms to common sense and is not too long or convoluted.

[rjyounes]

If we are going to say that a specification hasValue or hasMagnitude, then why not also isCategorizedBy? I think the predicates can be interpreted flexibly enough to make that acceptable.