W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2002

RE: UPDATE: why RDF syntax is not suitable for OWL

From: Smith, Michael K <michael.smith@eds.com>
Date: Fri, 15 Feb 2002 12:18:06 -0600
Message-ID: <B8E84F4D9F65D411803500508BE322140BDBBAC4@USPLM207>
To: Dan Connolly <connolly@w3.org>
Cc: Pat Hayes <phayes@ai.uwf.edu>, "Peter F. \"Patel-Schneider" <pfps@research.bell-labs.com>, www-webont-wg@w3.org

Sure, there are various places where the triple syntax is defined.  And the
model theory uses it.  Which is appropriate, the model theory should be
using an abstract syntax.  But in neither case is this defined to be the
syntax of RDF.  There is a chapter called 

  6. Formal Grammar for RDF

which I take to be the syntax of RDF.  And it has many advantages over the
section you point to.  Has it been demonstrated that the description in
section 5 admits all and only the triples that are implied by the formal
grammar of section 6?

Again, the wording in section 5 talks about the requirement that "the
elements of Ord must be used in sequence starting with RDF:_1".  But we have
an open world.  What does it mean if I don't find RDF:_2, but I have RDF:_3?
As far as I can tell, it means nothing other than that I may not be looking
everywhere I need to.  

The RDF:LI syntax of section 6 seems much easier to both present and reason
about. Though I confess I still don't know what the following means, in that
I don't know what the first element of the sequence is.

<rdf:Seq ID="pages">
  <rdf:li resource="http://foo.org/foo.html" />
  <rdf:li resource="http://bar.org/bar.html" />
<rdf:Seq about="#pages">
  <rdf:li resource="http://foo.org/bim.html" />

Or maybe this is not permissible.

- Mike

-----Original Message-----
From: Dan Connolly [mailto:connolly@w3.org]
Sent: Friday, February 15, 2002 11:36 AM
To: Smith, Michael K
Cc: Pat Hayes; Peter F. "Patel-Schneider; www-webont-wg@w3.org
Subject: RE: UPDATE: why RDF syntax is not suitable for OWL

On Fri, 2002-02-15 at 10:42, Smith, Michael K wrote:
> > I don't think the real issue has anything much 
> > to do with triples; and since so many people like triples, then why 
> > not let 'em use 'em, I would suggest.
> > Pat Hayes
> I think it is a mistake to think 'so many people like triples'.  Maybe
> within the RDF community.  But I presume one of our goals is to create a
> standard that is adopted by a much wider community.  I would assert that
> wider community is  using XML syntax.

The wider community also uses links in the web; links that have
two ends and (in theory) a type. The semantic web, to me, is largely
about taking the theoretical possibilities of typed links
and exploiting them practically.

I can definitely see the downside of RDF being restricted to triples
(i.e. two-place predicates). I think an extension to n-ary
predicates would be interesting to consider. Along with
nicer syntax for collections, ala daml:collection.

>  They are writing and using tools that
> process XML.
> I will ask this question again: Where does the RDF standard say that its
> syntax is defined by triples?

The abstract syntax of RDF formulas takes the form of a set of triples;
the original specs were kinda buggy, but this is the section where
it tried to make this clear:

  This specification shows three representations of the data model;
  as 3-tuples (triples), as a graph, and in XML.

  -- http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#model

>  Where is the formal triple syntax for RDF?

I think this is the best explanation to date:

  0.2 Graph syntax

> All I have seen is an XML syntax.  What documents have I not read?
> It would be perfectly reasonable to define a translation from XML to
> in support of existing tools.  Or for those people who like to read
> code.
> - Mike
> Michael K. Smith
> EDS Austin Innovation Lab
> 98 San Jacinto, Suite 500
> Austin, TX 78701
> Work: 512 404-6683
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 15 February 2002 13:19:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:27 UTC