W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2002

Re: fighting complexification (was: rdf-concepts comments: this should be a note)

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Tue, 5 Nov 2002 16:15:51 +0000 (GMT)
To: Aaron Swartz <me@aaronsw.com>
cc: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.44.0211051609470.19310-100000@mail.ilrt.bris.ac.uk>

On Tue, 5 Nov 2002, Aaron Swartz wrote:

> > Where's the complexity that you see, Aaron?
> Abstract syntax:  An RDF document is a series of statements, each made
> up of three parts, any of which can be a resource, identified by a URI,
> the first and last of which can be an existential variable identified
> by a local node identifier, called a bNode, the last of which can also
> be a Literal, which consists of a string, a language tag, identified by
> a two-letter language code from [cite] and a datatype, identified by a
> URI of an XML Schema datatype [cite].
> That's off the top of my head; I probably missed a lot and got stuff
> wrong!
> Syntax: For RDF/XML? I don't even want to go there!

Neither do most people. Dave's done an excellent job of describing a
nightmare; he's also produced a spec that actually _specifies_ what the
various constructs mean. We've all got a "wouldn't start from here"
feeling about RDF/XML, maybe, but that's (a) not an option available to
the WG, and (b) less of an issue now that production-strength parsers
and serialisers are becoming available.

> Model Theory: You can safely: take any triple away; replace any blank
> node with a URIref, literal or new blank node; combine two RDF
> documents you believe in (as long as you rename the bNodes).
> That wouldn't be too bad if it was said in that fashion; again I
> probably confused a lot.

MT has been carefully pitched to satisfy (or at least, mollify)
mathematicians while still being "accessible" to non-mathematicians, I

> > A "simple" competitor to RDF might be a rather straightforward
> > graph-based language - but explanations of how that should be used to
> > provide rich consistent semantic structures are almost certainly not
> > going to be.
> I don't really follow you. Here's what a simple competitor would look
> like:
> Abstract syntax:  An X document is a series of 3-tuples, where each
> member is either a resource (identified by a URI) or a string.
> Model Theory: You can safely take any triple away and combine two X
> documents.
> Syntax: Each 3-tuple is separated by a ' .\n', each member is separated
> by ' ', the resources are identified by '<' + URI + '>' and the strings
> by '"' + string + '"'. [Give example.]
> Curtain. Then there'd be a primer with some words on use, maybe a page
> or two.

What I mean was; you've got a great start, but people want to do more
than just grovel around following arcs. Because that's like programming
in C - it's pointer-chasing - and any sensible user is going to want to
raise their level of interaction with a data model higher than that, to
encompass idioms that support rich data types (amongst other things).
Which means that you might have a "simple" foundation, but the
complexity will still occur - just not in your documents.

jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
( echo "ouroboros"; cat ) > /dev/fd/0 # it's like talking to yourself sometimes
Received on Tuesday, 5 November 2002 11:18:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:18 UTC