- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 30 Mar 2004 15:39:13 +0100
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
-------- Original Message -------- > From: Patrick Stickler <mailto:patrick.stickler@nokia.com> > Date: 30 March 2004 09:51 > > I like the gist of this use case. A possible variant could > also address distributed/federated query, where the query > broker simply maintains a set of URIs denoting DAWG compliant > portals, and addition of new sources is done simply by adding > to that set of URIs. > > Patrick It would be good to keep this base case simple (one device, contacting several places) and creating a separate distributed/federated query use case as an extension of this even if it is the query broker style you describe. This keeps the use cases clear - it seems to me that adding too many ifs/buts to a use case means distracting from agreeing the core. Andy > > On Mar 29, 2004, at 19:32, ext Seaborne, Andy wrote: > > > > > > > > > == Task > > > > A support engineer wants to find the telephone number of a person > > called "Fred Bloggs", a person he has not spoken to before but one of > > his workgroup colleagues has. The information may be one of several > > databases (information may be quite new, a workgroup may have > > different databases for different support situations for historical > > reasons). > > > > The support engineer has a phone number look facility on his PDA. > > This software knows the query needed based on FOAF but needs to be > > told where to ask the query. > > > > == Importance of DAWG > > > > In order to ask the same query of different databases, the software > > tool needs to know what protocol to use. The DAWG recommendation > > provides a common way of doing this so the software tool does not > > need to do anything different except change the destination of the > > query. > > > > End-users benefit in seamless access to a wider variety of data > > sources. Application providers benefit from wider access to different > > kinds of data sources without needing to provide specific software; > > similarly for server software providers. > > > > == Other > > > > This is a common access protocol use case. By having one common > > protocol, the same client-side software can be used with different > > datasources even if the software was written independently of the > > database interface. It does not matter which implementation of a > > web-based interface is used. > > > > The protocol should use already deployed technology (SOAP and/or > > HTTP) to reduce the deployment burden. The DAWG rec. need only > > describe how to package the query and the details of the result. > > > > The ability to execute queries from a small device suggests a > > lightweight usage of HTTP or SOAP, or at least a lightweight subset. > > > > It is possible that the DAWG-QL will not cover all possible > > situations. The protocol could be used to carry other queries, in > > specialised query languages, in the same general framework.
Received on Tuesday, 30 March 2004 09:55:52 UTC