define needed reasoning

[VladimirAlexiev]

@Sveino talks of "RDFSPlus" and the repo refers to http://mlwiki.org/index.php/RDFS-Plus, but

• that's not any official spec
• there are some mistakes
• it includes more than we need

So instead, let's specify explicitly what reasoning is needed by CIM.

rdfs:subClassOf

• SHACL needs it, it says it with a lot of circumlocution (legacy of PFPS), so you have to follow this chain:
  https://www.w3.org/TR/shacl/#ClassConstraintComponent
  https://www.w3.org/TR/shacl/#dfn-shacl-instance
  https://www.w3.org/TR/shacl/#dfn-shacl-types
  https://www.w3.org/TR/shacl/#dfn-shacl-superclass
• AFAIK, the shapes about cim:IdentifiedObject are not attached to all subclasses thereof, but are expected to apply
• Widely used in CIM:

grep -c subClass */*/*
CGMES-NC/ttl/AssessedElement-AP-Voc-RDFS2020.ttl:1
CGMES-NC/ttl/AvailabilitySchedule-AP-Voc-RDFS2020.ttl:11
CGMES-NC/ttl/Contingency-AP-Voc-RDFS2020.ttl:6
CGMES-NC/ttl/EquipmentReliability-AP-Voc-RDFS2020.ttl:177
CGMES-NC/ttl/GridDisturbance-AP-Voc-RDFS2020.ttl:10
CGMES-NC/ttl/Header-AP-Voc-RDFS2020.ttl:2
CGMES-NC/ttl/ImpactAssessmentMatrix-AP-Voc-RDFS2020.ttl:8
CGMES-NC/ttl/MonitoringArea-AP-Voc-RDFS2020.ttl:6
CGMES-NC/ttl/ObjectRegistry-AP-Voc-RDFS2020.ttl:0
CGMES-NC/ttl/PowerSchedule-AP-Voc-RDFS2020.ttl:4
CGMES-NC/ttl/PowerSystemProject-AP-Voc-RDFS2020.ttl:2
CGMES-NC/ttl/RemedialAction-AP-Voc-RDFS2020.ttl:51
CGMES-NC/ttl/RemedialActionSchedule-AP-Voc-RDFS2020.ttl:18
CGMES-NC/ttl/SecurityAnalysisResult-AP-Voc-RDFS2020.ttl:2
CGMES-NC/ttl/SensitivityMatrix-AP-Voc-RDFS2020.ttl:1
CGMES-NC/ttl/StateInstructionSchedule-AP-Voc-RDFS2020.ttl:29
CGMES-NC/ttl/SteadyStateHypothesisSchedule-AP-Voc-RDFS2020.ttl:42
CGMES-NC/ttl/SteadyStateInstruction-AP-Voc-RDFS2020.ttl:12
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_DL.ttl:9
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_DY.ttl:258
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_EQ.ttl:175
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_EQBD.ttl:21
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_GL.ttl:5
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_OP.ttl:35
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_SC.ttl:33
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_SSH.ttl:71
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_SV.ttl:11
CGMES/ttl/IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_TP.ttl:9

owl:inverseOf

• Each CIM object prop has an inverse.
• There's no preference of one direction to the other, so either can be present.
  But because SHACL must check one or the other direction, both must be present
• need to do replace cims:inverseRoleName by owl:inverseOf #26

SymmetricProperty ?

inverseOf is a SymmetricProperty.
Having Symmetric reasoning will facilitate inverse reasoning, even if inverseOf is stated on only one direction.

This defect appears only for dcat:Dataset.publisher - dcat:Dataset.Resource11:

PREFIX cims: <http://iec.ch/TC57/1999/rdf-schema-extensions-19990926#>
select * {
  ?x cims:inverseRoleName ?y
  filter not exists {?y cims:inverseRoleName ?x}
}

Symmetric reasoning is a subset of inverse reasoning (symmetric props are self-inverses),
so we can accomplish the same if we just have this axiom:

inverseOf inverseOf inverseOf

Nothing else

• rdfs:domain: AFAIK no CIM node is instantiated without class, and subClassOf will infer all relevant superclasses
  Please confirm
• rdfs:range:
  • for ObjectProperties, same as rdfs:domain
  • but for literals: Add Datatypes To Instance Data #49
• FunctionalProperty, InverseFunctionalProperty: express single-value props as owl:FunctionalProperty #30
  • But we don't want to infer owl:sameAs from these prop assertions.
• subPropertyOf: this finds nothing

grep subProperty */*/*

• Transitive: unheard of

[Sveino]

I agree that RDFS-Plus might not be well defined, and we should make sure that we know which one we should support.
There is primary two aims:

1. Remove the need for using cims replace cims:inverseRoleName by owl:inverseOf #26 (as one example)
2. Limited the owl support to what can be supported (or needed to be supported) by on OOP bases application

The minimum support is:

• owl:Class
• owl:inverseOf
• owl:FunctionalProperty
• owl:DatatypeProperty

What we would need to considerer:

• owl:InverseFunctionalProperty (for the use of mRID as identification)
• owl:TransitiveProperty can be useful in regards to option association, e.g. if you contain a Generator to a given Substation it implies that all part that is part of a Generator must also be contain in the same Substation.
• owl:sameAs might be relevant in regards to nameaspaces (I will open an issue on this)
• owl:equivalentClass might be relevant in regards to transition form one CIM version to the next and for alignment with other standards.

[VladimirAlexiev]

@Sveino What vocabulary you use and what reasoning you want (need for particular use cases) are different things.

• AFAIK, Class, ObjectProperty, DatatypeProperty don't imply any reasoning
• FunctionalProperty, InverseFunctionalProperty imply "sameAs", not constraints.
• TransitiveProperty is often useful, but it also makes sense to distinguish a "step" prop vs its transitive closure. An example are broader vs broaderTransitive in SKOS
• sameAs might be useful if different parties mint different URLs about the same thing, but it also adds complications.
  IMHO the better way is to mandate specific/reproducible URLs, eg based on EIC

[VladimirAlexiev]

makes sense to distinguish a "step" prop vs its transitive closure.

Unfortunately RDF doesn't make a distinction between direct and inferred rdfs:subClassOf and rdf:type.

The CIM class hierarchy is deep and includes many abstract classes.
To fetch the specific (directly asserted) type of a power system resource, queries will need to use database-specific extensions.
As per w3c/sparql-dev#124:

• in rdf4j: sesame:directType
• in jena: urn:x-hp-direct-predicate:http_//www.w3.org/1999/02/22-rdf-syntax-ns#

I bet vendors will not jump with joy at this complication.

This is an example that "there is such thing as TOO MUCH reasoning":
one should always consider the specific consequences of using specific reasoning.