From SPARQL Working Group
> 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  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 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 <http://www.example.org/closure/concise-bounded-desc> ; ...
Does this use of sd:feature fit your needs?
thanks, Gregory Williams (on behalf of the SPARQL Working Group)