deprecate cims:AssociationUsed "No" props (or even delete them?)

[VladimirAlexiev]

• replace cims:inverseRoleName by owl:inverseOf #26 maps cims:inverseRole to the standard prop owl:inverseOf
• define needed reasoning #50 discusses the required reasoning.
  I thought inverseOf reasoning is required since otherwise how will SHACL and SPARQL writers know which direction of an inverse pair to use?

However, @Sveino explained that cims:AssociationUsed points out which prop of an inverse pair is actually used, eg:

cim:ACDCConverterDCTerminal.DCConductingEquipment a owl:ObjectProperty, owl:FunctionalProperty ;
  rdfs:label "DCConductingEquipment" ;
  rdfs:comment "A DC converter terminal belong to an DC converter."@en ;
  cims:AssociationUsed "Yes" ; ###########
  cims:multiplicity cims:M:1..1 ;
  owl:inverseOf cim:ACDCConverter.DCTerminals ;
  rdfs:domain cim:ACDCConverterDCTerminal ;
  rdfs:range cim:ACDCConverter .

cim:ACDCConverter.DCTerminals a owl:ObjectProperty, owl:InverseFunctionalProperty ;
  rdfs:label "DCTerminals" ;
  rdfs:comment "A DC converter have DC converter terminals. A converter has two DC converter terminals."@en ;
  cims:AssociationUsed "No" ; #############
  cims:multiplicity cims:M:0..n ;
  owl:inverseOf cim:ACDCConverterDCTerminal.DCConductingEquipment ;
  rdfs:domain cim:ACDCConverter ;
  rdfs:range cim:ACDCConverterDCTerminal .

My proposal is to make this explicit by using standard props:

cim:ACDCConverter.DCTerminals owl:deprecated true;
  skos:scopeNote "This property is not asserted in instance data. Use its owl:inverseOf property instead"@en

An even "stronger" approach would be to omit the definition of the "recessive" prop and declare only its name in the "dominant" prop:

cim:ACDCConverterDCTerminal.DCConductingEquipment prov:inverse "ACDCConverterDCTerminal.DCConductingEquipment".

This is the PROV approach: https://www.w3.org/TR/prov-o/#inverse-names.
It has been adopted in DCAT (at least in part): https://w3c.github.io/dxwg/dcat/#inverse-properties, w3c/dxwg#1336 .

However, we have rich info (owl:InverseFunctionalProperty, cims:multiplicity) that we would lose if we use a mere name.

[griddigit-ci]

Indeed the association used denotes the usage, but a bit more than that the presence in the serialised data. The "used" might be a bit broader terms as I do not know if you actually do some sort of RDFS based validation you kind of use both...

I guess this is point to discuss. Deprecate seems not that nice option as this can confuse with the meaning of deprecate we use in CIM = being it is still used, but it will be deleted in next or following versions

I may propose another approach

• as we split vocabulary and constraints we can just delete cims:AssociationUsed from the vocabulary, but we will still have the rest of information, i.e. comments, multiplicity, etc.
• as part of the SHACL constraints we find a way to validate that the inverse associations are not present in the exchange/in the instance. I am not sure if this is possible to check at SHACL level

A disadvantage is that if we remove cims:AssociationUsed we have trouble to derive constraints from RDFS to SHACL, so that part of the tooling will need additional input which we can see to supply by other means

[VladimirAlexiev]

@Sveino please state whether CIM data will use inverseOf inference

• if not then cims:AssociationUsed holds precious info: which direction is actually present in the data.
  (and this issue suggests to express this in a standard way)
• if yes then cims:AssociationUsed is less important

can confuse with the meaning of deprecate we use in CIM = being it is still used, but it will be deleted in next or following versions

• skos:scopeNote clarifies this
• we could use two subprops of owl:deprected:
  • cims:deprecatedWillBeDeletedInFuture
  • cims:deprecatedBecauseNotUsedInData

[Sveino]

I agree with Chavdar. We need to owl:inversOfand we expect that there will be reasoning to derive the association that is not included in the instance file. cims:AssociationUsed is a profile information. It will not be included in the vocabulary. It can therefore be translated into relevant SHACL validation without being included as RDFS.

[VladimirAlexiev]

Decided that:

• SHACL will continue to operate only over AssocitionUsed "Yes"
• It is possible to check in SHACL that the "wrong" (recessive) direction is not present:
  • use a sh:not [sh:property [sh:path <recessive prop>]]
  • but should put them in a separate SHACL file: to be used on file validation only, but not repository validation
• inverse reasoning is useful, in particular for querying
• but won't be demanded in the standard because that's a competitive product feature.

[griddigit-ci]

the current outcome here is that

1. We keep owl:inverseOf in the RDFS so that we have the description of the 2 association ends
2. in SHACL we use the following pattern to validate that inverse associations are not exchanged. We can use the same/similar pattern in the SHACL for the profile so that we describe used direction of the association.

dl:DiagramObjectPoint.DiagramObject-inversePresent1
rdf:type sh:NodeShape ;
            sh:property dl:DiagramObject.DiagramObjectPoints-present1;
sh:targetSubjectsOf cim:DiagramObject.DiagramObjectPoints .

dl:DiagramObject.DiagramObjectPoints-present1
rdf:type sh:PropertyShape ;
            sh:description "Inverse associations should not be instantiated" ;
            sh:message "Inverse association present" ;
sh:name "Inverse1-targetSubjectsOf" ;
            sh:maxCount       0;
sh:path cim:DiagramObject.DiagramObjectPoints;
sh:severity sh:Violation .