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

Re: Standardise method for selecting extensions for DESCRIBE

From: Peter Ansell <ansell.peter@gmail.com>
Date: Thu, 24 Jun 2010 10:36:07 +1000
Message-ID: <AANLkTimp1hAu1OCUd_xKP3SUq9GRE53-7zaAx-bTMJ2-@mail.gmail.com>
To: Leigh Dodds <leigh.dodds@talis.com>
Cc: public-rdf-dawg-comments@w3.org

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.



[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 00:36:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:10 UTC