Fwd: Standardise method for selecting extensions for DESCRIBE

Before we send an official reply...some question to Greg, to the group: 

While we have not put elaborating more on DESCRIBE on our features list, I think the suggestion is valuable... however, in my feeling it only makes sense if there was at least one concrete proposal out there for defining such an algorithm, with a URI.
Is there such thing at the moment? I think it is out of scope to define it for us.

Opinions?

Axel



Begin forwarded message:

> Resent-From: public-rdf-dawg-comments@w3.org
> From: "Peter Ansell" <ansell.peter@gmail.com>
> Date: 24 June 2010 01:36:07 GMT+01:00
> To: "Leigh Dodds" <leigh.dodds@talis.com>
> Cc: <public-rdf-dawg-comments@w3.org>
> Subject: Re: Standardise method for selecting extensions for DESCRIBE
> archived-at: <http://www.w3.org/mid/AANLkTimp1hAu1OCUd_xKP3SUq9GRE53-7zaAx-bTMJ2-@mail.gmail.com>
> 
> Thanks,
> 
> I would add to that page that it would be useful to define in Service
> Descriptions a list of URIs for Describe algorithms that an endpoint
> supports. I think it is a very powerful addition to the language when
> it is combined with Service Descriptions.
> 
> Hopefully it isn't being ignored just because it isn't graph
> matching/triple based, as there were (are?) objections in the core
> group about Describe even being in the language at all. [3] With this
> extension there is no guessing as to which algorithm is being used so
> queries are always going to execute the same way on the same dataset
> regardless of the implementation, as long as the implementations
> support the type of query as specified in their Service Description.
> The current randomness may be the cause of the current lack of
> interest in developing it because people misunderstand it.
> 
> Cheers,
> 
> Peter
> 
> [3] http://www.w3.org/2001/sw/DataAccess/issues#DESCRIBE
> 
> On 24 June 2010 09:58, Leigh Dodds <leigh.dodds@talis.com> wrote:
> > Hi Peter,
> >
> > This was a feature I'd like to have seen in the language too. I
> > submitted it as a proposed feature during the requirements gathering
> > process. More detail here:
> >
> > http://www.w3.org/2009/sparql/wiki/Feature:ControlOfDescribeQueries
> >
> > But as far as I'm aware its not been selected for standardisation as
> > part of SPARQL 1.1
> >
> > L.
> >
> > On 22 June 2010 23:02, Peter Ansell <ansell.peter@gmail.com> wrote:
> >> Hi,
> >>
> >> 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.
> >>
> >> Virtuoso currently offer this ability using SQL define commands
> >> attached to the front of a SPARQL query [2].
> >>
> >> Personally I never use SPARQL DESCRIBE because I have no way of
> >> knowing which method is going to be used, and I don't want to be
> >> flooded with triples if the method is Symmetric Concise Bounded
> >> Description for instance, and the URI is in the object position of a
> >> large number of statements that are not relevant to me right now. It
> >> would nice to be able to get the ability to discover Blank Nodes in an
> >> Asymetric way, as you can't iteratively find Blank Nodes using the
> >> results of past queries that you can do if all subjects and objects
> >> are URIs.
> >>
> >> 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.
> >>
> >> Sorry if this feature has been brought up before. I couldn't find it
> >> with my searching.
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> [1] http://www.w3.org/Submission/CBD/
> >> [2] http://docs.openlinksw.com/virtuoso/rdfsparql.html#rdfsqlfromsparqldescribe
> >>
> >>
> >> Please consider the environment before printing this email.
> >>
> >> Find out more about Talis at http://www.talis.com/
> >> shared innovation™
> >>
> >> Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited.
> >>
> >> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
> >>
> >
> >
> >
> > --
> > Leigh Dodds
> > Programme Manager, Talis Platform
> > Talis
> > leigh.dodds@talis.com
> > http://www.talis.com
> >
> 
>