Re: HL7 RIM Designtime OWL Runtime RDF

Hi Peter,

On Wed, 2013-01-16 at 08:39 -0800, Peter.Hendler@kp.org wrote:
> Eric et al, 
> Is there any material on the idea of "design time OWL runtime RDF"?   
> 
> Is it Kosher, once you are done with your reasoners, to convert to RDF
> and then treat it as if it were closed world like a database? 

Absolutely.  Almost all applications use a closed world assumption at
some point.
> 
> RIM which is OO, is of course closed world and can be represented in a
> database. Nothing can change, no new assertions can be made. When an
> HL7 message is sent, we assume it can't be changed by a reasoner or
> anything else. It is set in stone. In fact, there are laws. You are
> not allowed to edit a message once it's been sent. 
> 
> In open world, anyone can add to the triple store at any time, and
> meanings can change. But in an HL7 message, once you make the message,
> you are not allowed to amend or add to it. 

It should be monotonic, so even though all of the existing statements
still hold, additional statements may be true also.  When talking about
"changing" some data, it's important to distinguish between
(monotonically) adding more data to it and (non-monotonically) modifying
the existing data.
> 
> On a related note.  We have different ways of expressing negation to
> Acts. Much of the complication comes from whether the negation is done
> in the vocabulary (SNOMED) or the OO part of the model (RIM). 
> How can we tell if two different representations where the is negation
> expressed on different parts in the model, are semantically the same? 

Can you give an example? 
> 
> The terminology (SNOMED open world, OK to use reasoners) and the RIM
> (OO closed world) can not be mixed (I think).  

Why do you say that they cannot be mixed?  You do have to be careful to
know which data is making what closed world assumption.

> But my question is this. 
> Can you reduce the whole representation of the RIM part of the model
> and the terminology part (SNOMED) into one set of triples, and then
> could you reduce two  instances of the these mixed models to graphs of
> triplets that you can compare? 

In principle, yes, I think so.  But let me turn it around the other way.
I think it is important to design the RDF models such that they can be
mixed and instances can be compared.  If there are problems in doing so,
then we need to correct the models to fix them.
> 
> If you did reduce/normalize the mixed model of the OO RIM and the EL+
> logic SNOMED into one set of triples.  Could you consider these, for
> your comparisons, as if they are closed world and simply compare the
> graph patterns? 
> 
> This is another way to ask.  At any point in the life of a model (HL7
> message or clinical statement for example), can you just declare "from
> this point forward, no one is allowed to add to or change this graph
> in any way", and then treat the whole graph as if it is closed world,
> even though at an earlier point in the graphs life cycle it did
> consist of SNOMED (open) and RIM (closed)?  Does it become closed by
> agreement not to add to it after it is final? 
> 
I think it is critical that the RDF models be designed to be monotonic,
so that you can always add more information without invalidating
previous information.  This means that you cannot just say something
like "Mary is pregnant".  It has to be qualified to a particular context
or time period, such as "On 1-Jan-2013 Mary's pregnancy test was
negative".  (Sorry for such an obvious example, but hopefully you see
what I mean.)

To my mind, monotonicity is the key.  I normally think of "closed world"
and "open world" as being more about what you *do* with the data, than
being about the data itself.  If the data is designed to be monotonic,
then for specific uses you can use closed world reasoning.

With all that said, I'm not certain that I'm really hitting on the
question that you're raising, so if you can show a more concrete example
it may help.

Thanks!

-- 
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.

Received on Wednesday, 16 January 2013 19:46:41 UTC