Re: Standardise method for selecting extensions for DESCRIBE

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 13:28:56 UTC