W3C home > Mailing lists > Public > www-tag@w3.org > November 2002

Re: My action item on RDDL/RDF

From: Tim Bray <tbray@textuality.com>
Date: Mon, 11 Nov 2002 10:49:00 -0800
Message-ID: <3DCFFB9C.4090509@textuality.com>
To: Dave Beckett <dave.beckett@bristol.ac.uk>
Cc: Paul Prescod <paul@prescod.net>, WWW-Tag <www-tag@w3.org>

Dave Beckett wrote:

> I edit the RDF/XML specification (revising the existing syntax) so
> here is how I see it.  One of RDF/XML's many original goals was to
> enable it to be embedded in HTML (Tim Bray was on the original
> working group and can correct me).  This is one of the reasons why it
> has many (too many) abbreviated forms

My recollection is that the original RDF/XML syntax emerged from a 
horrible morass of Netscape/Microsoft infighting that left it in a 
damaged state which which it has yet to recover.

Right now, we have a problem:

1. The syntax of RDF/XML is sufficiently scrambled and arcane that it is 
neither human-writeable nor human-readable.
2. The RDF/XML syntax grossly, egregiously, horribly abuses qnames.
3. People who care about metadata have no trouble thinking in terms of 
resource/property/value triples
4. The notion that you can slip RDF into XML transparently enough that 
people think of it as XML and it works as RDF has failed resoundingly in 
the marketplace, cf RSS1.0
5. Alternatives like N3 that actually let you look at the syntax and see 
the triples suffer in comparison to the XML/RDF syntax because they lack 
XML's widely-deployed base of software with all the i18n machinery and 
API-ware and so on.

So why can't we have an RDF syntax that actually exposes the 
Resource/Property/Value structure in an obvious way, and doesn't depend 
on qname magic and schemas that aren't recommendations, but is still XML 
and hence handy for interchange?

Let's call it the RPV syntax.  It has two elements, R and PV.

The simplest expression looks like this (let's assume 
xml:base="http://example.com"):

<R r="/resources/rA">
  <PV p="/properties/pA" v="/values/vA" />
  </R>

Don't even need to explain it.  You can have as many PV's in an R as you 
want.  The property has to be a URI reference and has to be there.  If 
there's a "v" attribute, the value is a URI reference too, or you can 
give a literal textual value locally:

<R r="/resources/RA">
   <PV p="/properties/pA" v="/values/vA" />
   <PV p="/properties/PB">The value is PB</PV>
   </R>

You can have the literal text value somewhere else (PV can have only one 
of a "v" attribute, a "vText" attribute, or content):

<R r="/resources/RA">
   <PV p="/properties/pA" v="/values/vA" />
   <PV p="/properties/PB">The value is PB</PV>
   <PV p="/properties/PC" vText="/texts/textC" />
   </R>

The R element contains assertions about the resource whose URI is given 
in the "r" attribute.  If there is no "r" attribute there has to be an 
"id" attribute, in which case the "R" element asserts the existence of a 
resource (an R element must have either an "r" or an "id" attribute but 
not both).

<R id="resource-A">
   <PV p="/properties/pA" v="/values/vA" />
   <PV p="/properties/PB">The value is PB</PV>
   <PV p="/properties/PC" vText="/texts/textC" />
   </R>

<R r="#resource-A">
   <PV p="/properties/pD">Value of pD</PV>
   </R>

For extra credit you could have separate resourceBase, propertyBase, and 
valueBase settings instead of just xml:base.

What else would you need?  -Tim
Received on Monday, 11 November 2002 13:49:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:12 GMT