Re: Comments on SPARQL 1.1 Service Description WD 20091022

Hi Greg,

Thanks for the response to my comments, much appreciated. Some
comments on your response :)

2010/1/12 Gregory Williams <greg@evilfunhouse.com>:
>> * 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]
>
> While the service description is intended to represent exactly this sort of thing, I'm not sure the service description vocabulary should make direct reference to features that aren't sanctioned by the SPARQL spec. The sd:feature property can be used to point to any feature IRI, including extensions to SPARQL itself, but the only features I'm inclinded to enumerate in the spec are those that are defined by the spec.

I'd like to make two points here:

1. property functions ARE sanctioned by the specification, they're
permitted both within the syntax and the pattern matching mechanism,
its just that they're not explicitly cited as a possible query engine
feature

2. the purposes of introducing a standard service description
vocabulary however minimal, is to help formalize current practices.
Many SPARQL implementations and extensions exist that use property
functions to extend graph pattern matching in new ways. I don't see
this changing much in the future, so all I'm suggesting is that the
usage is recognised and given a name. There need be no further changes
to the core specification.

The alternative is that the 1.1 service description document doesn't
include a URI for property functions, requiring the implementor
community to define their own, hopefully converging on a single
well-known URI. This would potentially be a specification to define a
single URI, with the prospect of rolling that into SPARQL in some
future update. Wouldn't it be simpler to just do that now?

I've outlined some additional thoughts in this vein at [1].

>> * 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
>
> I don't believe the working group has considered this yet, but I'd be happy to discuss it for inclusion in a future draft.

I'd suggest a simple property annotation on the endpoint description.

> As for the specific case of a default graph (I assume you meant graph and not dataset?) being the union of all named graphs, this is another feature for which we'll be providing a feature IRI. Knowing a service supports this feature probably won't directly indicate whether the default graph is updateable, but it will be an indication that the graph content depends on other graphs.

This is an example of a feature thats not sanctioned in the SPARQL
query language but is going to be described in the service description
because its commonly deployed :)

Cheers,

L.

[1]. http://www.ldodds.com/blog/2009/11/describing-sparql-extension-functions/

-- 
Leigh Dodds
Programme Manager, Talis Platform
Talis
leigh.dodds@talis.com
http://www.talis.com

Received on Monday, 18 January 2010 21:53:15 UTC