W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > January 2013

Re: HL7 RIM Designtime OWL Runtime RDF

From: Sivaram Arabandi, MD <sivaram.arabandi@gmail.com>
Date: Wed, 16 Jan 2013 23:55:20 -0600
Message-ID: <CAOzuP9FcKMUsZwafwWUMF4u9mTX965y6r=v7nTZCbyQiX-jQPQ@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: "Peter.Hendler@kp.org" <Peter.Hendler@kp.org>, "meadch@mail.nih.gov" <meadch@mail.nih.gov>, "conor-dowling@caregraf.com" <conor-dowling@caregraf.com>, "d.rebholz.schuhmann@gmail.com" <d.rebholz.schuhmann@gmail.com>, "jluciano@gmail.com" <jluciano@gmail.com>, "michel.dumontier@gmail.com" <michel.dumontier@gmail.com>, "public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>, "ri@semanticidentity.com" <ri@semanticidentity.com>, "rmrich5@gmail.com" <rmrich5@gmail.com>, "tfmorris@gmail.com" <tfmorris@gmail.com>
David, thanks. Like the examples. Only thing to make sure is that the
data/graph used to draw the conclusion is not altered with back-dated data
- think this aspect is already being discussed.


On Wednesday, January 16, 2013, David Booth wrote:

> Hi Siviram,
> On Wed, 2013-01-16 at 14:51 -0600, Sivaram Arabandi, MD wrote:
> > I am enjoying reading and catching up on this thread.
> >
> > David, you mentioned 'rdf model' below - are you referring to ontology
> > models?
> Yes, sort of.  One can design an RDF model without formalizing it into a
> written ontology.   So I was referring to the schema of the RDF data --
> classes, relationships, etc -- whether or not that schema is implicit or
> explicit (i.e., written into an ontology).
> > And, you said "To my mind, monotonicity is the key."  But in medicine
> > most reasoning is non-monotonic  - default reasoning, (educated)
> > guesses and revision of diagnosis as new data comes into the picture.
> > What am I missing here?
> Today you might conclude "As of 16-Jan-2013 the diagnosis is X", but
> tomorrow you might conclude "As of 17-Jan-2013 the diagnosis is Y".  If
> you represent the statements that way (qualified by the particular
> context or, in this case, date) then they are monotonic -- they remain
> true forever, regardless of what new information arrives.  Whereas if
> today you were to represent that information simply as "The diagnosis is
> X" then it would be non-monotonic, because tomorrow you might need to
> change it to "The diagnosis is Y".
> OTOH, even if the data is monotonic, you can cleanly use default
> reasoning and the closed world assumption in the way you *use* that
> data.  For example, if the data is represented like "As of 16-Jan-2013
> the diagnosis is X", then a query can return the *latest* diagnosis and
> report that "the current diagnosis is X".  Tomorrow, after more data has
> been added, that same query might report that "the current diagnosis is
> Y".
> You can think of "the current diagnosis is X" as being derived,
> non-monotonic data.  If you store it, you must be careful to treat it
> only as cached information that will be invalidated when its antecedent
> information changes.  The RDF Pipeline framework that I've been working
> on
> http://code.google.com/p/rdf-pipeline/
> was designed in part to handle this kind of problem: to keep track of
> information dependencies and update derived non-monotonic information
> automatically.  Here are slides about it from last year's Semantic
> Technology conference:
> http://dbooth.org/2011/pipeline/
> You can also design your RDF data models so that certain pieces make
> closed world assumption or use defaulting conventions.  Then you have to
> be careful to keep track of which pieces they are, so that when you
> merge data you do so appropriately without invalidating anything.  For
> example, you might change defaults into explicit values before merging.
> --
> David Booth, Ph.D.
> http://dbooth.org/
> Loss of web prodigy Aaron Swartz: http://tinyurl.com/ahe2k8c
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.

Sivaram Arabandi, MD, MS
Ph:  832.726.2322
Received on Thursday, 17 January 2013 05:55:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:00 UTC