RE: requirement: multigraph query

-------- Original Message --------
> From: public-rdf-dawg-request@w3.org <>
> Date: 06 May 2004 20:32
> 
> Is this proposed for the query language, or for the protocol?
> I realize that requirements for both are in scope, but I'm
> curious what the intent of the requirement is.
> 
> In SQL, for example, selection of the database is left to
> protocol, while selection of table(s) is part of the query language.
> 
> If we're talking about aggregating a bunch of separate RDF
> repositories, this seems clearly out of scope. The
> aggregation of multiple repositories is nothing but a new
> repository. How repositories are formed or composed is an
> architecural issue that is going to cost us a year if we
> really do it the right way. Let's not do it--if you want to
> write a query client which touches a dozen different
> repositories, then write an app that joins them all into a
> local virtual repository and then query that. The fact that
> your implementation of the repository implements the query
> language in this complex way shouldn't change what the
> language is. (Again, we're standardizing what results are
> right and wrong, not how you get those results.)

I agree - it seems that the binding of a query to a source is done through
the local API.  By giving a name (URI) to the combination of either
aggregator or query broker, then there need be only one "source" as in the
place where the query is intially directed.  How it is fulfilled is not a
matter for the WG.

The first "aggregated query" case seems particularly a local API issue. Have
I missed something in thinking that there is no advantage to be gained by
knowing a query is the union of multiple query results?

The "union query", where the results are different and more than the merge
of results, because it is considering the combined graph, seems to be about
query routing.  Call me a wimp, but I don't want to go there in this WG.
And creating the explicit merge of two large databases just for a single
query is prohibitively expensive.

Kendall - is there anything more here we're missing in saying the
identification of the target is not a query language issue and that the
target of a query may be a name for a transparently complex query
broker/aggregator?  Just syntax that helps would not make it a requirement
for me.

Is it a protocol issue?  If it were then the protocol is more than a single
HTTP or SOAP interaction.

This is not to say these are things that the use cases wouldn't like to have
this - "2.3 Finding Unknown Media Objects" has 

"""
a query that will be executed regularly against the conglomerate's knowledge
bases. 
"""

which could either be result merging or a query on multiple merged sources
to get cross-KB linkages.  

	Andy "who sees the requirements list growing rather long"

> 
> > -----Original Message-----
> > From: public-rdf-dawg-request@w3.org
> > [mailto:public-rdf-dawg-request@w3.org] On Behalf Of Kendall Clark
> > Sent: 06 May 2004 10:47 To: public-rdf-dawg@w3.org
> > Subject: requirement: multigraph query
> > 
> > 
> > 
> > Requirement
> > -----------
> > It should be possible to specify one or more RDF graphs
> > against which a
> > query shall be executed.
> > 
> > Discussion
> > ----------
> > This requirement admits of two (semantically and
> > operationally distinct)
> > readings:
> > 
> >    - "aggregated query", which is syntactic sugar for multiple
> >      queries, that is, union the results of multiple queries;
> > 
> >    - "union query" over multiple graphs, that is, query
> >      the union of multiple graphs.
> > 
> > My users want both forms; I think we'd settle for the first, weaker
> > form. But if neither of these ends up in our spec, it's the first
> > thing we'll
> > implement, which makes interop hard.
> > 
> > Kendall Clark

Received on Thursday, 6 May 2004 17:10:33 UTC