The Case For Redirection (was Re: Some Requirements)

> > On behalf of RDF authors everywhere, I'd like to make a URI which is
> > usable in several, simultaneous ways: 
> > 
> >   r1.  As a not-overloaded name, essentially a logical constant term,
> >        as specified in RDF Semantics [1].   The URI will be my name
> >        for something; others may make other names for the thing or
> >        reuse my name for it. 
> 
> Seems already covered.
> 
> >   r2.  As a web page address for human-readable content, working in
> >        currently-deployed browsers, giving users direct access to web
> >        content which I supply associated with the URI;
> > 
> >   r3.  As a web address for RDF/XML content, allowing simple systems
> >        to fetch a small to medium size knowledge base, which I supply,
> >        associated with the URI
> 
> Can't you use content negotiation for this?  

Sort of.  See below.

> >   r4.  As the address of a query answering service, allowing more
> >        complex systems faster access to larger knowledge bases, which
> >        I also supply associated with the URI
> 
> I don't know how this would work.  Which knowledge base?  How is it related
> to the URI reference with optional fragment identifier?

r3 and r4 both involve access to the RDF knowledge base that the host of
the URI provides for people asking about it; the difference is that
with r3 you get a dump of the whole thing; with r4 you get to pose
your query, eg with DQL.

> It seems to me that you can already do all this.  Use a URI reference with
> a fragment identifier as the name.  The web page and the RDF/XML content
> (and maybe OWL content (and maybe FOL content (and ...))) can all live at
> the URI address.  The query answering system could also live there, I
> guess.
> 
> So you have
> 
> 	http://sandro.org/foaf#sandro		for the name
> 	http://sandro.org/foaf.html		for the human readable page
> 	http://sandro.org/foaf.rdf		for the RDF/XML content
> 	(http://sandro.org/foaf.owl		for the OWL content)
> 	http://sandor.org/foaf#sandro?...	for other purposes
> 
> All, except the last, would be accessible via
> http://sandro.org/foaf#sandro.  The last, I think, needs extra parameters,
> and thus can't be just http://sandro.org/foaf#sandro.  
> 
> This has the advantage that related names can share URIs.

With the right view of content negotiation, this might work.  But I'm
not sure it's possible.  This brings up the issue of what
"representation" means in HTTP, since content negotiation allows
selecting one representation from among many, according to its
media-type (aka MIME type, aka content type).

If you tried to fetch <http://sandro.org/foaf#sandro> (which would be
truncated to <http://sandro.org/foaf> before going out) with "Accept:
text/html" you would presumably get back a representation of
http://sandro.org/foaf.html (that is, you would receive a
serialization of a hypertext doument) and would probably think your
original URI identified an anchor in that document.

If you tried to fetch the same URI with "Accept: application/rdf+xml"
you would presumably get back a representation of
http://sandro.org/foaf.rdf (that is, you would receive a serialization
of an RDF graph) and would probably think your original URI identified
an instance of foaf:Person.

So this doesn't seem so good.  I've been over this and over this, and
have been unable to find a way to get both r2 and r3, with URIs like
http://foo#bar.

> You could even use redirection to use a URI reference without a fragment
> identifier.  I think, however, that this is a mistake.

With redirection and no fragment identifiers, I can get r2 and r3:

1.  You fetch http://sandro.org/foaf/sandro with "Accept: text/html"
    and you are redirected to http://sandro.org/foaf/sandro.html, a web
    page about sandro (me).

2.  You fetch http://sandro.org/foaf/sandro with "Accept:
    application/rdf+xml" and you are redirected to
    http://sandro.org/foaf/sandro.rdf, an RDF/XML document which
    probably says some formal things about me, referring to me as
    <http://sandro.org/foaf/sandro>.

The redirection is important if we interpret "representation"
strictly, since it lets us give an answer without claiming the
returned byte string is "a representation" of the thing you asked
about.  The "303 See Other" redirection says "I'm not going to give
you a representation; why don't you ask over there...."

It's also important if you want to help users keep straight the
difference between the URI of a person and the URI of a web page about
the person.  That is, I'd like people to distinguish between saying

     <http://sandro.org/foaf/sandro> a Liar.      # that person lies

and
     <http://sandro.org/foaf/sandro.html> a Liar. # that page lies
	
and the redirection helps keep that clear, by changing what's
displayed in the "Address" or "Location" bar.

Also, we can get r4, too: the RDF/XML document at
http://sandro.org/foaf/sandro.rdf can describe some query answering
services and declare them to be as authoritative as itself.


> > Also, ideally:
> > 
> >    x1.  This would all work beyond the time over which I can
> >         reasonably expect to control any particular domain name or
> >         website;
> 
> This is *much* harder.  I believe that it would need a significant upgrade
> to WWW mechanisms, essentially a way of specifying a temporal component in
> URIs and redirecting somehow based on this temporal component.  I don't
> see this happening, ever.

My clever hack here is to include an improbably string in the URI and
recommend people assume that all URIs containing that string are
owl:sameAs each other.  When systems fail in a primary dereference
operation that can fall back to a secondare one of looking for other URIs
containing that improbable string.    (I don't think there's a google
for URI substrings, but it's probably a lot easier then searching for
things which are declared somewhere to be owl:sameAs your now-404 URI.)


> >    x2.  This would work even if a community of use arises which
> >         disagrees with me about what the URI names.  I made it
> >         up, I was the first to use it, no one should be able to
> > 	make me into a liar by convincing people it meant something
> >         different. 
> 
> I think that most solutions will have this property.

I'd like to see an example of that.  My best guess here is to embed a
cryptographic hash of an introductory use into the URI; then I can
always whip out that introductory use and show whether something is
(in)consistent with it.   (And yeah, the hash is clumsy, but at least
it doubles as my improbable string for x1.)

     -- sandro

Received on Thursday, 25 September 2003 14:09:16 UTC