leverage QUDT to represent quantity kinds and units

[VladimirAlexiev]

The latest CIM version that I have (2022-07) eg IEC61970-600-2_CGMES_3_0_1_ApplicationProfiles\v3.0\RDFSEd2Beta\RDFS\IEC61970-600-2_CGMES_3_0_0_RDFS_501Ed2CD_EQ.rdf defines data properties something like this:

cim:ACDCConverter.idleLoss
        rdf:type         owl:FunctionalProperty , owl:DatatypeProperty ;
        rdfs:domain      cim:ACDCConverter ;
        rdfs:label       "idleLoss"@en ;
        rdfs:range       cim:ActivePower ;
        skos:definition  "Active power loss in pole at no power transfer. It is converter’s configuration data used in power flow. The attribute shall be a positive value."@en .

cim:ActivePower  rdf:type  owl:Class ;
        rdfs:label        "ActivePower"@en ;
        eq:Package        "Package_CoreEquipmentProfile" ;
        eq:isCIMDatatype  "True" ;
        skos:definition   "Product of RMS value of the voltage and the RMS value of the in-phase component of the current."@en .

cim:ActivePower.multiplier
        rdf:type     owl:FunctionalProperty , owl:DatatypeProperty ;
        rdf:value    "M" ;
        rdfs:domain  cim:ActivePower ;
        rdfs:label   "multiplier"@en ;
        rdfs:range   cim:UnitMultiplier ;
        eq:isFixed   "True " .

cim:ActivePower.unit  rdf:type  owl:FunctionalProperty , owl:DatatypeProperty ;
        rdf:value    "W" ;
        rdfs:domain  cim:ActivePower ;
        rdfs:label   "unit"@en ;
        rdfs:range   cim:UnitSymbol ;
        eq:isFixed   "True " .

cim:ActivePower.value
        rdf:type     owl:FunctionalProperty , owl:DatatypeProperty ;
        rdfs:domain  cim:ActivePower ;
        rdfs:label   "value"@en ;
        rdfs:range   xsd:float .

There are serious problems with this representation:

• Instance data only ever carries numbers (xsd:float), not any of the "decorations" declared by its "datatype" class cim:ActivePower (unit, multiplier, etc).
• This is borne by the property kind owl:DatatypeProperty. But cim:ActivePower is a class, so it cannot be the range of a data property
• Since there are no ActivePower individuals, it's not a class. It's a QuantityKind (borrowing a term from QUDT)
• There's no good reason to define unit "W" and multiplier "M" just for ActivePower because the same "MW" is used for many other kinds of "Power"

A week ago you had a presentation of QUDT and I assume you liked it. Here's what info QUDT includes about these items:

<http://qudt.org/vocab/unit/MegaW>
  rdf:type <http://qudt.org/schema/qudt/Unit> ;
  <http://qudt.org/schema/qudt/applicableSystem> <http://qudt.org/vocab/sou/CGS> ;
  <http://qudt.org/schema/qudt/applicableSystem> <http://qudt.org/vocab/sou/CGS-EMU> ;
  <http://qudt.org/schema/qudt/applicableSystem> <http://qudt.org/vocab/sou/CGS-GAUSS> ;
  <http://qudt.org/schema/qudt/applicableSystem> <http://qudt.org/vocab/sou/PLANCK> ;
  <http://qudt.org/schema/qudt/applicableSystem> <http://qudt.org/vocab/sou/SI> ;
  <http://qudt.org/schema/qudt/conversionMultiplier> 1.0e06 ;
  <http://qudt.org/schema/qudt/hasDimensionVector> <http://qudt.org/vocab/dimensionvector/A0E0L2I0M1H0T-3D0> ;
  <http://qudt.org/schema/qudt/hasQuantityKind> <http://qudt.org/vocab/quantitykind/ActivePower> ;
  <http://qudt.org/schema/qudt/hasQuantityKind> <http://qudt.org/vocab/quantitykind/Power> ;
  <http://qudt.org/schema/qudt/prefix> <http://qudt.org/vocab/prefix/Mega> ;
  <http://qudt.org/schema/qudt/symbol> "MW" ;
  <http://qudt.org/schema/qudt/ucumCode> "MW"^^<http://qudt.org/schema/qudt/UCUMcs> ;
  <http://qudt.org/schema/qudt/uneceCommonCode> "MAW" ;
  rdfs:isDefinedBy <http://qudt.org/2.1/vocab/unit> ;
  rdfs:label "MegaW"@en ;
