Aspect is not a Category, but CoherentUnit is a Category.

[uscholdm]

Related to: #451

PROPOSAL:

• make Aspect no longer be a subclass of Category
• Optional: make Aspect a subclass of SchemaMetaData
• Make CoherentUnit a subclass of Category
• Make hasStandardUnit a subproperty of categorizedBy

Aspect is a subclass of Category. This seems wrong to me. An aspect is a characteristic, such as height, inner diameter or cycle time. I cannot think what these things are categorizing. What can usefully be regarded as being in the category of "inner diameter"? I have no good idea and one wrong idea. The latter is to think of inner diameter as categorizing a Magnitude. However, there is a single magnitude that represents '2 inches', which could be the inner diameter of one pipe, the outer diameter of another and the length of a toothpick. Also, we generally try to avoid putting information on categories, but it is important to put information on Aspects.

Should Aspect be an orphan, or somewhere else? Things like width, inner diameter etc. are most directly modeled as properties, e.g. hasWidth, hasInnerDiameter who ranges are some subclass of Magnitude (in this case, Extent). Modeled this way does not involve the class Aspect. However, if we want to say things about these characteristics in the context of a product specification, we have to be able to say things like:

• the width of cabinet model B2774, to be in spec must be with in 1% of 27 inches.
• the battery life of the iPhone 12 Max, to be in spec, must be between 22 and 24 hours

So there will be an instance of ProductSpecification that has says what it means to be in spec for each of any number of characteristics. This requires the characteristic to be the subject of a triple, so we cannot use a property.
This is when we need to model underlying concepts represented by the properties: hasWidth, hasInnerDiameter, etc as individuals of some class. That class is gist:Aspect. I have been using it this way since 2011 at Proctor and Gamble. It was also used at Schneider, Platts, MD Anderson, IBB and perhaps a some others.

Because these aspects are really representing properties, it would make sense to have Aspect be a subproperty of SchemaMetaData. We could also leave it as an orphan.

On the other hand, one can think of every Magnitude as belonging in a category based on its CoherentUnit, which closely/exactly corresponds to a dimension (which is not explicit in gist).

• 27 inches belongs in the category of things that are measured in meters.
• 55 mph belongs in the category of things that are measured in meters per second.
• 80 watts belongs in the category of things that are measured in joules per second

[dylan-sa]

I agree w/ @uscholdm that gist:Aspect should not be a subclass of gist:Category. Usually instances of gist:Category could at least in principle also be modeled as classes. They are "buckets," so to speak. An aspect like height or inner diameter is not itself a bucket. It's true that there are related buckets like "thing with a height" or "thing with an inner diameter of three feet," but we wouldn't consider these to be instances of gist:Aspect.

I have no objection to placing gist:Aspect under gist:SchemaMetaData, as it arguably functions similarly to rdf:Property, which I think would also fall under gist:SchemaMetaData. However, I could also understand if gist:SchemaMetaData was really intended to include only RDF(S)/OWL concepts (plus analogous concepts from the relational world). I would be curious to hear more about how gist:SchemaMetaData has been used in practice.

[rjyounes]

I agree w/ @uscholdm that gist:Aspect should not be a subclass of gist:Category. Usually instances of gist:Category could at least in principle also be modeled as classes. They are "buckets," so to speak. An aspect like height or inner diameter is not itself a bucket. It's true that there are related buckets like "thing with a height" or "thing with an inner diameter of three feet," but we wouldn't consider these to be instances of gist:Aspect.

This is quite convincing.

I have no objection to placing gist:Aspect under gist:SchemaMetaData, as it arguably functions similarly to rdf:Property, which I think would also fall under gist:SchemaMetaData. However, I could also understand if gist:SchemaMetaData was really intended to include only RDF(S)/OWL concepts (plus analogous concepts from the relational world). I would be curious to hear more about how gist:SchemaMetaData has been used in practice.

This is not convincing. The way I understand SchemaMetaData, it's for modeling schema and their components, such as classes, properties, tables, columns, views, etc. An instance of SchemaMetaData would be, for example, a column in a table, which would have various properties such as datatype, whether nulls are allowed, whether it is a foreign key to some other table, whether it is a primary key, etc. I see no relationship here to Aspect, which describes real things like tables, pipes, and washing machines. I don't see how the inner diameter of a pipe is metadata rather than descriptive data.

[uscholdm]

I don't see how the inner diameter of a pipe is metadata rather than descriptive data.

The fact that a particular pipe's inner diameter is 3 cm is not metadata, it is descriptive data.
The relationship called inner diameter that connects a pipe to a distance is part of a schema that can be used to describe pipes, it is used to create the descriptive data. This is true whether 'inner diameter' is a column in a relational schema, an owl:ObjectPropety or a gist:Aspect

[rjyounes]

I don't have a good grasp of how SchemaMetaData should be used. I wonder if anyone does use it.

I'd be in support of the following:

• Change Aspect to Characteristic (clearer) and make it a top-level class, which seems reasonable to me
• Change isAspectOf to the inverse hasCharacteristic - note this also changes the direction. One is generally going to ask "What characteristics does this pipe (or pipes generally) have?" rather than "Which (types of) things have an inner diameter?" See issue Deprecate isAspectOf, add hasAspect #603.
• In order to avoid confusion, rename isCharacterizedAs. This was never a good name anyway, since nothing about it suggests domain Event and domain Behavior. Or preferably just drop it altogether - it's not clear what the value of such a narrowly-defined predicate is or what the expected use cases are.
• Possibly: define range of hasCharacteristic to Characteristic - see issue Add domain Aspect to gist:isAspectOf #529.

[uscholdm]

DEFERRED: until there is a revision to units and magnitudes in a future major release. #697

[uscholdm]

I no longer think that is it useful to make CoherentUnit a subclass of Category. It can be thought of as a category but all units, coherent units included, are just magnitudes used in a special way. So UnitOfMeasure should be a subclass of Magnitude. See #782

[rjyounes]

Closing - will be handled in units and measures model.