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

Re: Recommendations for serving backlinks when having hash URIs?

From: Christoph LANGE <ch.lange@jacobs-university.de>
Date: Wed, 10 Feb 2010 12:03:27 +0100
To: Richard Cyganiak <richard@cyganiak.de>
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-Id: <201002101203.29133.ch.lange@jacobs-university.de>
Hi Richard,

2010-02-10 02:43 Richard Cyganiak <richard@cyganiak.de>:
> On 9 Feb 2010, at 23:17, Christoph LANGE wrote:
> > [lots of musings on how it could(n't) be done with hash URIs]
> > 
> > ...
> > 
> > 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.

Thanks, that sounds very "reason"able (both in the English and in the formal
sense)!

So far the MIME type for which we will most urgently need such a solution is
indeed RDF.  However, if we should also need the hash→slash redirection for
other MIME types, would you rather recommend adding e.g.

foo27#bar1 rdfs:seeAlso slashland/foo27/bar1.html .

or would it then be preferable to resort to my initial approach and perform
content negotiation and 303 redirects on the slash URIs?

Another question is how to deal with the weak semantics of rdfs:seeAlso here.
In _our_ application we can of course hard-code that whenever a hash URI is
encountered, the rdfs:seeAlso link (if existing) must be followed first.  But
then how would other clients know that in this setup the rdfs:seeAlso is not
just anything optional/additional that you can follow or not, depending on
what the user is interested in, but that it _should_ _really_ be followed in
order to retrieve even basic information about the resources?  Is it safe to
expect that any "reasonable" linked data client, when the only triple that it
finds when crawling is rdfs:seeAlso, assumes a closed world and somehow
guesses that it _has_ to follow that link in order to find out more?

Cheers, and thanks,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
Received on Wednesday, 10 February 2010 11:04:07 UTC

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