From SPARQL Working Group
Revision as of 01:22, 13 July 2010 by Gwilliam (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
> 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.


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.

> 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 <> ;

Does this use of sd:feature fit your needs?

thanks, Gregory Williams (on behalf of the SPARQL Working Group)