W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

Re: Standardise method for selecting extensions for DESCRIBE

From: Paul Gearon <gearon@ieee.org>
Date: Thu, 24 Jun 2010 06:28:23 -0700
Message-ID: <AANLkTilzOO2BQGZBGL9awRb0pJve296g6ba57VIil9eT@mail.gmail.com>
To: Axel Polleres <axel.polleres@deri.org>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Gregory Williams <greg@evilfunhouse.com>
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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:00 UTC