Replace 'equivalentClass' definitions of 'Unit' sublasses with 'subclass' and 'type' statements
Opened this issue · 0 comments
jmkeil commented
Currently, (almost) all subclasses of unit are equivalent to a union of some prefixed unit classes and a oneOf class.
Example:
<owl:Class rdf:about="&om;AreaUnit">
<rdfs:label xml:lang="en">area unit</rdfs:label>
<rdfs:subClassOf rdf:resource="&om;Unit"/>
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class>
<owl:oneOf rdf:parseType="Collection">
<om:Unit rdf:about="&om;acre-International"/>
<om:Unit rdf:about="&om;acre-USSurvey"/>
<om:Unit rdf:about="&om;are"/>
<om:Unit rdf:about="&om;barn"/>
<om:Unit rdf:about="&om;circularMil"/>
<om:UnitExponentiation rdf:about="&om;squareMetre"/>
<om:UnitExponentiation rdf:about="&om;squareInch-International"/>
<om:UnitExponentiation rdf:about="&om;squareFoot-International"/>
<om:UnitExponentiation rdf:about="&om;squareYard-International"/>
<om:UnitExponentiation rdf:about="&om;squareMile-International"/>
</owl:oneOf>
</owl:Class>
<owl:Class rdf:about="&om;PrefixedAre"/>
<owl:Class rdf:about="&om;SquarePrefixedMetre"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
</owl:Class>
I propose to replace these definitions with rdf:type and rdfs:subClass statements.
Example:
<owl:Class rdf:about="&om;AreaUnit">
<rdfs:label xml:lang="en">area unit</rdfs:label>
<rdfs:subClassOf rdf:resource="&om;Unit"/>
</owl:Class>
and (in Turtle for the sake of simplicity)
om:acre-International rdf:type om:AreaUnit .
om:acre-USSurvey rdf:type om:AreaUnit .
om:are rdf:type om:AreaUnit .
om:barn rdf:type om:AreaUnit .
om:circularMil rdf:type om:AreaUnit .
om:squareMetre rdf:type om:AreaUnit .
om:squareInch-International rdf:type om:AreaUnit .
om:squareFoot-International rdf:type om:AreaUnit .
om:squareYard-International rdf:type om:AreaUnit .
om:squareMile-International rdf:type om:AreaUnit .
om:PrefixedAre rdfs:subClassOf om:AreaUnit .
om:SquarePrefixedMetre rdfs:subClassOf om:AreaUnit .
Reasons:
- The current statements are to strong, as they exclude the existence of further units. They assume OM is 100% complete and that makes reuse more difficult, as one cannot add a unit without changing OM statements (#66).
- These strong statements cause higher reasoning complexity (#79).
The required changes could probably be done with a few SPARQL UPDATE queries, given OM would uses a common serialization style (#80).