Re: Dereferencing a URI vs querying a SPARQL endpoint

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

Received on Wednesday, 20 May 2009 19:48:31 UTC