W3C home > Mailing lists > Public > semantic-web@w3.org > September 2006

Performance issues with OWL Reasoners (Was RE: Playing with sets in OWL...)

From: Kashyap, Vipul <VKASHYAP1@PARTNERS.ORG>
Date: Thu, 14 Sep 2006 11:01:33 -0400
Message-ID: <2BF18EC866AF0448816CDB62ADF6538104C1644D@PHSXMB11.partners.org>
To: "Alan Ruttenberg" <alanruttenberg@gmail.com>, "William Bug" <William.Bug@DrexelMed.edu>
Cc: "Miller, Michael D \(Rosetta\)" <Michael_Miller@Rosettabio.com>, "Marco Brandizi" <brandizi@ebi.ac.uk>, <semantic-web@w3.org>, <public-semweb-lifesci@w3.org>


OWL reasoners support two types of reasoning:

1. ABox reasoning (reasoning about instance data). Scalability here is being
achieved here by leveraging relational database technology (which is
acknowledged to be scalable) and mapping OWL instance reasoning operations to
appropriate SQL queries on the underlying data store. I believe most OWL
reasoners follow this strategy

There's an interesting paper by Alex Borgida and Ron Brachman in SIGMOD 1993
which presents this approach, title "Loading data into description reasoners"

2. TBox reasoning scalability is a challenge, especially at the scale of 100s of
thousands of classes found in medical ontologies. Would love to hear from DL
experts on this issue.

---Vipul

=======================================
Vipul Kashyap, Ph.D.
Senior Medical Informatician
Clinical Informatics R&D, Partners HealthCare System
Phone: (781)416-9254
Cell: (617)943-7120
http://www.partners.org/cird/AboutUs.asp?cBox=Staff&stAb=vik
 
To keep up you need the right answers; to get ahead you need the right questions
---John Browning and Spencer Reiss, Wired 6.04.95
> -----Original Message-----
> From: public-semweb-lifesci-request@w3.org [mailto:public-semweb-lifesci-
> request@w3.org] On Behalf Of Alan Ruttenberg
> Sent: Monday, September 11, 2006 7:35 PM
> To: William Bug
> Cc: Miller, Michael D (Rosetta); Marco Brandizi; semantic-web@w3.org;
> public-semweb-lifesci@w3.org
> Subject: Re: Playing with sets in OWL...
> 
> 
> On Sep 8, 2006, at 11:39 PM, William Bug wrote:
> 
> > 	3) Re:anonymous classes/individuals of the type Alan describes:
> > These are essentially "blank nodes" in the RDF sense - "unnamed"
> > nodes based on a collection of necessary restrictions, if I
> > understand things correctly.  Please pardon the naive question, but
> > aren't there some caveats in terms of processing very large RDF and/
> > or OWL graphs containing "blank" or "anonymous" nodes.  For many
> > OWL ontologies, this might not be a concern, but if one were to be
> > tempted to express a large variety of such sets based on different
> > groupings of the sequence probes on a collection of arrays -
> > groupings relevant to specific types of analysis - I could see how
> > these anonymous entities - especially the anonymous sets of
> > individuals - could really proliferate.
> 
> Predicting the performance of even small OWL ontologies is a bit of a
> crap shoot at the moment, it appears, though there is ongoing
> research to try to address this. In cases I've worked on I've had
> really small ontologies blow up, and larger cases run extremely
> quickly after some solicitation of advise from the DL experts and a
> little experimentation.
> 
> I think the best thing in these cases are to try to represent what is
> desired, see what happens, and ask for help when it doesn't scale as
> desired. Such cases will, at the minimum be grist for future
> research, and I get the sense that they are highly valued by OWL
> researchers.
> 
> Although I used an anonymous individual in one of the examples, there
> is really no need to, and in fact my recommendation would be to avoid
> their use by generating a name in those cases, taken from a namespace
> that is advertised to be unresolvable and used for this purpose. This
> not for reasons of efficiency as much as for understandability - the
> anonymous nodes are properly considered existential variables and
> should probably be used when you know that's what you want.
> 
> -Alan
> 
> 
> 
> 
Received on Thursday, 14 September 2006 15:01:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:41:53 UTC