Re: Query and storage

At 11:53 AM 5/23/02 +0100, Seaborne, Andy wrote:
> > a higher level than "find this pattern of triples"
>
>Agreed.  There are two problems that are closely related by sharing
>technology but are different use models.  Query-variable bindings is a
>matter of one layer of the application wanting to ask questions of the RDF
>graph ("find the resource such that ...") and the extract subgraph that is a
>matter of RDF->RDF transformation by restricting one graph.  These two seem
>to get mixed up.

Yes, I agree.
(My query implementation doesn't return a subgraph at all, just the 
variable bindings.)

> > I'd like to see more work on storage formats before we nail down a query
>language.
>
>This is where I disagree: I don't want to see a relationship between the
>query language and the storage.  I think query should be specified in
>relation to the RDF graph.  It would be different implementations for
>different application domains that make decisions about storage and query
>*implementation*.  There is no need to bind storage choices to QL choices.

I agree with what you say here, but maybe I should clarify what I meant.  I 
didn't mean that the query language should be bound to a storage format.

Rather, I was thinking about the efficiency of higher-level query 
constructs;  my own implementation is modelled on the idea of matching 
tree-shaped query subgraphs against an arbitrary RDF graph.  My intuition 
here is that this should permit more efficient handling of the 
query.  Working with a Jena-like interface, the first thing I do to 
implement this is break it down into a collection of triples to be matched, 
so on that score I don't seem to have made any useful progress.  (To set 
against that, I was encouraged that the implementation seems to be 
constrained to conduct the graph query in much the same way that I would do 
if programming it by hand.)

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 23 May 2002 12:43:21 UTC