Hi,
there isnt a single answer unfortunately.
Lets take symetric concise bound descriptions (SCBD) which basically
means from the uri you'll get triples around it recursively until you
find other URIs. (so when you find a blank node you keep on going).
This seems a pretty good way to provide
Hi Daniel,
From my own experience, there is often a very different set of results
for dereferencing a linked data URI and a DESCRIBE on that URI in a
SPARQL endpoint.
The variance depends on how the linked data is being generated. For
applications that are generating the RDF as an alternate view
On 21/05/2009 00:02, Daniel Schwabe dschw...@inf.puc-rio.br wrote:
On 20/05/2009 17:14, Hugh Glaser wrote:
Sorry, I'll try harder :-)
I understand that what you are asking is something like this.
For some sites (including rkbexplorer), when you resolve a URI, it constructs
a SPARQL query
Peter Ansell a écrit :
Hi,
If you have a dataset that is very large and highly interlinked on
particular URI's, the DESCRIBE response may be too large to reasonably
transmit to a user over the internet (and to expect a sparql endpoint
to give out in one chunk). This is assuming the typical
Hi,
Ok so even if this sounds like a good choice, its easy to see that in
practice this is not sufficient, e.g. james bond would be a URI with
no label if you fetch any of the other 2 nodes.
This is particularly important if we take into account usability.
So probably a SCBDwL (with labels
I think sitemap may already have what you want.
We use slicing=subject-object
For our sets such as:
(See http://acm.rkbexplorer.com/sitemap.xml).
http://sw.deri.org/2007/07/sitemapextension/
Says:
The sc:linkedDataPrefix and sc:sparqlEndpointLocation tags can have an
optional slicing attribute
Sorry, I'll try harder :-)
I understand that what you are asking is something like this.
For some sites (including rkbexplorer), when you resolve a URI, it constructs a
SPARQL query and returns the result of the query.
This might be all the triples with the subject, or object, or both, or
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
Hi,
If you have a dataset that is very large and highly interlinked on
particular URI's, the DESCRIBE response may be too large to reasonably
transmit to a user over the internet (and to expect a sparql endpoint
to give out in one chunk). This is assuming the typical DESCRIBE
behaviour that
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
Kingsley Idehen wrote:
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
11 matches
Mail list logo
