Re: Design Review of SPARQL query 1.293 (valueTesting, DESCRIBE)

On Thu, 2005-04-07 at 16:08 +0100, Dave Beckett wrote:
[...]
> 
> The expression stuff including datatypes is just working on the
> detail and looks on the right track, I can't see any big problems
> with the current approach.

EricP, Dave, please note some recent comments...

[[
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, 
plus the SPARQL tests BOUND, ISURI, ISBLANK, ISLITERAL.

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.

...
]]
-- Klyne in Comments on SPARQL 17-Feb-2005 draft
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Apr/0010.html


> DESCRIBE is looking rather odd, as I learnt it wasn't quite what I
> thought it was having read through the document fully.

That message also comments on DESCRIBE, but that's old news; that
issue is closed.

> Dave
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 8 April 2005 19:46:37 UTC