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?