Re: Standardise method for selecting extensions for DESCRIBE

We recently looked at this for one of our products (search over RDF) and found 4 or 5 distinct notions of how to do DESCRIBE. We implemented all of them because no one of them would be sufficient for most of our users' requirements.

I think status quo re: DESCRIBE should be maintained. It's under-specified but it's a hook and hooks are useful.

Cheers,
Kendall

On Jun 24, 2010, at 6:28 AM, Paul Gearon <gearon@ieee.org> wrote:

> Perhaps this is out of scope, but I'd like to see it. Personally,
> DESCRIBE is completely useless without a formal definition, and as
> such I never use it. I always opt for a CONSTRUCT instead, as that is
> properly defined.
> 
> Regards,
> Paul Gearon
> 
> On Thu, Jun 24, 2010 at 2:59 AM, Axel Polleres <axel.polleres@deri.org> wrote:
>> 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
>>> 
>> 
>> 
>> 
>

Received on Thursday, 24 June 2010 14:41:30 UTC