On 9/11/2010 2:04 AM, Michel_Dumontier wrote:
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.
Speaking as someone just browsing this discussion (so take my comments
for what they're worth, which isn't much), I'd tend to agree with Eric
here. If I (as a human) saw this in an ontology, I'd expect that I can
freely mix and match units in my data and that any software processing
the data will cope with it or raise a reasonable error.
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.
Would you expect my above assumption to be accurate? It sounded from
some other messages in the thread that there's a thought that even with
the "generic" approach that systems would in general handle data in
homogeneous units?
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.
There's no thinking required if you have an OWL reasoner as an integral
part of your tool chain. Otherwise, there is thinking required. And even
if you have an OWL reasoner in your tool chain, you'd probably have to
be doing something clever with integrity constraints a la Clark & Parsia
to catch errors this way, rather than just to end up asserting bogus data.
Again, apologies if my comments are off-base as I'm mainly just passing
through here!
Lee
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.
