- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Fri, 03 Mar 2006 12:03:52 -0500
- To: edbark@nist.gov
- Cc: Jim Hendler <hendler@cs.umd.edu>, RIF WG <public-rif-wg@w3.org>
> 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. Ed, two points: 1. It is actually the first style (call-based) that allows the use of multiple sources. The second (translation-based) is not easily amenable to that. If you have a standard translation from OWL and you use it to dump different ontologies into a rule-based format then you get a mess and all kinds of bad interactions between different formulas. 2. There are no FOL rule engines as far as I know. They currently exist on paper only. It is not at all certain that there will be. So, what is your target user group? --michael
Received on Friday, 3 March 2006 17:04:04 UTC