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

Re: Profiles intro

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Thu, 10 Apr 2008 09:04:03 -0400 (EDT)
Message-Id: <20080410.090403.137289373.pfps@research.bell-labs.com>
To: ivan@w3.org
Cc: bparsia@cs.man.ac.uk, clu@tcs.inf.tu-dresden.de, public-owl-wg@w3.org

From: Ivan Herman <ivan@w3.org>
Subject: Re: Profiles intro
Date: Thu, 10 Apr 2008 14:46:42 +0200

> Bijan,
> let us not start a row here. I may have been a bit harsh in my
> reactions, Carsten hit a nerve:-) I do not think we should go down the
> road of differentiating among profiles on the basis of whether they are
> RDF-ish or not. Ie, can we set this aside and get back to the original
> issue? :-)
> Ivan


A while ago you said

	What I am looking for are statements that make it clear in which
	circumstances I would choose one profile over the other (even if
	I have no idea of the implementation details, nor do I want to
	deal with those). The fact that it can be implemented in
	polynomial time or whatever is only one (albeit important)
	aspect. I have heard arguments that say "if your ontology has a
	simple structure, but have a large abox, then use DL-Lite"; I am
	looking for things like that. The fact that a specific profile
	_can_ be implemented via cheaper means is not enough, in my
	view, to be defined as a _standard_ profile, and the current
	document certainly reads that way...

and then later

	To be honest, I do not understand that. I am not playing dumm; I
	_really_ do not understand what you mean!

	- "The DL-Lite profile is for using conventional database
	systems to efficiently query large amounts of data in the
	presence of a very lightweight ontology."
	- "The OWL-R profile is for efficient rule-based reasoning about
	lightweight ontologies and potentially large amounts of data."

	The interesting thing is that, from a user point of view and
	based on those two statements, there is no clear reason why
	choosing one over the other! Both profiles are for lightweight
	ontologies and large amount of data.... _That_ statement I do
	understand and like. But then... why having _both_ DL-Lite and

	Is there a way to differentiate between the terms 'lightweight'
	ontologies? Can we say that OWL-R is 'lighter' than DL-Lite?

and even later

	Yes, that is what meant; would 'ontology query' work? I am not
	sure what the terminology you guys use... 

	[ You said: ]
	>> In other cases, the emphasis is to provide a minimal
	>> classification and federation vocabulary over a possibly very
	>> large set of data (typically in the form of RDF triplets),
	>> while maintaining efficient querying. Two such
	[ Carsten Lutz replied: ]
	> DL Lite seems unrelated to RDF triplets. It is only OWL-R that
	> is very RDF-ish.
	Ouch. That hurts. This is a Semantic Web ontology, so if an
	ontology is unrelated to RDF triplets, than what does it have to
	do with this group? I do not see why OWL-R would be more RDF-ish
	than DL Lite or vice versa. 

It seems to me very much germane to discriminate between the profiles
based on their position related to the stance that everything is a
triple.  Of the three profiles, OWL-R is the only one that has a version
that is "Full", i.e., uniformly treats all information as triples.  Both
EL++ and DL-Lite distinguish between data (in the form of triples) and
other kinds of information (namely ontology information).

It thus seems more accurate to say that of the three profiles OWL-R is
the only one that can indiscriminately handle triples without losing its
fundamental characteristics.  Both EL++ and DL-Lite are completely
agnostic as to whether the underlying data model of non-fact axioms is
based on triples and could not deal with indiscriminate mixing of fact
triples and ontology triples.

If I was trying to say this in as few words as possible I would probably
have said that OWL-R is the profile most closely tied to RDF, or even
that OWL-R is the only profile that is very RDF-ish.

Received on Thursday, 10 April 2008 13:14:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:04 UTC