Re: Standardise method for selecting extensions for DESCRIBE

I agree and have seen the situation Kendal describes - there is no right 
description to return and it's good the application or data provider can 
do "the right thing" for their needs.

The client does not necessarily know the right thing and a bunch of 
queries to probe the data or CONSTRUCT queries is not useful


CONSTRUCT is the way the client control triples returned; DESCRIBE is 
the way the service controls the triples.  There is an argument that it 
is CONSTRUCT that needs to be expanded.

And do we need some kind of content negotiation for graph returned?

It might be useful to name some common patterns in Service Description 
but just agreeing the details is not an insignificant amount of work.

 Andy

On 24/06/2010 15:41, Kendall Clark wrote:
> 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
>>>>
>>>
>>>
>>>
>>
>
>
> 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.

Received on Thursday, 24 June 2010 17:44:11 UTC