Re: Standardise method for selecting extensions for DESCRIBE

On 1 August 2010 05:04, Gregory Williams <greg@evilfunhouse.com> wrote:
> On Jun 22, 2010, at 6:02 PM, Peter Ansell wrote:
>
>> It would be nice with the SPARQL review if there could be a minor
>> change to the DESCRIBE query syntax to support optional selection of
>> the way DESCRIBE should work.
>>
>> For example, even if I know that my SPARQL endpoint supports different
>> types of DESCRIBE queries, such as Concise Bounded Description [1] and
>> Symmetric Concise Bounded Description and basic Subject Predicate
>> Object (with or without inferences), there is no standard way of
>> telling a DESCRIBE query to use one over the other.
>>
>> A syntax may be "DESCRIBE [USING <METHODURI>] <URI>" or any other way
>> that is substantially backwards compatible. The METHODURIs for some
>> common methods could be suggested, with any new methods being easily
>> extensible using URIs that anyone else publishes.
>>
>> This wouldn't change the best guess approach that was originally
>> standardised for DESCRIBE, but it would give a user some standard way
>> of selecting their preferred DESCRIBE method in some cases.
>
> Peter,
>
> The ability to choose a DESCRIBE algorithm was one of the features proposed[1]
> for inclusion in SPARQL 1.1. However, compared to several other features which
> will be in SPARQL 1.1, there was little support within the working group for
> standardizing a means of choosing a DESCRIBE algorithm.

It is a shame that it didn't make the list. Hopefully it makes the
shortlist in future revisions. Describe is a potentially very useful
tool but it is underspecified currently. Maybe this feature will end
up being implemented before it is specified.

>> Even if this feature doesn't get through, it would be nice to have the
>> DESCRIBE query method as a required element the SPARQL Service
>> Description so I could at least identify the method that would be used
>> by default for an endpoint.
>
>
> The SPARQL 1.1 Service Description document currently describes a sd:feature
> property meant for use in describing arbitrary features of a SPARQL endpoint.
> Provided a URI for a DESCRIBE algorithm, a service description could describe
> its implementation with:
>
>  [] a sd:Service ;
>        sd:feature <http://www.example.org/closure/concise-bounded-desc> ;
>        ...
>
> Does this use of sd:feature fit your needs?

If we have to rely on sd:feature, a user would need to recognise which
of the triples referred to filter extensions and which refer to the
describe algorithm. If there are only a few commonly used describe
algorithm URIs then sd:feature would be a usable workaround.

I would prefer something like the following:

[] a sd:Service ;
      sd:defaultDescribeAlgorithm
<http://www.example.org/closure/concise-bounded-desc> ;

Cheers,

Peter

Received on Sunday, 1 August 2010 01:52:27 UTC