Re: Dereferencing a URI vs querying a SPARQL endpoint

On 21/05/2009 00:02, "Daniel Schwabe" <dschwabe@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 and returns the result of the query.
>> This might be all the triples with the subject, or object, or both, or
>> something more complex that takes into account b-nodes.
>> So it might be nice if somewhere, such as the sitemap.xml, this query was
>> documented.
>> I think this is exactly what the "slicing" is trying to do, but instead of
>> publishing the actual query, it names the common (obvious) ones to use.
>> So a "slicing" of "subject" would tell you that you could do the query you
>> say below on the appropriate SPARQL endpoint and get exactly the same thing
>> you would get by resolving the URI.
>> So I still think that answers your question, but I'm sure you can tell me if
>> it doesn't :-)
>> 
>>  
> Ok, I see your point. However, I don't see *which* of the various
> slicings described is the one returned (ie, the equivalent query) when I
> resolve a URI... or do you mean it is always the "subject" slicing?
Yes.
> Where is this stated that this slicing is what you get when resolving
> the URI?
I think that is exactly what the sitemap is saying.
But not "the" URI - all URIs at that sc:linkedDataPrefix> or
<sc:sparqlEndpointLocation>.
So my understanding of the semantic sitemap extension says that a sitemap
that has:
<sc:linkedDataPrefix
slicing="scbd">http://example.com/products/</sc:linkedDataPrefix>
<sc:linkedDataPrefix
slicing="subject">http://example.com/customers/</sc:linkedDataPrefix>
means that any URI with prefix http://example.com/customers/ will have been
constructed from a subject-style query and any URI with prefix
http://example.com/products/ will have been constructed from a SCBD.
Best
Hugh
> 
> Cheers
> D
> 
> 
> 
> 
> 
>

Received on Thursday, 21 May 2009 09:07:50 UTC