Align NC instance file to both CGMES 2.4 and CGMES 3.0

[Sveino]

CGMES Network Code (NC) instance data will follow the same namespace that will be used for the CIMJSON-LD. However, we need to defined a machine-understandable structure and syntax to explain the mapping between the namespaces. In addition, we would like that the same Network Code instance file should work with CGMES 2.4 (CIM16) and CGMES 3.0 (17).

@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:    <http://www.w3.org/2002/07/owl#> .
@prefix cim:    <https://cim.ucaiug.io/ns#> .
@prefix cim16:  <http://iec.ch/TC57/2013/CIM-schema-cim16#> .
@prefix cim17:  <http://iec.ch/TC57/CIM100#> .

cim:Equipment owl:equivalentClass cim16:Equipment .
cim16:Equipment owl:equivalentClass cim:Equipment .
cim:Equipment owl:equivalentClass cim17:Equipment .
cim17:Equipment owl:equivalentClass cim:Equipment .

[VladimirAlexiev]

Equivalences like this are not free!

• (you don't need equivalentClass in both directions since it's symmetric by definition)
• If you declare this, every equipment node will get 3 types. To deal with these types, queries will need to be a lot more complex
• You'd also need to declare equivalentProperty for each prop, with further complications for queries
• This will multiply x3 the number of triples

I think the more feasible approach is to write SPARQL updates that migrate a database from the older to the newest namespace.

Furthermore, equivalences don't express the idea of migrating namespaces across versions (16->17->18) because:

• they are symmetric
• mapping individual terms is not the same as mapping whole namespaces. If one of the classes was missed, would it mean the same or different thing?

ps: I see I said the same (but in more detail) in #70

[Sveino]

"There’s No Such Thing as a Free Lunch" The alternative is that we have everything duplicated three times and use sameAs. In the future we need to implement this by versioning of the vocabulary. Now we have - in the context of Semantic Web three different ontologies. For OOP tool vendors they will have one internal datamodell that they would need to map to three different namespace. In the context of NC they need to use cim: <https://cim.ucaiug.io/ns#> in the context of CGMES 3.0 cim: <http://iec.ch/TC57/CIM100#> and in the context CGMES 2.4 cim: <http://iec.ch/TC57/2013/CIM-schema-cim16#>

We need to find a way to inform the tools - as we want everything to be data/schema driven. We can come up with our own mapping or try to re-use something from Semantic web.

As part of KG we would need to evaluate the best way to execute this. Primarily we are now looking into SHACL validation that can support multiple versions.

Good point that the operation is symmetric:

@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:    <http://www.w3.org/2002/07/owl#> .
@prefix cim:    <https://cim.ucaiug.io/ns#> .
@prefix cim16:  <http://iec.ch/TC57/2013/CIM-schema-cim16#> .
@prefix cim17:  <http://iec.ch/TC57/CIM100#> .

cim:Equipment owl:equivalentClass cim16:Equipment .
cim:Equipment owl:equivalentClass cim17:Equipment .

This statement does not cover all the requirement in regards to the migrating namespaces across versions (16->17->18). However, this solution will be based on the fact that there will be different version of the same namespace.

[griddigit-ci]

Vlado, I was thinking that it is possible to define "mapping" or basically a transformation technique between 2 graphs (e.g. the graphs of the RDFS) by using SPARQL as we can also express mathematical relationship between properties. I attempted to so a small sample which I can try to find. What do you think for such an idea?

Perhaps this is a bit bigger scope than what is in this issue

[VladimirAlexiev]

• In metadata (or the ontologies), we can state

  cim:Equipment           dct:replaces cim16:Equipment, cim17:Equipment. # class
  cim:Equipment.inService dct:replaces cim17:Equipment.inService. # prop that was added in cim17

• From such declarations, we can generate SPARQL Updates to migrate (of course, we can use VALUES lists):

  
  insert {
  graph <new-graph> {
  ?x a cim:Equipment ?y
  }
  } where {
  graph <old-graph> {
  ?x a cim17:Equipment
  }
  };

insert { graph { ?x cim:Equipment.inService ?y } } where { graph { ?x cim17:Equipment.inService ?y } };

- We could also do this with GraphDB rules. The benefit is that if you change the value of `cim17:Equipment.inService` in `<old-graph>`, it will be automatically propagated to `cim:Equipment.inService` in `<new-graph>`