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
