Re: Dereferencing a URI vs querying a SPARQL endpoint

I would expect that a DESCRIBE query to the SPARQL endpoint return what
I get when dereferencing the URI.

  pa

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

Received on Wednesday, 20 May 2009 20:51:30 UTC