W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

Re: Querying multipl sources objective

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 02 Aug 2004 11:16:47 +0100
Message-ID: <410E148F.7050109@hp.com>
To: Jim Hendler <hendler@cs.umd.edu>, "Eric Prud'hommeaux" <eric@w3.org>
Cc: Jos De_Roo <jos.deroo@agfa.com>, public-rdf-dawg@w3.org

I see the first priority for DAWG is the point-to-point case of one 
client application accessing one RDF repository.  If we provide a 
recommendation for the point-to-point case we will be providing 
something useful to the community.  Other models of application 
processing are built on top of this data access functionality.

Innone of the cases of aggregate/federated/union query, there does not 
(to me, at least) seemed to be a clear processing mode that needs 
recommendation support.

Aggregate Query: the value over the client library doing this itself 
seem small and would need no support from the a recommendation to do so. 
  Indeed, the results of one query might influence whether to even ask 
the query at a second place (e.g. find in first means don't need to ask 
at second).

Union Query: (1) There is a scale problem here (2) graph merge isn't 
smushing - sometimes the combination of data sources needs some 
application-domain specific involvement to make it a useful integration. 
  It is only ad hoc union here - if it is server created union, I'd 
expect it to have a URI (service-style or model-style protocol) of its own.

Federated Query: The way the information flows from the first part to 
the second part of the federated query seems to be application-level, 
not data access level (e.g. why a linear flow, why not branching after 
the first query to one of several second parts).  My reservation is that 
there isn't a clear sweet spot emerging yet from systems out there.

Received on Monday, 2 August 2004 06:17:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC