Re: Recommendations for serving backlinks when having hash URIs?

On 10 Feb 2010, at 11:03, Christoph LANGE wrote:
>>> 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?

I'd recommend:

<foo27#bar1> rdfs:seeAlso <slashland/foo27/bar1> .

and then perform standard (non-redirect) content negotiation at  
<slashland/foo27/bar1>, with variants at <bar1.rdf>, <bar1.html> etc.

> 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?

Unfortunately that's a somewhat unsolvable problem. Because at the end  
of the day it's always up to the clients wether they follow your links  
or not, no matter what you call your property (owl:sameAs,  
rdfs:seeAlso, my:mustFollowThisOrDie). The rdfs:seeAlso property at  
least is standard, and thus has a decent probability of being  
understood by a client.

In practice, some clients will understand it and some won't. Hence it  
might be prudent to include some *very* basic information directly in  
your original file at <foo27>, let's say at least an rdfs:label and  
maybe an rdf:type for the <foo27#barNNN> URIs.

Best,
Richard



>
> Cheers, and thanks,
>
> Christoph
>
> -- 
> Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange,  
> Skype duke4701

Received on Wednesday, 10 February 2010 11:21:27 UTC