W3C home > Mailing lists > Public > www-rdf-rules@w3.org > February 2003

RE: RDF query testcase requirements: IRC chat?

From: Geoff Chappell <geoff@sover.net>
Date: Sat, 15 Feb 2003 09:45:28 -0500
To: "'Libby Miller'" <Libby.Miller@bristol.ac.uk>, <www-rdf-rules@w3.org>
Message-ID: <000701c2d500$e5112ea0$835ec6d1@GSCLAPTOP>

> -----Original Message-----
> From: www-rdf-rules-request@w3.org
> On Behalf Of Libby Miller
> Sent: Friday, February 14, 2003 11:09 AM
> To: www-rdf-rules@w3.org
> Subject: RDF query testcase requirements: IRC chat?
> hi all
> As part of the EC SWAD-Europe project [1], I'm writing a report on
> languages for RDF. Rather than repeat lots of excellent work (e.g.
> [2][3][4]), I've decided to focus on testcases for RDF query. I
> a thread on query testcases on this list a couple of weeks ago. A
> summary is here
> The main issue for me is how to express the query itself.
> My inclination is to try and express queries as graphs with parts
> missing, that is, to interpret an RDF graph as a query, as Jos de Roo
> suggested [5].

I'm not sure I fully understand all of the goals of your investigation
but I guess I don't see this as a great choice for several reasons: 

1. Most of the query languages that exist today for RDF are of the form
	SELECT ?var1 ?var2 WHERE ...
Why not pick a common query description that is closer to this form -
i.e. one that returns variable bindings and not triples?

2. The RDF graph form doesn't allow for anything but simple conjunctive
queries (as previously mentioned on this thread). That may be all you're
looking for now, but it seems like you'd be at a dead-end if you ever
wanted to expand the testsuite.

3. While suitable for entailment tests (when you have both the question
and the answer) the graph-as-query is a bit awkward as a query method
because you have no way to express what should be returned. The query
answerer has no choice but to spit back the full query graph (and only
the query graph) with bnodes given values (presumably for each set of
bindings that satisfy the query.) This can be awkward in practice for
query systems that use the SELECT ... approach.

> I think this would give us one big win, which is that we could ignore
> the syntactic differences between several very similar query languages
> for RDF (although this will by no means encompass all RDF query
> languages). Plus of course, we get the query parser for free.

We could ignore the syntactic differences also by just coming up with a
simple description of a query - a la ruleml, dql, etc. And assuming we
use RDF for that description, we'd get the parser for free also. One way
or another there will be processing necessary to convert the query into
the native query form of the system. It many/most cases I imagine it
would be just as easy or easier to convert from a description of a query
rather than a graph-as-query.


Geoff Chappell
> Libby
Received on Saturday, 15 February 2003 09:45:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:14 UTC