RE: [TMO] patient record normalization

* Michel_Dumontier <Michel_Dumontier@carleton.ca> [2010-09-10 18:42-0400]
> > -----Original Message-----
> > From: Eric Prud'hommeaux [mailto:ericw3c@gmail.com] On Behalf Of Eric
> > Prud'hommeaux
> > Sent: Friday, September 10, 2010 6:41 PM
> > To: Michel_Dumontier
> > Cc: Chimezie Ogbuji; public-semweb-lifesci@w3.org
> > Subject: RE: [TMO] patient record normalization
> > 
> > * Michel_Dumontier <Michel_Dumontier@carleton.ca> [2010-09-10 16:30-
> > 0400]
> > >
> > > > But then anyone merging two TMO documents with different units has
> > the
> > > > normalization burden. If we pick a unit and annotate the
> > predicates,
> > > > then the folks who would have to do the work of merging with non-
> > TMO
> > > > documents (who would have to introduce some rules/canonicalization
> > > > pipeline anyways) have the OWL hooks to automate that merging.
> > >
> > > Again, if we are considering TMO, then we can impose a restriction to
> > specify the unit - we can also make this clear in documentation
> > relating to the measurements with units.
> > 
> > My thesis is that including such apparent flexibility does a bit more
> > harm than good; that the potential good is almost exclusively in the
> > use of tools which can make generic use of standard value predicates
> > (rdf:value, muo:numericalValue) e.g. data browsers. The harm is that
> > you are advertising a flexibility that you don't intend to honor; the
> > freedom of units. If we impose the reasoning constraint not on the
> > authoring pipeline, but instead on those who would make use of the
> > generic predicates, we reduce the likelihood of non-normalized data.
> 
> 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. 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). 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)

which, if I think hard, tells me that I must normalize my data, but
this is pretty far from follow-your-nose semantics.

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?

> m.
> 
> > 
> > 
> > > > > Also, having domain-independent predicates makes it easier to
> > render
> > > > a view
> > > > > of the data (for human consumption) that includes visual cues
> > > > regarding the
> > > > > units of measures associated with values directly from the data
> > since
> > > > such
> > > > > tools will always expect the same set of terms to capture a value
> > and
> > > > its
> > > > > unit of measurement.
> > > >
> > > > If you've bought the argument for early normalization, isn't it
> > > > needlessly dangerous to offer the freedom to express BP in mmHg in
> > an
> > > > ontology that's required to have BP in MPa? It does put more burden
> > on
> > > > the use of generic data browsers (they'd have to read the OWL in
> > order
> > > > to present the user with units), but I think that use case is small
> > > > compared to the cost of data consumption.
> > >
> > > I don't think we should tailor our data model to generic data
> > browsers - they are far too simple for the complex knowledge that we
> > have to represent.
> > >
> > > m.
> > 
> > --
> > -ericP

-- 
-ericP

Received on Saturday, 11 September 2010 02:07:23 UTC