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

Re: RDF query testcase requirements: IRC chat?

From: R.V.Guha <guha@guha.com>
Date: Sat, 15 Feb 2003 11:10:25 -0800
Message-ID: <3E4E90A1.1080301@guha.com>
To: Geoff Chappell <geoff@sover.net>
Cc: www-rdf-rules@w3.org


  I think this approach will be an abuse of RDF. It treats the 
data model as a syntax. Parsers are quite trivial to write, so 
that should not be a concern.

  Regarding the other point you made about selecting variables 
vs graphs --- the two are equivalent. Reaching back into the 
dark mists of time, a paper that Eric Miller, Ora Lassila, Dan 
Brickley and I wrote for QL 98 (called Enabling Inference) 
proposed sub-graph matching, which is the basic operation 
performed by any deductive engine, as the basis of a query 
system. I can't find that paper, but I think it showed how the 
two (selecting variables vs subgraphs) are equivalent. In any 
case, all one has to show is that a *set* of graphs in which 
nodes can be variables can be mapped into conjunctive normal 
form and vice versa.

  In the context of any particular query language, we can 
allow the form of the return results to be one or the other by 
using function ala:

select fillgraph($x, $y, ...) from ... where <graph mentioning 
$x, $y, ...>

If you just wanted the variables, which I suspect will be the 
common case, you can just say,

select $x, $y, ... from ... where <graph mentioning $x, $y, ...>


Geoff Chappell wrote:

> 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.
> Regards,
> Geoff Chappell
> [...] 
Received on Saturday, 15 February 2003 16:30:40 UTC

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