W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2009

Comments on SPARQL 1.1 Service Description WD 20091022

From: Leigh Dodds <leigh.dodds@talis.com>
Date: Sat, 24 Oct 2009 14:27:58 +0100
Message-ID: <f323a4470910240627q447dcfb0jbaf80e3b4ea77817@mail.gmail.com>
To: public-rdf-dawg-comments@w3.org
Hi,

Here are some personal comments on the SPARQL 1.1 Service Description
Working Draft published on 22/10/2009.

* Section 3.2.2 sd:Language. It would be useful to clarify the text to
indicate that the "subset of the SPARQL language" that is being
described is either SPARQLQuery or SPARQLUpdate. My initial reading
was that the class was to be used to describe subsets of the SPARQL
*query* language, but I don't think this is what is intended.

* Section 3.2.3 sd:Function. This section lists scalar functions,
aggregate functions and entailment regime. It ought to be updated to
include an entry for property functions; these features are
implemented in a number of processors already and are an important
capability to be able to document. I've written up some notes on
different forms of SPARQL extension here [1]

* Section 3.4.7/3.4.8. Using the provided functionality I can refer to
a dataset that the endpoint exposes, but in the circumstances where an
endpoint exposes multiple datasets and/or graphs I cannot yet state:
this one is the default. Ideally there should be a way to indicate
which of the described datasets (if any) will be used as the default
of the query or protocol request doesn't include a dataset

* One important aspect of SPARQL endpoints is whether they use a fixed
dataset or allow an arbitrary dataset to be constructed for the
purposes of the query, e.g. by fetching data from URI specified in the
FROM/FROM NAMED claused. It would be useful to be able to describe
this capability in the service description. Simply omitting a dataset
description in this case it ambiguous (the dataset may still be
"fixed" but its just not described. One option would be to include an
additional sub-type of endpoint to allow them to be classified in this
way.

* The SPARQL protocol document notes that a SPARQL endpoint may refuse
to process a request if a dataset is not specified. Perhaps this
potential behaviour should be documented in the service description,
e.g. indicating that one of the described datasets must be used in the
protocol or query

*  Section 4.1, "Graph Store and SPARQL Query Services" of the SPARQL
1.1 Update document notes that the graphs for the update service may
differ from those offered by the query service. In the present Service
Description specification I don't see a way to indicate that one or
more datasets are to be used for the update service while others may
only be available for query. A simple and common example of this would
be a dataset which is the union of all stored named graphs in the
Graph Store. This is a feature of several SPARQL implementations but
this dataset is unlikely to be available for manipulation through
SPARQL Update, etc.

Cheers,

L.

[1]. http://www.ldodds.com/blog/2009/10/surveying-and-classifying-sparql-extensions/

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@talis.com
http://www.talis.com
Received on Saturday, 24 October 2009 13:28:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 24 October 2009 13:28:32 GMT