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

RE: Use case: Common access

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 30 Mar 2004 15:39:13 +0100
Message-ID: <E864E95CB35C1C46B72FEA0626A2E808028A25D0@0-mail-br1.hpl.hp.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:18 GMT