.

(Sorry this uses long URLs: I got it from https://qudt.org/vocab/unit/MegaW, since the downloaded version 2.1 of 2020-11 that I have is poorer). As you see, it has all the info from CIM above, plus a lot more: links to UNECE and UCUM, prefix and conversionMultiplier, dimension vector, and which quantityKinds it applies to.

Its sibling unit "megawatt per hour" has a bit more info: also link to IEC CDD ("0112/2///62720#UAA225" is called an IRDI).

unit:MegaW-HR
  a qudt:Unit ;
  qudt:conversionMultiplier 3.6e+09 ;
  qudt:conversionOffset 0e+00 ;
  qudt:hasDimensionVector qkdv:A0E0L2I0M1H0T-2D0 ;
  qudt:hasQuantityKind quantitykind:Energy ;
  qudt:iec61360Code "0112/2///62720#UAA225" ;
  qudt:plainTextDescription "1 000 000-fold of the product of the SI derived unit watt and the unit hour" ;
  qudt:ucumCode "MW.h"^^qudt:UCUMcs ;
  qudt:uneceCommonCode "MWH" ;
  rdfs:isDefinedBy <http://qudt.org/2.1/vocab/unit> ;
  rdfs:label "Megawatt Hour"@en ;
.

Here's the quantityKind:

quantitykind:ActivePower
  a qudt:QuantityKind ;
  dcterms:description "\\(Active Power\\) is, under periodic conditions, the mean value, taken over one period \\(T\\), of the instantaneous power \\(p\\). In complex notation, \\(P = \\mathbf{Re} \\; \\underline{S}\\), where \\(\\underline{S}\\) is \\(\\textit{complex power}\\)\"."^^qudt:LatexString ;
  qudt:hasDimensionVector <http://qudt.org/vocab/dimensionvector/A0E0L2I0M1H0T-3D0> ;
  qudt:informativeReference "http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=131-11-42"^^xsd:anyURI ;
  qudt:informativeReference "http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=31891"^^xsd:anyURI ;
  qudt:latexDefinition "\\(P = \\frac{1}{T}\\int_{0}^{T} pdt\\), where \\(T\\) is the period and \\(p\\) is instantaneous power."^^qudt:LatexString ;
  qudt:symbol "P" ;
  rdfs:isDefinedBy <http://qudt.org/2.1/vocab/quantitykind> ;
  rdfs:label "Active Power"@en ;
  rdfs:seeAlso quantitykind:ComplexPower ;
  rdfs:seeAlso quantitykind:InstantaneousPower ;
  skos:broader quantitykind:ComplexPower ;
  qudt:applicableUnit unit:GigaW, unit:KiloW, unit:MegaW, unit:MicroW, unit:MilliW, unit:NanoW, unit:PicoW, unit:TeraW, unit:W
.

Or see https://qudt.org/vocab/quantitykind/ActivePower for a bit more info and rendered formulas.

---

My proposal is to:

• leverage QUDT,
• correctly define the range of the data prop and use hasQuantityKind and applicableUnit to bind to those characteristics
  • There's also qudt:unit but it would be used in an observation that doesn't leverage the default unit
• only keep a CIM node for the quantityKind because you have an electricity-specific definition for it.
  • Link them by skos:exactMatch because owl:sameAs semantics would merge (smush) their characteristics.
  • You see that quantityKinds use skos:broader to make a hierarchy, so using
  • You could repeat some of the QUDT data about quantityKind (eg the dimensionVector etc) but I think there's no need

cim:ACDCConverter.idleLoss
        rdf:type         owl:FunctionalProperty , owl:DatatypeProperty ;
        rdfs:domain      cim:ACDCConverter ;
        rdfs:label       "idleLoss"@en ;
        rdfs:range       xsd:float;
        qudt:unit        unit:MegaW;
        qudt:hasQuantityKind cim:ActivePower ;
        skos:definition  "Active power loss in pole at no power transfer. It is converter’s configuration data used in power flow. The attribute shall be a positive value."@en .

cim:ActivePower  rdf:type  qudt:QuantityKind ;
        rdfs:label        "ActivePower"@en ;
        eq:Package        "Package_CoreEquipmentProfile" ;
        eq:isCIMDatatype  "True" ;
        skos:definition   "Product of RMS value of the voltage and the RMS value of the in-phase component of the current."@en;
        skos:exactMatch   quantitykind:ActivePower
.

Not only this representation is more correct, it's also a lot simpler than above! It will cut the number of "UoM related terms" from 5n to 2n.

[Sveino]

I like this a lot. This is fairly inline with what I expected. This mean that we only need to include the float value in the instance file. I am a bit on and off on the challenge if we should support the possibility to support both MW and kW as unit for the same profile. In that case we would have to include the unit in the instance file. It would be good if we are documenting how this could be done to show that we evaluated this option. I personally think this would be the best solution.

[bartkl]

Great ideas, excited to see CIM moving this way. I have some questions and thoughts.

@VladimirAlexiev I believe the qudt:applicableUnit property is intended to be derived, not explicitly specified. Its comments point to a good explanation of this here.

Furthermore you speak of leveraging the "default unit" for a certain quantity kind. Can you tell me where this default is specified? It seems you mean qudt:applicableUnit but I don't think that servess as a default (it also tends to be multivalued).

---

I am a bit on and off on the challenge if we should support the possibility to support both MW and kW as unit for the same profile. In that case we would have to include the unit in the instance file.

@Sveino That's an interesting point. My first hunch would be to support the flexibility of providing units in the instance data. If left out in the instance data, a default from the ontology can be inferred (if possible).

Finally, are you aware there's also a QUDT SHACL schema? I'd imagine extending the SAHCL validation of the profile with some statements/rules that verify the correct use of units etc. that are specific to a specific profile is highly desired. Not only does it seem more suitable, I also believe it would be more useful, since I'd say fewer people use OWL reasoners than SHACL validators. (Note that I'm not arguing only OWL or only SHACL be used; both could play their own suitable role. Just thinking oud loud.)

