W3C home > Mailing lists > Public > public-owl-wg@w3.org > February 2008

Re: Fragments discussion, continued

From: Achille Fokoue <achille@us.ibm.com>
Date: Wed, 20 Feb 2008 12:52:49 -0500
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>, public-owl-wg-request@w3.org
Message-ID: <OF8A909D25.D5959144-ON852573F5.0062248F-852573F5.00623812@us.ibm.com>
Hi,

SHER [1] has indeed focused on Alan?s point 3) ?scalability to large 
numbers of  instances?. However, our approach has been to attempt 
scalability over ?practical? large knowledge bases without restricting 
their expressivity.  It has successfully been applied to various real 
world problems (e.g. Automated Clinical trials matching using ontologies 
[2], Scalable Cleanup of Information Extraction Data Using Ontologies [3], 
and a work-in-progress application of semantic search against MEDLINE 
biomedical literature databases).  Although our initial focus was not to 
restrict the expressivity, we have come to appreciate the additional 
improvement in performance and scalability obtained by adding some 
restrictions. Fragments were one of the most important reasons for IBM?s 
involvement in OWL 1.1 WG. 

We are interested in fragments that will provide a clear and simple 
guidance to users (non-dl experts) as to how to control in a standard way 
the computational complexity of reasoning on their knowledge bases.  From 
our perspective, it will, on the one hand, reduce resistance to the 
adoption of the technology as our customers could start with annotating 
their data with concepts and relationships defined, for example, in a 
tractable subset without impact on performance. On the other hand, since 
the data is already annotated with semantic information ?alas inexpressive 
one-, more expressive semantic views could be defined without changing the 
data. So far, I am satisfied by the efforts towards simplicity in the WG - 
in particular, the use of rule-style semantics. 

We also see OWL 1.1 as an opportunity to bridge the gap between industry 
and academia. In particular, we consider as an important goal the 
standardization of a tractable subset of OWL that would work well with 
traditional DBMS.  Something in the flavor of DL-Lite family could fit 
that requirement. We like the rule-style semantics of OWL Prime, but we 
are not convinced yet that its set of constructs will enable it to scale 
over large instances.

In a nutshell, 1) we are not proposing a new fragment, 2) we would likely 
support an EL like fragment in REC, and 3) we agree with Alan on the need 
for a fragment gears towards scalability to large numbers of instances 
(DL-Lite could be a good starting point, but we might need some additions 
to it: for example transitivity, even though queries will no longer be 
transformed into SQL queries).

Best regards,
Achille.

[1] 
http://domino.research.ibm.com/comm/research_projects.nsf/pages/iaa.index.html
[2] http://www.springerlink.com/content/k582jur3k03l5m03/
[3] http://www.springerlink.com/content/q7500h6gv65078k7/




Alan Ruttenberg <alanruttenberg@gmail.com> 
Sent by: public-owl-wg-request@w3.org
02/19/2008 10:27 AM

To
"Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
cc

Subject
Fragments discussion, continued







It seems (I hope) we are getting closer to some sort of mutual 
understanding of our needs for fragments. I'd like to sketch out the 
shape of what I'd be happy to see as an outcome of tomorrow's meeting.

I think we've heard convincing arguments that having a large number 
of fragments in Rec track, absent strong justification for each, 
isn't desirable. On the other hand, I'd like to put forward that 
there are compelling reasons to acknowledge OWL Lite, in the manner 
I've proposed, and to put 3 fragments on rec track, and proceed in 
subsequent meetings to nail down details of specification and 
documentation.

The fragments:

1) OWL Prime (details of exactly what is in or out of OWL Prime 
remain to be worked out). Justified by specific industry interest 
from Oracle and HP, and to address the constituency that wishes to 
have a workable and more easily understandable rule-based OWL.
2) EL++. Justified by existing academic and commercial 
implementations, useful computational properties (polytime) and 
demonstrated use for working with important ontologies for 
biomedicine, a field which has been at the leading edge of Semantic 
Web adoption.
3) A fragment characterized by scalability to large numbers of 
instances (not necessarily scalable tbox) , but with strong 
guarantees with respect to completeness and consistency detection.
This is probably DL-Lite, but I want to leave the door open to input 
from IBM, who's SHER implementation might also fit the bill. We 
haven't discussed this fragment much, so I'll give my view of why it 
is justified. Such a fragment  fills a hole that neither of two other 
fragments fill, as It is likely that OWL Prime will not allow 
existentials in  a rule head (following pD*), and EL++ is not as 
scalable. In addition DL-Lite is implementable in relational 
databases with queries translatable to SQL. I have heard of two 
academic implementations ("the italians" &  Jeff Pan) and a 
commercial implementation - Clark and Parsia's, and the nature of the 
fragment is such that it would be easily adoptable by relational 
database providers. Finally, it is my judgement, as a user, that 
strong guarantees of the ability to detect inconsistency and give 
complete answers bring high value to science applications.

To recap the OWL Lite proposal, the suggestion is to keep OWL Lite, 
unchanged, to support existing users, verify that it behaves as 
before using OWL 1.1 DL semantics, and write a Note to explain its 
status.

Remaining fragments in the current Fragments document, would be 
described in one or more WG Notes.

My hope would be to not necessarily work out all the details 
tomorrow, but instead to come to agreement on this number of 
fragments (3) and their character, so that subsequent meetings  can 
be focused on implementation rather than policy.

Regards,
Alan
Received on Wednesday, 20 February 2008 17:53:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 February 2008 17:53:11 GMT