CIMXML converting strategy

[Sveino]

Issue Summary: The current format of CIMXML is incompatible with standard RDF/XML syntax and the envisioned structure of CIM JSON-LD. To effectively use SHACL validation (e.g., for cim:Datatypes), we need to convert CIM XML, particularly its header information, into a format and structure compatible with standard RDF syntax. This conversion approach presents two main alternatives:

Alternative Approaches:

1. Minimal Conversion
2. Full Conversion to Match CIM JSON-LD

Option 1: Minimal Conversion

• Advantages:

  • Less Dependency on CIM JSON-LD Design Decisions: This approach allows us to proceed without needing a finalized specification for CIM JSON-LD.
  • Limited Conversion Requirements: Performs only essential transformations, sufficient for retrieving data from graph storage.

• Disadvantages:

  • SHACL Rule Updates Needed: The SHACL rules will need to accommodate the partially converted CIM XML, which might differ from standard RDF syntax and CIM JSON-LD.
  • Post-Conversion Benchmarking: Each SHACL engine would need post-conversion testing to ensure compatibility, adding complexity if the conversion approach varies between engines.

Option 2: Full Conversion to CIM JSON-LD Format

• Advantages:

  • Compatibility with CIM JSON-LD: Aligns directly with the CIM JSON-LD structure, enabling standardized SHACL rule application without requiring format adjustments.
  • Simplified SHACL Testing and Validation: Full conversion minimizes the need for separate testing or custom conversion per SHACL engine.
  • No need for update when we move to CIM JSON-LD.

• Disadvantages:

  • Dependency on CIM JSON-LD Design: This approach would require some level of finalizing the CIM JSON-LD structure, potentially delaying implementation if specifications are still evolving. However, this is done for the header, but not for the difference model.

[griddigit-ci]

Indeed the preference would be option 2. I had the impression that we started formulating this in the JSON-LD context that will somehow be a thing that is referenced and not directly included in each of the instances.

[VladimirAlexiev]

@Sveino Whatever you decide about representing Models, you should use the same ontology terms in CIM XML and JSONLD. Otherwise you'll make it more impossible to use standard RDF tools, and will create confusion. You cannot be "DCAT compliant" in one representation, but "not compliant" in another.

In general I am all for ontology reuse, but not in this case:

• You have maybe 500-1000 classes. Making 1 of them reuse an existing ontology is not much of a gain
• dcat:Dataset doesn't have any special features for describing RDF datasets. VOID has such
• CIM models have several special features (DependsOn, Supersedes, forward/reverse differences) that DCAT doesn't have
• dcat:Dataset isn't related in any way to named graphs. There is a system class (I think rdfg:Graph) that we should use

JSON-LD context that will somehow be a thing that is referenced and not directly included in each of the instances.

Yes, the ontologies currently have

@context: https://rawgit2.com/Sveino/Inst4CIM-KG/develop/rdfs-improved/CIM-ontology-context.jsonld

and I'll do the same for instance data (it will be in https://rawgit2.com/Sveino/Inst4CIM-KG/develop/rdf-improved/CIM-context.jsonld)

[Sveino]

It is important that we do not get circular discussion and issue dependency. When we are talking about CIM XML and CIM JSON-LD conversion, we are not talking about syntax transformation. We are talking about new syntax version with additional meta vocabulary.
The following is key facts and decisions:

• CIM XML, describe in IEC 61970-552:2018, is not following RDF XML standard
• the current meta-model/vocabulary describe in IEC 61970-552:2018, does not support the current need
• CIM JSON-LD will describe in a new standard document, IEC 61970-553:ED1. This shall be fully compliance with the latest RDF syntax standard. Will allow for RDF XML, Turtle or any other syntax, but only -553 and -552 would have compliance testing
• Model meta vocabulary will not be described -552 or -553, but would have a separate vocabulary, for ENTSO-E we have to use DCAT for the metadata that is supported by DCAT.
• next version of -552 will not include header information. It might be updated to be fully supporting RDF XML, but this is a bit depending on how much change that involves and how CIM JSON-LD would be. The primarily point with CIM XML is to be backwards compliance,

We will be using rdfg:Graph we can use VOID or other standard RDF vocabulary.

Just to highlight one out of many requirement, we need to tag all dataset with One requirement for all datasets would be tagget with relevant security level. This is EU Publication defined as dcterms:accessRights

[VladimirAlexiev]

Decision:

• fill out https://github.com/Sveino/Inst4CIM-KG/issues/122
• add update query to cim-trig.pl, to convert from old Model terms to new dcat/dct/dcat-cim terms