Comments on SPARQL 17-Feb-2005 draft


Now I think I've just about internalized the main features of this draft, I 
have some more feedback.  Essentially, I fear that it's overcomplicated, 
and could use some streamlining.  Specific features that I feel could be 
removed or simplified are:
   Multiple-graph queries
   DESCRIBE result type
   Required SPARQL operators
(more details below)

I don't object to these being defined possibilities, but I feel they 
represent an onerous implementation burden relative to their utility, and 
thus should not be part of the mandatory SPARQL core in their present form, 
to the extent that the same results can be achieved (modulo efficiency 
concerns) without the full capabilities currently described.  If they are 
retained as optional features of SPARQL, I would prefer to seem them 
specified in separate documents, or in appendices to the core specification.

1. Multiple-graph queries

I think these should be removed from the basic SPARQL core, since I feel 
they add a fair deal of implementation complexity and an application can 
achieve the same result by submitting multiple queries, possibly to 
different query processors.

I also feel it would be premature to standardize an approach to multi-graph 
querying ahead of there being a consensus/standard for something like RDF 
named graphs.

I recognize that there are certain efficiencies which can be achieved only 
by allowing a client to submit such a query to an intelligent query 
processor, and think it should be possible to extend the basic SPARQL 
language cleanly to accommodate such queries.

2. DESCRIBE result type

I think the desired effect could be achieved using standard SPARQL queries 
with some special RDF vocabulary, or maybe in conjunction with something 
like Larry Masinter's tdb: URI scheme proposal 
(  Therefore, I think it has NO PLACE 
in the base SPARQL specification, since it adds to implementer burden 
without creating any otherwise-unavailable functionality.

I will almost certainly not include this in my implementation.

3. Required SPARQL operators

This is less clear-cut to me, but I think there are some of the specified 
operators that don't need to be mandatory in every implementation, there 
being an extension mechanism to fall back to.

I think a minimal set of operators might be string and numeric comparisons, 

The XQuery connectives appear to duplicate the union and intersection 
(group) graph patterns.

Although date/time tests are clearly useful for a significant class of 
applications, I don't think they are needed for all applications, and could 
be optional.

Similarly, I can see regex matching is useful but not always essential, and 
it does in some cases impose a significant implementation burden if the 
right form of regex library happens not to be available -- I think this 
feature should be optional.


While considering value-testing options:

Concerning extensibility of value testing operations, I think there should 
be an option to treat unrecognized tests as "True" rather than failures, 
this resulting in additional query results being returned that can be 
filtered by the client (thus allowing a client application to work with 
different query processors with differing support for value testing functions).

I also think that it would be useful if there is a mechanism to discover 
what value testing operations are supported by a query processor, maybe as 
part of the protocol, or simply using some special RDF vocabulary to make 
queries about the processor itself (I favour the latter).


In our research group, we have a strong requirement to perform stemmed 
string matching in RDF queries, which is handled natively by the underlying 
database.  (This project is using Jena on Postgres, and to achieve this 
functionality we currently have to perform an evil hack which involves 
manipulating Jena's underlying database schema, so we can use the Postgres' 
test-stemming search directly.  Ugh!!)

Extensible value-tests in SPARQL seems to be the right way to address this 
kind of problem, so that a query processor supporting this feature can make 
maximal use of the underlying capabilties.  I mention this here simply so 
that the requirement can be noted as a desideratum for SPARQL.


I also have some further comments about details of the specification, some 
substantive, but they'll have to wait for another message.


Graham Klyne
For email:

Received on Friday, 8 April 2005 08:56:00 UTC