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