[Sveino]

That's an interesting point. My first hunch would be to support the flexibility of providing units in the instance data. If left out in the instance data, a default from the ontology can be inferred (if possible). @bartkl remember that we are not really limiting the use of CIM in the semantic web space, but rather for the object oriented implementation. I like flexibility - but that come with a cost. Our current position is that we can defined the unit in the profile.

Finally, are you aware there's also a QUDT SHACL schema? No, but SHACL rules should in general be associated with a profile rather than a vocabulary. There are work being done on QUDT to support reasoning described in OWL. Agree that one does not exclude the other - but they have different purpose.

[bartkl]

@Sveino Clear. And yes I agree SHACL should not be used for the vocabulary, I was talking about using SHACL for use in profiles. Just wanted to point out that there exists a QUDT SHACL model we can use for validating profiles.

[Sveino]

@bartkl Can you add a link tot eh QUDT SHACL?

[bartkl]

@Sveino: QUDT SHACL graph: https://qudt.org/2.1/schema/shacl/qudt

[VladimirAlexiev]

@bartkl You're right, qudt:applicableUnit is not intended for this, I fixed my last code block to use qudt:unit.

"default unit" for a certain quantity kind. Can you tell me where this default is specified?

That would be the inverse of qudt:derivedCoherentUnitOfSystem "unit system in which the unit is derived from the system's base units with a proportionality constant of one".

I think these are the units with conversionMultiplier=1.0, eg that is the case for https://qudt.org/vocab/unit/W . But I'll check for all: see (https://github.com/qudt/qudt-public-repo/issues/952).

[VladimirAlexiev]

@bartkl, https://qudt.org/2.1/schema/shacl/qudt is quite big and not modular: https://github.com/qudt/qudt-public-repo/issues/953

[VladimirAlexiev]

https://github.com/Sveino/Inst4CIM-KG/issues/29 is very similar to this but addresses some other aspects.