Re: Dereferencing a URI vs querying a SPARQL endpoint

Pierre-Antoine Champin wrote:
> I would expect that a DESCRIBE query to the SPARQL endpoint return what
> I get when dereferencing the URI.
>
>   pa
>   
Daniel,

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 
URI.

Please confirm yay or nay.

Kingsley
> 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
>>>>         
>>     
>
>
>
>
>   


-- 


Regards,

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