-
Notifications
You must be signed in to change notification settings - Fork 1
Home
(See initial modeling discussion here)
We are basically going to implement the following conversion approach. See at the end for remaining questions.
An instance of the Unit
class captures one main unit entry in the XML. It may have a primary name (via property hasName
) and zero or more aliases (via hasAlias
property).
This is a functional property to capture the <def>
element from the XML description.
This is a functional property that indicates the primary name of a given Unit
instance. In particular, a unit may not have a primary name.
Indicates an alternate name for a given Unit
instance. A unit can have zero or more aliases associated.
Indicates a symbol associated with a given Unit
instance. A unit can have zero or more symbols associated.
Instances of the UnitName
class capture a name or alias associated with an instance of a class Unit
.
With UnitName
as domain, this functional property indicates the Unit
instance associated with the name.
With UnitName
as domain, this functional property indicates whether the name is "singular"
or "plural"
.
Remarks:
- The approach clearly separates the concept of unit from any associated specific names/aliases.
- Those names/aliases will have URIs per se (so they could be self-resolvable)
Both Unit
and UnitName
instance URIs will share the same namespace. The id part for each UnitName
instance will simply be the associated name itself. This is appropriate because is both user- and web-friendly.
In the Unit
case, and avoid any collisions with the corresponding UnitName
ids, we will apply an arbitrary but deterministic translation (md5 or sha hash) of the <def>
string, and use the last 6 characters. If a collision results, add '+' to the def string and re-hash; repeat until a unique name results.
- All units must have def strings but a few may not have names.
- Collisions should be rare for the number of units involved.
The following entry from the original vocabulary:
<unit>
<def>'/60</def>
<name><singular>arc_second</singular></name>
<symbol>"</symbol>
<symbol>″</symbol> <!-- DOUBLE PRIME -->
<aliases>
<name><singular>angular_second</singular></name>
<name><singular>arcsecond</singular></name>
<name><singular>arcsec</singular></name>
</aliases>
</unit>
will result in the RDF representation:
@prefix : <http://mmisw.org/ont/mmitest/udunits2-accepted/> .
@prefix prop: <http://mmisw.org/ont/mmitest/udunits2-prop/> .
:2a1369
a :Unit ;
prop:hasDefinition "'/60" ;
prop:hasName "arc_second" ;
prop:hasAlias :arcsec, :angular_second, :arcsecond ;
prop:hasSymbol "\"", "″" ;
:arc_second
a :UnitName ;
prop:namesUnit :2a1369;
prop:hasCardinality "singular";
:arcsec
a :UnitName ;
prop:namesUnit :2a1369;
prop:hasCardinality "singular";
:angular_second
a :UnitName ;
prop:namesUnit :2a1369;
prop:hasCardinality "singular";
:arcsecond
a :UnitName ;
prop:namesUnit :2a1369;
prop:hasCardinality "singular";
Any other questions?
yeah, where did my questions go???
Well, I didn't include those because, mainly, this page is specifically about the modeling itself. But below are some "answers" while we put this part of the discussion in a more appropriate place.
\2. How will Units and UnitNames be seen in ORR?
\3. How will URLs be generated for the two class types?
It seems your concern here still wrt to what you call "vocabularies" taht is, it seems to me, in the sense of the voc2rdf tool. First, the URLs for these two class will, in principle, just share the same namespace as the unit and unitname instances. Secondly, we are capturing a complete XML file (say, the "accepted" one) in a single ontology.