Re: exchanging OWL through RIF

Jim Hendler wrote:

>> 1 - Consider an organization like the  Natl Cancer Inst which has a 
>> big OWL ontology (i.e. has a number of full time people working on 
>> curation, versioning, etc).  They or some other org decide they'd like 
>> to use it on databases and datasets for datacleansing or other "rule 
>> based" operation.
>>    Recoding the whole into a new rules language would be prohibitively 
>> expensive unless there is some sort of automagic translator of some or 
>> all of the RDFS/OWL they use.
> 
> This, I think, is more like what Ed was proposing.  

It is.  The particular example that leapt to mind (with Jim's prompt) is
converting elements of a medical ontology for a rule-based diagnostic tool.

Interestingly, for this particular example, Michael may be right.  It may be 
possible to organize the rules model for the diagnostic tool in such a way as 
to consist partly of SPARQL(-like) queries on the NCI ontology.

But it all depends on the "style" of the rules engineer for the tool.
- one rules engineer would know that he wants his tool to work with the NCI 
ontology directly and treat the NCI ontology as an external information base 
accessed by "attached procedures", or maybe by something we invent that is 
somewhat smarter.
- another rules engineer would convert those NCI ontology elements needed by 
the diagnostic tool into a form that could be used directly by the rules 
engine, around, beside and among other rules.  That is, s/he would use the OWL 
ontology to *extend* the rulebase.

IMHO, each of these styles is "better" in certain circumstances:
    The first creates an intrinsic dependence, possibly on a specific 
site/service, for the diagnostic tool.  At the same time, it preserves the 
separation of concerns -- the ontology can grow and become more detailed and 
more accurate and the diagnostic tool in the field may profit from that 
without modification.
    The second creates tool independence, so that the diagnostician doesn't 
have to have wireless access to use it. It allows the tool's rulebase to be 
enriched from multiple sources, initially, and whenever the engineer finds and 
encodes them, with the consequence that the diagnostic tool can do better than 
any of the participating ontologies.  OTOH, it requires regular update by the 
rules engineer to incorporate these enhancements, and field upgrade to the 
installed base, even when the source is just the latest version of the 
ontology the engineer started with.
    It is certainly true that if the ontology engineer at the primary site 
extends the primary ontology using the other ontologies that the rules 
engineer used, the primary ontology will also provide all the same benefits, 
plus separation of concerns.  So the question comes down to: who will actually 
do that work?  Experience teaches that, unless there is a very strong 
affiliation with the ontology provider, the rules engineer will assume he has 
to do it and now, because it affects time-to-market, product quality and 
customer utility.

Over time, we will re-educate rules engineers (along with other software 
engineers) to think in terms of Web-based access to resources as a matter of 
fact.  But just now, too many of those in power became engineers in the 1980s 
for that to happen quickly.  (In the late 1980s we had the same problem 
getting software engineers to use the central databases directly.)

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

Received on Friday, 3 March 2006 16:46:17 UTC