W3C home > Mailing lists > Public > semantic-web@w3.org > May 2009

Re: Dereferencing a URI vs querying a SPARQL endpoint

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 20 May 2009 22:10:17 -0400
Message-ID: <4A14B809.7040401@openlinksw.com>
To: Pierre-Antoine Champin <swlists-040405@champin.net>
CC: Daniel Schwabe <dschwabe@inf.puc-rio.br>, semantic-web@w3.org, public-lod@w3.org
Pierre-Antoine Champin wrote:
> I would expect that a DESCRIBE query to the SPARQL endpoint return what
> I get when dereferencing the URI.
>   pa

Is this your problem:

Linked Data Servers publish URIs. The mechanism that delivers these URIs 
tends to vary since they are the product of URL-rewrite rules that may 
or may not be associated with SPARQL queries, and when SPARQL Query 
based you may be dealing with a CONSTRUCT or a DESCRIBE.

Ideally, you would like to be able to discern via SPARQL, what SPARQL 
query patterns sits behind the re-write rule for a given de-referencable 

Please confirm yay or nay.

> Daniel Schwabe a écrit :
>> Dan and Hugh,
>> let me be more specific.
>> I'm not really advocating that only *one* direction should be returned
>> (or even both directions).
>> I am asking a more general question (to which I don't think Hugh really
>> gave an answer either) which is, is there any query that returns the
>> same triples as the ones you get when you dereference a URI, in a site
>> that also provides a SPARQL endpoint?
>> In the affirmative case, I am suggesting that the corresponding query be
>> documented in the sitemap.xml document.
>> Does this make sense?
>> Cheers
>> D
>> On 20/05/2009 14:15, Dan Brickley wrote:
>>> On 20/5/09 18:59, Daniel Schwabe wrote:
>>>> Dear all,
>>>> while designing Explorator [1], where one can explore one or more triple
>>>> repositories that provide SPARQL enpoints (as well as direct URI
>>>> dereferencing), I found the following question, to which I don't really
>>>> know the answer...
>>>> For the sake of this discussion, I'm considering only such sites, i.e.,
>>>> those that provide SPRQL enpoints.
>>>> For a given URI r, is there any relation between the triples I get when
>>>> I dereference it directly, as opposed to querying the SPARQL enpoint for
>>>> all triples <r, ?p, ?o> ? Should there be (I could also get <?s, ?p, r>,
>>>> for example) ?
>>>> For sites such as dbpedia I believe that I get the same set of triples.
>>>> But I believe this is not a general behavior.
>>>> Should there be a good practice about this for LoD sites that provide
>>>> SPARQL endpoints?
>>>> At the very least, perhaps this could also be described in the semantic
>>>> sitemap.xml, no?
>>> In general, I'd be wary of doing anything that assumes the direction a
>>> property is named in is important.
>>> Taking the old MCF example,
>>> http://www.w3.org/TR/NOTE-MCF-XML-970624/#sec2.1
>>> the_songlines eg:author bruce_chatwin .
>>> where eg:author has a domain of Document and a range of Person.
>>> Exactly the same information could be conveyed in data where the
>>> property naming direction was reversed. And case by case, different
>>> natural languages and application environments will favour slightly
>>> one direction over the other. Here we could as well have had
>>> bruce_chatwin eg:wrote the_songlines .
>>> or eg:book or eg:pub or eg:xyz, with domain Person, range Document.
>>> As it happens in English, the word "author" doesn't have a natural and
>>> obvious inverse here but that's incidental. The point is that both
>>> forms tell you just as much about the person as about the document,
>>> regardless of property naming and direction. The form using
>>> "eg:author" seems to be document-centric, but in fact it should
>>> equally support UI layers that are concerned with the person or the
>>> document. It would be dissapointing if a UI that was presenting info
>>> about Bruce Chatwin was to miss out that he was the author of
>>> the_songlines, simply because somewhere along the line a schema writer
>>> chose to deploy a property "author" rather than "wrote"...
>>> cheers,
>>> Dan
>>>> [1] http://www.tecweb.inf.puc-rio.br/explorator



Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Thursday, 21 May 2009 02:11:02 UTC

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