- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 02 Aug 2004 11:16:47 +0100
- 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. Andy
Received on Monday, 2 August 2004 06:17:16 UTC