> > It's not a restriction on the predicates - it's a restriction on
> instances of a certain class - like that of blood pressure
> measurements. Checking consistency would tell you whether your data
> conforms to the specification described by the ontology document.
>
> Right, but tells whom, and when? including :measuredInUnits advertises
> a flexibility which you do not intend to honor.
The predicate would only advertise that the domain would be a quantity and the
range a unit.
> If I dereference
> :systolicMPa, I learn that the units are exactly MPa. If I dereference
> muo:numericalValue and muo:measuredUnits, I learn that I can use any
> units (misleading).
It isn't misleading, it's exactly as advertised.
> If I wade through the OWL for TMO, I learn that
> there's a restriction for say:
>
> Class: tmo:BloodSystolicPressureReading EquivalentTo:
> (:value exactly 1)
> and (:measuredInUnits exactly u:mmHg)
>
and (:measureInUnits only u:mmHg)
> which, if I think hard, tells me that I must normalize my data, but
> this is pretty far from follow-your-nose semantics.
There's no thinking required - the semantics are clearly spelled out in the
axioms. Instances of this class refer to mmHg as the unit. Any instance that
refers to a different unit is not a member of this class.
> I think I have described why authoring is less fault-prone if the
> normalized date in TMO uses precise predicates. Do you have other use
> cases which override that one?
The counter argument to using a specialized predicate is that
1) we cannot describe a unit
2) there is a proliferation of relations as there are countless quantities
multiplied by each of their respective units.
3) relations can only be weakly described (they do not have the class
constructors available to describe them)
4) requires one to query the labels instead of the semantics to find the
appropriate relation.
5) requires one to parse the label for the intended unit.
It's a shortcut that makes linked data prettier, but weakens formal knowledge
representation.
m.
