W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: draft XML query results format spec

From: Kendall Clark <kendall@monkeyfist.com>
Date: Wed, 29 Sep 2004 08:03:34 -0400
To: Simon Raboczi <raboczi@tucanatech.com>
Cc: public-rdf-dawg@w3.org
Message-ID: <20040929120334.GB17067@monkeyfist.com>

On Wed, Sep 29, 2004 at 02:54:42PM +1000, Simon Raboczi wrote:

> sorted results would be unpleasant for consumption by XML tools.  The  
> XML format didn't have this problem because XML elements like the  
> <result> children of <results> have an order, whereas in RDF/XML the  
> <sparql:Solution> children of <rdf:RDF> don't have an ordering in the  
> RDF graph.

For technical as well as for marketing reasons, I think having an XML
format for variable binding results is a good idea; actually, I think
it's pretty much mandatory. I favor Dave's schemaless format,
especially since it's the most concise, as Steve has just shown (a 17%
difference for big results sets can make a real diff, I suspect).

However, I also think we should get used to the idea of having
multiple results formats:

	1. RDF graphs (returned by CONSTRUCT queries; returned by the
	protocol operation, getModel, which is concretely realized in
	HTTP as GET /model HTTP/1.1)
	2. variable bindings as RDF graphs (returned by SELECT queries
	that have negotiated RDF via con-neg)
	3. variable bindings as XML trees (returned by SELECT queries
	that have negotiated XML via con-neg)
	4. some kind of distinguished boolean (ASK queries)

>From a consumer point of view, (1) and (2) and indistinguishable,
really. Both are just RDF graphs. Having (3) is very useful for, among
other things, making SPARQL 'seem easy' to XML hackers and for
satisfying our charter requirement to play nicely with XQuery.

And we have plenty of ordinary protocol machinery with which to
request and receive alternative representations of the same resource:

	- (2) and (3) are alternative representations of the same
          resource, namely, the set of variable bindings resulting
          from a SELECT query

	- There are several alternative ways of representing the
          results of CONSTRUCT queries; we should come down firmly on
          the side of *the* canonical way, RDF/XML, but it's
          inevitable that people will use ordinary web machinery to
          exchange other representations
	- We haven't talked much about ASK and boolean values, but
          that *seems* the easiest case.

W3C's WebArch document implies that providing alternative
representations of the same resource, either driven by user agent or
origin server requirements or capabilities, is one of the bits of web
architecture which makes it a reasonable, useful computing
environment. In that kind of environment it seems a bit odd to
restrict ourselves and others unnecessarily.

Cheers, Kendall
Received on Wednesday, 29 September 2004 12:17:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC