W3C home > Mailing lists > Public > www-rdf-logic@w3.org > December 2001

Re: DAML+RDFS: potentials for simplifications?

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Tue, 11 Dec 2001 15:32:10 -0500
To: connolly@w3.org
Cc: phayes@ai.uwf.edu, jbroeks@cs.vu.nl, www-rdf-logic@w3.org
Message-Id: <20011211153210A.pfps@research.bell-labs.com>
From: Dan Connolly <connolly@w3.org>
Subject: Re: DAML+RDFS: potentials for simplifications?
Date: Tue, 11 Dec 2001 12:37:17 -0600

> Pat Hayes wrote:
> > 
> > >On Thu, 29 Nov 2001 Joachim.Peer@unisg.ch wrote:
> > >
> > >>  You say, a result of the simplified syntax is, that a
> > >>  processor would need a "set of conventions". Yes, but how
> > >>  does this differ from the current situation?
> > >
> > >It doesn't, and I think we are touching upon the core here:
> > >by using a set of conventions (RDF!) that seems likely to be
> > >shared by a broader community we are increasing
> > >interoperability. Possibly at the cost of not having the
> > >most optimal model, but this is a typical result of a
> > >compromise. You can't have your cake and eat it, too.
> > >
> > >>  Are you aware of any DAML interpreter which has no
> > >>  hardcoded set of DAML specific instructions?
> Yes:
> 	http://www.w3.org/2000/10/swap/
> It's not a complete DAML+OIL reasoner... it
> sometimes goes into an infinite loop and sometimes
> fails to find all valid conclusions. But
> it handles DAML+OIL vocabulary in lots
> of practical applications.
> (It didn't handle cardinality as of a while
> ago, but somebody just contributed some math
> built-ins, so it might be able to now.)

Hmm.  That page does not mention DAML(+OIL) at all.  Is there some
indication of how anything on that page is related to DAML+OIL somewhere?

> > >Yes. Any RDF parser for example. Or the RDF Schema query
> > >engine that we are currently building. Any RDF or
> > >RDFS-specific tooling in fact.
> > 
> > I think this answer is disingenuous. Any RDF parser can parse
> > DAML+OIL , but it parses it as RDF, not as DAML+OIL. In order to
> > 'interpret' (which I take to mean, be able to draw valid conclusions
> > from) the DAML+OIL, one needs to know more than just RDFS: one needs
> > to know how the DAML+OIL syntax is encoded into RDF. For example, one
> > needs to know that some of the RDF is asserted as part of a DAML
> > assertion, but other pieces of RDF are assertions about the syntax of
> > the DAML assertions.
> Huh? what do you mean by that? The software I use
> treats all the assertions the same, and works quite well.
> The spec says in so many words:
>   "A DAML+OIL knowledge base is a collection of RDF triples."
> 	-- http://www.daml.org/2001/03/reference.html

So?  An RDF/XML document is an XML document, but I don't think that an XML
processor will at like an RDF processor just because it is given an RDF/XML
document instead of some other XML document.

> [...]
> > >True. But the RDFS-aware application will still know that
> > >there is a relation called UnionOf.
> > 
> > Right, but that is false in DAML+OIL. There is no such relation: that
> > 'relation' is part of the syntax. See Peter Patel-Schneider's recent
> > postings to the joint committee and the subsequent discussions:
> > http://www.daml.org/listarchive/joint-committee/0934.html
> The way you write this suggests that it's a position that's
> agreed by all the DAML+OIL contributors, Pat. Please
> be more clear.
> As far as I'm concerned, there is a ont:unionOf relation;
> it holds between a class and a list of classes.

Well that depends on what you want the relationship between RDF and
DAML+OIL to be.  If you want to encode DAML+OIL in RDF (triples) then,
sure, you can think of daml:unionOf as a relationship between an RDF:class
and a DAML+OIL list of RDF:classes.  However, if you want to make DAML+OIL
an extension of RDF, then you may have to give that up (to get the
appropriate semantic relationship between RDF and DAML+OIL).

> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/

Peter F. Patel-Schneider
Bell Labs Research
Received on Tuesday, 11 December 2001 15:32:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:37 UTC