Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CIMXML converting strategy (re Model) #116

Open
Sveino opened this issue Oct 25, 2024 · 4 comments
Open

CIMXML converting strategy (re Model) #116

Sveino opened this issue Oct 25, 2024 · 4 comments
Labels
instance Pertains to instance data spec Need to also change some standard or specification urlpolicy Considerations about URL/namespace/folder/filename design/carving

Comments

@Sveino
Copy link
Owner

Sveino commented Oct 25, 2024

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.
@Sveino Sveino added spec Need to also change some standard or specification urlpolicy Considerations about URL/namespace/folder/filename design/carving labels Oct 25, 2024
@VladimirAlexiev VladimirAlexiev added the instance Pertains to instance data label Oct 25, 2024
@griddigit-ci
Copy link
Collaborator

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
Copy link
Collaborator

VladimirAlexiev commented Oct 26, 2024

@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
Copy link
Owner Author

Sveino commented Oct 28, 2024

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
Copy link
Collaborator

VladimirAlexiev commented Nov 1, 2024

Decision:

@VladimirAlexiev VladimirAlexiev changed the title CIMXML converting strategy CIMXML converting strategy (re Model) Dec 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
instance Pertains to instance data spec Need to also change some standard or specification urlpolicy Considerations about URL/namespace/folder/filename design/carving
Projects
None yet
Development

No branches or pull requests

3 participants