RE: requirement: multigraph query

Jos,

Would your usage be covered by specifying the multiple graphs in the
protocol?  You said "unioning the graphs" - does that include executing the
query and taking into account linkages between the graphs, rather than the
aggregation of results case.

- - - -

There seem to be three design points in identying the source:

+ In the query language
+ By service access point (SAP) where the query is sent
+ In the protocol, sending a list of graph names as arguments.

(Loosely, a GET makes SAP and selected resource the same URI.)

We can make the selection of graphs part of the protocol, part of the query
language, or a feature of the SAP used; this is the service-oriented framing
of giving a name to the combined graph before hand.

Normally, choosing the target for the query is a local API issue.  It is
because there isn't a web place where the combination resides that measn we
would have to do something.

The example of a request from a cell phone to have all friend's RSS feeds
checked is the same query on a number of graphs, where the graphs are not
identifed by the SAP.  The saving is sending the query once, but asking for
execution against multiple sources (it was left open as to whether
crosslinking between the sources is done).  Results are returned as a union
- not much saving there.  It is easier for the phone to manage the process
if it offloads the multiple graph nature of the request.

The original text was:

] Requirement
] -----------
] It should be possible to specify one or more RDF graphs against
] which a query shall be executed.

I can live with the wording because it allows for it to be a protocol
matter.  It even includes the case where things are set up before hand, such
as the mobile phone saying "create this grouping" at some time in the past,
getting back a URL, then executing the query on that URL.  Like querying an
RSS aggregator - this could even be beneficial because the grouping can be
reused and precached.

I would expect comments from the wider community on this requirment as it
can also be read as suggesting it that either a real aggregation is created
per query or that query routing is being done.  Any suggestions for
clarifying that?

	Andy

-------- Original Message --------
> From: Jos
> Date: 6 May 2004 23:49
> 
> KendallC wrote:
> [...]
> > > If we're talking about aggregating a bunch of separate RDF
> > > repositories, this seems clearly out of scope.
> > 
> > First, I didn't say a *word* about "RDF repositories". I said multiple
> > graphs; either querying each graph and unioning the results, or
> > unioning the graphs then executing the query against it. That's
> > got nothing whatever to do with RDF repositories (which is a function
> > of how we *name* the multiple graphs, a position I didn't
> take in the
> requirement).
> 
> Now I finally know what an RDF repository means :)
> I also can't live without "unioning the graphs
> then executing the query against it" (which is in
> our experience definitely not the same as "querying
> each graph and unioning the results", but that's
> maybe because we mix RDF graphs with RDF formulae..)

Received on Friday, 7 May 2004 08:21:35 UTC