no connection of CIM nodes to model

[VladimirAlexiev]

If you convert Nordic44_CGM_36d_SSH.xml to ttl, you see this:

<urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586>
        rdf:type                       md:FullModel ;
        md:Model.DependentOn           <urn:uuid:2dd9014f-bdfb-11e5-94fa-c8f73332c8f4> ;
        md:Model.created               "2017-11-24T09:03:09.9446768Z" ;
        md:Model.description           "CGM Test model developed by Statnett SF. Nordic 44 bus system for the Nordic region" ;
        md:Model.modelingAuthoritySet  "http://www.Statnett.no/IGM/Nordic44_CGM" ;
        md:Model.profile               "http://entsoe.eu/CIM/SteadyStateHypothesis/1/1" , "http://entsoe.eu/CIM/SteadyStateHypothesis/1/2" ;
        md:Model.scenarioTime          "2015-03-06T01:30:00.0000000Z" ;
        md:Model.version               "36" ;
        pti:Model.createdBy            "Statnett SF" .

<file:///d:/Onto/proj/electrical/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_e2f56599-a78e-494f-8db3-c0b0bdab1d70>
        rdf:type                    cim:Terminal ;
        cim:ACDCTerminal.connected  "true" .

• CIM nodes use relative URLs, which is bad (#5)
• The model uses a URN. This is ok, although a resolvable URL is better
• Most importantly, there's no relation between CIM nodes and the model whatsoever. The fact that you've put them in one file doesn't matter a bit. If you load this file to a repo, these triples will be mixed with millions of other triples. losing all connection

One way to solve this is:

• use named graphs, where the model URN is also the graph name (URN)
• load all triples into that graph (the model triples could be inside or outside of the graph, depending on needs)

You could express this in TriG as follows (also fixed the relative URL to a URN):

graph <urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586> {
  <urn:uuid:1d8b61bc-c7f3-4e9e-a3bd-f4ec24beb586>
        rdf:type                       md:FullModel ;
        md:Model.DependentOn           <urn:uuid:2dd9014f-bdfb-11e5-94fa-c8f73332c8f4> ;
        md:Model.created               "2017-11-24T09:03:09.9446768Z" ;
        md:Model.description           "CGM Test model developed by Statnett SF. Nordic 44 bus system for the Nordic region" ;
        md:Model.modelingAuthoritySet  "http://www.Statnett.no/IGM/Nordic44_CGM" ;
        md:Model.profile               "http://entsoe.eu/CIM/SteadyStateHypothesis/1/1" , "http://entsoe.eu/CIM/SteadyStateHypothesis/1/2" ;
        md:Model.scenarioTime          "2015-03-06T01:30:00.0000000Z" ;
        md:Model.version               "36" ;
        pti:Model.createdBy            "Statnett SF" .

  <urn:uuid:e2f56599-a78e-494f-8db3-c0b0bdab1d70>
        rdf:type                    cim:Terminal ;
        cim:ACDCTerminal.connected  "true" .
}

[Sveino]

Yes, I totally agree. In addition to use name graph we would like to replace the header information with DCAT3 /PROV attributes. See example on JSON-LD (work-in-progress) : https://github.com/Sveino/Nordic44/blob/3-add-json-ld-example/Instances/CGMES_3_0/JSON-LD/InitialCase/Nordic44-30-HV1_DL.json

The think is that the same information are added to the Data catalog. Some is promoting that there should not be any header (model data) in the graph dataset. I am a bit turn on this. We are evaluating if we should exchange a Manifest dataset that include the header information and the provenance.