RE: RDF query testcase requirements: IRC chat?

> -----Original Message-----
> From: R.V.Guha [mailto:guha@guha.com]
> Sent: Saturday, February 15, 2003 2:10 PM
> To: Geoff Chappell
> Cc: www-rdf-rules@w3.org
> Subject: Re: RDF query testcase requirements: IRC chat?
> 
> Geoff,
> 
>   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.

One man's data model... :-) But I hear what you're saying - it's a bit
ugly. I probably wouldn't really like to see any sort of a RDF query
standard develop along those lines.

 
>   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.

Sure, but this just means that the ({?p ?s ?o} and {?p ?o ?x}) or ((<p>
<s> <o>), (<p> <o> <x>)) portions of the various query languages are
each equivalent to RDF graphs. But at this point you still need an
external (to RDF) language to tie those pieces together or express other
concepts such as functions, negation, universally quantified variables,
variable projection, etc. 

So to express a query we can either: 
1. live with the simple conjunctive-only query-by-example model
2. develop another syntax to express the concepts we want
3. wait for rdf to become expressive enough to do what we need
4. describe the queries in rdf (which is an ugly form of 2)

I'm clearly most in favor of #2. We probably won't be querying any time
soon if we go with #3 and I don't really see the real world utility of
#1. #4 would be a short-term compromise - presumably while waiting for 2
or 3.

>   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, ...>

The more awkward part, though, is returning triples from a query
language that thinks in variable result sets. For example take a query
like:

<rdfs:Class>
	<rdfs:label>
		<rdf:Description />
	</rdfs:label>
</rdfs:Class>


might end up via a transformation as a query in rdfql like:

var rs = (select ?p ?s ?o using #ds where {[rdf:type] ?x [rdfs:Class]} 
	and {[rdfs:label] ?x ?l} 
	and ((?p=[rdf:type] and ?s=?x and ?o=[rdfs:Class]}) 
			OR
		(?p=[rdfs:label] and ?s=?x and ?o=?l})));

//write back the results as rdf/xml
response.write(datasource(rs).format("application/rdf+xml"));

I guess it's not that hideous - but it would be prettier if we just
returned the variables. 

Geoff

> Guha
> 
> 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
> >
> > [...]
> >
> >>Libby
> >>
> >
> >

Received on Saturday, 15 February 2003 16:08:48 UTC