W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2012

RE: seeks input on Study Data Exchange Standards

From: <Peter.Hendler@kp.org>
Date: Wed, 22 Aug 2012 06:58:04 -0700
To: meadch@mail.nih.gov
Cc: kerstin.l.forsberg@gmail.com, matthias.samwald@meduniwien.ac.at, public-semweb-lifesci@w3.org
Message-ID: <OF99E9D335.5ED88B03-ON88257A62.004C19FF-88257A62.004CB9D9@kp.org>
>>Specifying if and how exactly each specific node should be reasoned upon 
sounds so complex that I cannot imagine it working in any practical 

It works very well for us.  Perhaps it's because you are imagining many 
nodes with many logics.  What it boils down to in real life at least now, 
is only one node per model which is bound to SNOMED.  The "code" of an 
Observation is SNOMED and we can and do use reasoners on that node.

There are not any other DL Ontologies in wide use in the world at this 
time other than SNOMED, and we mainly use it for Clinical Disorders, 
Procedures, Body site and Organism.  So we get a huge real life advantage 
from only designating one or two nodes at all.

But rather than lock it down forever, leave the possibility open that 
others may want to "open" up other nodes on occasion.
The default state of a node is "intensional = "false"  so in en entire 
model, you may see none or one node bound to SNOMED.

In real life it's not complex as long as you aren't imagining many nodes 
with different logics in the same model, which may never happen unless 
you're experimenting.

NOTICE TO RECIPIENT:  If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents.  If you have received this e-mail in error, 
please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or 
saving them.  Thank you.

"Mead, Charlie (NIH/NCI) [C]" <meadch@mail.nih.gov> 
08/22/2012 04:44 AM

Matthias Samwald <matthias.samwald@meduniwien.ac.at>, Peter 
"kerstin.l.forsberg@gmail.com" <kerstin.l.forsberg@gmail.com>, 
"public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>
RE: seeks input on Study Data Exchange Standards

Exactly the reason we are viewing OWL as the "design-time" SW approach RDF 
as the "run-time" tool -- and therefore being careful not to do anything 
so fancy in OWL that it can't be realized at run-time.

From: Matthias Samwald [matthias.samwald@meduniwien.ac.at]
Sent: Wednesday, August 22, 2012 7:05 AM
To: Mead, Charlie (NIH/NCI) [C]; Peter.Hendler@kp.org
Cc: kerstin.l.forsberg@gmail.com; public-semweb-lifesci@w3.org
Subject: Re: seeks input on Study Data Exchange Standards

Peter wrote:
> Using both SQL and subsumption you can automatically find things like 
> "find all disorders that are a kind of adverse drug reaction where drug 
is a subtype of antibiotic and was given for a kind of gram negative 
bacterial infection of the digestive system".
Simple subsumption such as that can be inferred by basic, RDFS-type 
reasoning. I don't see any potential problems caused by OWL's open world 
assumption here (please point them out if there are any).
Indeed, the open-world assumption of OWL can make creating expressive 
ontologies and using reasoners tricky. However, I do not see why the same 
should be true for using RDF, basic RDFS subsumptions and SPARQL. Could 
you provide some examples?

If we wanted to use more expressive ontologies with "intensional" entities 
(i.e., defined classes) in the overall system, we could simply run a 
reasoner and materialize the inferred statements for each ontology before 
it is 'shipped' for use by other systems. These other systems could then 
use simple RDF(S) and SPARQL (and maybe SPARQL rules), without the 
performance issues and potential unexpected consequences of open-world 
reasoning with expressive OWL ontologies. Specifying if and how exactly 
each specific node should be reasoned upon sounds so complex that I cannot 
imagine it working in any practical setting.

Received on Wednesday, 22 August 2012 14:04:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:56 UTC