W3C home > Mailing lists > Public > public-lod@w3.org > February 2010

Re: Recommendations for serving backlinks when having hash URIs?

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 10 Feb 2010 01:43:43 +0000
Cc: public-lod@w3.org
Message-Id: <51ACCFB5-37CB-45DD-9F33-DC4A4629188B@cyganiak.de>
To: Christoph LANGE <ch.lange@jacobs-university.de>
Hi Christoph,

On 9 Feb 2010, at 23:17, Christoph LANGE wrote:
>  are there any guidelines on how to reasonably restrict the number  
> of served
> RDF triples when
>
> * the linked data served should also include backlinks (i.e. triples  
> that have
>  the requested resource as object), as is good practice
> * hash URIs are used (and therefore a server response contains a lot  
> more than
>  what the client actually needs)
> ?
>
> In our setting, we are bound to use hash URIs for certain resources,  
> as the
> URI syntax conventions have existed before the age of linked data.   
> Suppose we
> have resources with URIs like fooX#barY, such as foo23#bar57.   
> Suppose that
> the RDF on the server is not served from static files fooX.rdf, but  
> from a
> triple store, and thus the server has some flexibility w.r.t. what  
> exactly to
> serve.  Now suppose a client is interested in foo27#bar4 and  
> therefore (hash
> URIs!) has to request foo27 from the server.  Then, the server would  
> at least
> have to return a lot of triples having any of the foo27#barY as  
> subject, e.g.
>
> foo27#bar1 :someprop foo27#bar56 .
> foo27#bar2 :someprop foo33#bar1 .
> foo27#bar4 :someprop foo66#bar89 .
>
> Additionally we would like to get some triples having foo27#barY as  
> an object,
> but again the server does not know that the client is only  
> interested in
> foo27#bar4.
>
> Of course any reasonable approach to pick the most "relevant"  
> triples depends
> on the specific vocabulary and application, but still, are there any
> guidelines?  Or should we rather consider ways of mapping hash URIs  
> to slash
> URIs?  Are there standard approaches?  I could imagine that e.g. for  
> foo27 the
> server could return only these triples:
>
> foo27#bar1 owl:sameAs slashland/foo27/bar1 .
> foo27#bar2 owl:sameAs slashland/foo27/bar2 .
> ...

Maybe simpler:

foo27#bar1 rdfs:seeAlso slashland/foo27/bar1.rdf .
foo27#bar2 rdfs:seeAlso slashland/foo27/bar2.rdf .
...

And then serve up the detailed description inside the *.rdf files,  
while still using the hash URIs inside these files. This limits the  
complication to the RDF file level, without requiring messing about  
with multiple URI aliases.

Best,
Richard



>
> and that then the client would issue a second request to  
> "slashland", where a
> reasonable response of links and relevant backlinks could be  
> computed more
> easily.
>
> Cheers, and thanks in advance for any help,
>
> Christoph
>
> -- 
> Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange,  
> Skype duke4701
Received on Wednesday, 10 February 2010 01:44:19 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:25 UTC