Re: opaque uris and self-describing resources

> paul, stop these nasty questions ;-)
> 
> Paul Prescod wrote:
> > On Jan 15, 2008 4:36 PM, Noah Slater <nslater@bytesexual.org> wrote:
> >> Also, saying "std:in" carries absolutely no semantics by it's
> >> self. Sure, you could publish a HTML profile somewhere, but you're
> >> missing out on being able to advertise this profile's location using
> >> the name it's self.
> > If there is an HTML page at these links then how do you distinguish
> > between a GET intended to get those pages from a GET intended to read
> > from STDIN?

First off, I think stdin, etc, is an excellent example of something
which, if it's going to be a URI, should *not* be an http URI.  (For the
reasons given earlier, about how software not familiar with this
proposed new convention would respond.)  

That said, if you were to still use HTTP here, you could make the
distinction in the (TAG) standard way: look at the HTTP response codes.
(more below.)

> this goes right down to the core of some pretty fundamental problems 
> with the semantic web's fuzzy way of handling identity. steve pepper 
> (http://lists.w3.org/Archives/Public/uri/2007Dec/0076.html) just 
> refreshed our memory that even though the problem has been known for a 
> long time and is pretty essential, nobody seems to really care as long 
> as they can happily juggle lots of triples... ;-)
> 
> i guess the more specific answer would be that if you GET the profile in 
> some html page, then if you do understand that profile, you also 
> understand that you should rather GET stdin, which means that the 
> profile would somehow "semantically redirect" you to the "true" resource.
> 
> at least that is what i took away from the discussion of geolocation. in 
> a http-centric world, a geolocation is a http resource which (a) is a 
> regular web page (maybe displaying a map), and (b) to those who 
> understand the magic prefix or the embedded profile, is not just a web 
> page about the location, but the location itself.

It looks like you may have missed the key nuance of "303 See Other".
(This is not surprising.  It took me a year or two to come up with it,
and the TAG took another year or two to endorse it.  Of course, most of
that time was spent thinking "there must be something simpler!" before
deciding this was the best option.)

Here's how it might work....

There would be a URI (U1) which denotes a spot on the globe:

    http://geo.example.org/42.3619/-071.0918

When you do an HTTP GET, the server DOES NOT return a "200 OK" result.
Instead, it returns a "303 See Other", redirecting the browser to
another URL (U2), such as:

    http://geo-ui.example.org/info?lat=42.3619&lon=-071.0918

Logically, U1 identifies a spot on the globe, while U2 identifies a web
page.  In practice, if you paste U1 into a browser, the browser will
switch over the U2, displaying U2 in the address bar and displaying the
content of the page U2.  This makes sense, since the browser can't do
anything with a non-web-page URI like U1.  (On the other hand, if the
browser happens to support such things, like Firefox with the Tabulator
plugin, then it can directly show you RDF data about that location.)

Semantic Web applications could get data about the location in any of
several ways, such as GRDDL'ing U2.  As long as U1 and U2 are different
strings, it's clear enough when there is information about the location
(triples using U1) vs information about the web page (triples using U2).

Does that make sense?  Do you see why I think this is nicer for users
than using a new URI scheme?  With a new URI scheme, you only have U1,
without the automatic link to U2, and without automatic nice-behavior in
browsers.

     -- Sandro

Received on Wednesday, 16 January 2008 19:30:09 UTC