Misuse of inheritance (rdfs:subClassOf)-relations

[wsw2016]

Requirements to an ontology model:

• Ontology represents a "contract" between data-producer and data-consumer, so that both understand the same under the objects, object-property and data types.
• The objective of the model is too doubtless document the meaning of objects and object-properties.
• The meaning of the object-attribute consists of four aspects:
  • container object
  • property name
  • property type (data type or a class)
  • documentation of the meaning of that property to that object (as text and drawings).

Following these objectives, the simplest way to model data is to handle each object separately:

• Each property can be documented precisely as meant to be used with this specific object (e.g. documentation of the Switch.length and Track.length must be different, even if the use the same property name and property type).
• All properties will be documented explicitly.

The drawback of this approach, that it is not compact. In some cases, the objects use identical properties = [same property name, same property type, same property documentation] e.g. Switch.id and Track.id fulfill all three aspects. In such cases, a more abstract class can be constructed, e.g. IdentifiableElement having an attribute id: string, from which the more specific classes can be inherited. If the inheritance is used for “grouping” object-attributes, which don’t share name, type and documentation, the resulting inheritance-graph violates the requirements on the ontology (s. above). Example of issue in the 3.1.0-ontology with only one object Switch

• Switch.hasGeometry of type Sf.Multipolygon
• Switch.hasGeometry of type Sf.LineString
• Switch.hasParameter of type era.InfraSubsystem
• Switch.hasParameter of type era.EnergySubsystem
• Switch.hasParameter of type era.CCSSubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.InfraSubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.EnergySubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.CCSSubsystem
• Switch.isPartOf.parameter of type era.InfraSubsystem
• Switch.isPartOf.parameter of type era.EnergySubsystem
• Switch.isPartOf.parameter of type era.CCSSubsystem
• Switch.hasAbstraction of type LinearElement
• Switch.hasAbstraction of type NonlinearElement
• Switch.hasAbstraction.hasLocation of type LinearLocation
• Switch.hasAbstraction.hasLocation of type AreaLocation

All these object properties are introduced via inheritance. There are two issues with that:

• Most of the object properties are not intended to be used with the object “Switch” and must be prevented by using of addition means (e.g. shacl).
• The documentation (text and drawings) of many of these properties must be different from those defined for Track, Signal, Platform etc.

Conclusion: inherited classes exactly share all properties of the abstract class = same name, same type, same unambiguous documentation. If one of them does not fit, the object should not be inherited.

[Airy59]

Hi Stefan,

My short recommendation here would be the definition of subproperties where relevant; subproperties refine the semantics of properties (just as subclasses refine the semantics of classes).

SHACL constraints should not be misused for fixing ambiguous semantics.

Of course a switch can have several geometries associated with it, e.g. according to level of detail, source document, observation etc. These geometries may well be linestrings (schematic view) or polygons (asset boundaries). If these geometries are not used in the context of RINF, a RINF-specific SHACL shape could indeed be added to "filter them out". In that case, SHACL is indeed adapting the incoming knowledge to the particular RINF use case, not altering the knowledge and not preventing other usages.

Concerning documentation, TRANSMODEL and EULYNX DataPrep (as published) are a fine source for inspiration.

[gatemezing]

Requirements to an ontology model:

• Ontology represents a "contract" between data-producer and data-consumer, so that both understand the same under the objects, object-property and data types.
• The objective of the model is too doubtless document the meaning of objects and object-properties.

I am not sure to agree with you on the definition, although there is a need to document an ontology for reuse purpose. The definition I like the most of an ontology is the following " A formal and explicit representation of a shared conceptualization" . It is important that we are in an Open World Assumption (OWA) compared to Closed World Assumption (CWA) as it is the case in traditional DB.

[gatemezing]

Example of issue in the 3.1.0-ontology with only one object Switch

• Switch.hasGeometry of type Sf.Multipolygon
• Switch.hasGeometry of type Sf.LineString
• Switch.hasParameter of type era.InfraSubsystem
• Switch.hasParameter of type era.EnergySubsystem
• Switch.hasParameter of type era.CCSSubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.InfraSubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.EnergySubsystem
• Switch.hasSetOfParameters.subsetWithCommonCharacteristics.parameter of type era.CCSSubsystem
• Switch.isPartOf.parameter of type era.InfraSubsystem
• Switch.isPartOf.parameter of type era.EnergySubsystem
• Switch.isPartOf.parameter of type era.CCSSubsystem
• Switch.hasAbstraction of type LinearElement
• Switch.hasAbstraction of type NonlinearElement
• Switch.hasAbstraction.hasLocation of type LinearLocation
• Switch.hasAbstraction.hasLocation of type AreaLocation

I disagree with this way of reading/inferring based on the ontology. See again OWA paradigm. Of couse, I understand the need of "closing the world" with explicit axioms or SHACL rules.