- From: Tim Bray <tbray@textuality.com>
- Date: Mon, 11 Nov 2002 10:49:00 -0800
- 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 UTC