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

Re: Minutes of RDF DAWG telcon 2005-08-09 for review

From: Dan Connolly <connolly@w3.org>
Date: Tue, 09 Aug 2005 11:35:47 -0500
To: Janne Saarela <janne.saarela@profium.com>
Cc: DAWG public list <public-rdf-dawg@w3.org>
Message-Id: <1123605348.18971.946.camel@dirk>

Thanks for the quick minutes, Janne.

I have an ammendment to offer...

On Tue, 2005-08-09 at 19:05 +0300, Janne Saarela wrote:
> RDF Data Access Working Group
> http://www.w3.org/2001/sw/DataAccess/
> Tuesday 2005-08-09 14:30-16:30 UTC
> log: http://www.w3.org/2005/08/09-dawg-irc
[...]

> 3. toward Protocol last call
> 
[...]
> PROPOSED: a SPARQL service _must_ return MalformedQuery for queries that 
> are not SPARQL Query Strings
> RESOLVED, W3C/EricP and UMD/KC abstaining

The record should show the arguments we considered here...

We considered the case of a server that supports extensions
to the SPARQL query language; i.e. strings that don't match
the grammar... a so-called SPARQL++ service.

Should clients put these extended queries thru the existing
SPARQL interface? Or should they use a different interface?
For example, svc?query2=...extended-query... as opposed
to svc?query=...extended-query... .

A somewhat liberal approach is that a SPARQL server _may_ issue
MalformedQuery when an extended query is passed in the
query= slot, or it may support the extended query and run it.

The risk with the liberal approach is:
 1. naive user finds SPARQL service A, not realizing that
   A is also a SPARQL++ service, and uses one of the extended
   features and gets the impression that it's part of the
   standard SPARQL language

 2. naive user tries this same query on SPARQL server B,
   and gets MalformedQuery, and concludes, mistakenly,
   that B is broken, rather than realizing that A was extended.

A more conservative approach is to require SPARQL servers
to reject queries that don't match the grammar when they come
thru the standard interface, and require
that extensions be deployed some other way: at a different
endpoint, or using different parameter names; some sort
of different WSDL interface.

The risk with the conservative approach is that service
builders will go wild with extensions as per the liberal
approach anyway, and there just won't be a good match between
our spec an what's deployed.

Preferences for each side were expressed, and, in some cases,
changed during the discussion. This seems to be as much
a social question and a prediction about the medium-to-long-term
future as a technical design question that we could be more confident
of after a small number of weeks of study.

The chair considered that the conservative design was in some
ways more simple and mature, and in any case seemed to have
a critical mass of support and no objections, and so he
put the question.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Tuesday, 9 August 2005 16:35:52 GMT

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