search

Sveino / Nordic44

Synthetic Power System of the Nordic high voltage transmission System
Other
1 stars 0 forks source link

missing datatypes #6

Open VladimirAlexiev opened 2 years ago

VladimirAlexiev commented 2 years ago

Take a look e.g. at this node:

<file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_f176999f-9aeb-11e5-91da-b8763fd99c5f>
        rdf:type                     cim:SynchronousMachine ;
        entsoe2:Equipment.inService  "true" ;
        cim:RegulatingCondEq.controlEnabled "true" ;
        cim:RotatingMachine.p        "-611.6982" ;
        cim:RotatingMachine.q        "-131.620667" ;
        cim:SynchronousMachine.operatingMode cim:SynchronousMachineOperatingMode.generator ;
        cim:SynchronousMachine.referencePriority "0" .

It includes literals that don't have proper datatypes.

I'd assume these are appropriate datatypes

<file:///d:/Onto/proj/Nordic44/Instances/CGMES_2_4/Nordic44_CGM_36d_SSH.xml#_f176999f-9aeb-11e5-91da-b8763fd99c5f>
        rdf:type                     cim:SynchronousMachine ;
        entsoe2:Equipment.inService  "true"^^xsd:boolean ;
        cim:RegulatingCondEq.controlEnabled "true"^^xsd:boolean ;
        cim:RotatingMachine.p        "-611.6982"^^xsd:decimal ;
        cim:RotatingMachine.q        "-131.620667"^^xsd:decimal ;
        cim:SynchronousMachine.operatingMode cim:SynchronousMachineOperatingMode.generator ;
        cim:SynchronousMachine.referencePriority "0"^^xsd:integer .
VladimirAlexiev commented 2 years ago

The same holds about the model Nordic44_CPSM_01_MF.ttl: these should be xsd:dateTime:

        fw:FrameworkVersionObject.created "2018-02-23T14:42:00Z" ;
        fw:Model.validFrom           "2015-03-06T01:30:00.0000000Z" .

On the other hand, this should stay as string:

        fw:FrameworkVersionObject.version                "02" ;
Sveino commented 1 year ago

In CIM (IEC 61970-552) it is defined to not include datatype in the instance file. The reason for this was that this information is included in the RDFS. However, for JSON-LD (upcomming IEC 61970-553) we will include the datatype. The assumption you have made for the datatype are correct.

What would be the best way to get this right in GraphDB? Should we write a converter post import or can we update the datatype based on the RDFS that should been imported into GraphDB pre-import?

VladimirAlexiev commented 1 year ago

I think you got it backwards:

If the RDFS ontology declares cim:RegulatingCondEq.controlEnabled rdfs:range xsd:boolean, then cim:RegulatingCondEq.controlEnabled "true" won't comply to the ontology. The datatype won't be "inferred" from the ontology.

Yes, this can be cleaned with a SPARQL update. But I think it's better to produce clean instance files in the first place.