W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2011

Postcode use case

From: Nathan <nathan@webr3.org>
Date: Sun, 16 Jan 2011 21:01:58 +0000
Message-ID: <4D335CC6.3090206@webr3.org>
To: AWWSW TF <public-awwsw@w3.org>

One of a few example stories..

Consider a URI which refers to the location identified by the UK 
postcode NN15 7QX:


Upon dereferencing via HTTP, one could reasonably:
  - return RDF which included statements with this URI in the subject or 
object position, describing the resource.
  - return plain text which included human readable text describing the 
  - return HTML which included human readable text describing the 
resource (in a div with the @id "nn15-7qx"), and a javascript 
application which loaded up an interactive map centred on the location 
of the postcode, and a machine readable description of the resource in RDFa.

Regardless of what any specification may attempt to indicate, I /can/ do 
this and the URI consistently identifies the same concept, in all cases 
and contexts.

context 1:
Now, consider for a moment that somebody else creates a satellite 
navigation system, which when given that URI, dereferences it via HTTP, 
reads the location and then directs the driver to that location.

The maker of the sat nav system contacts the owner of the domain and 
asks them to expose the information they need in a specialized format 
designed for spatially aware geo systems, the domain owner agrees and 
exposes it via content negotiation.

Later, to make the system faster, the maker of the sat nav system caches 
  the information it needs locally, it's now dereferencing the same URI, 
but not via HTTP. Later still, the maker simply moves to persistent 
storage rather than caching, and uses the same URI as a persistent 
identifier referring to the location. The URI is completely decoupled 
from HTTP, it identifies a single resource, not a primary or secondary 
resource. The URI, within that context, continues to refer to the same 
conceptual mapping, even thought the domain has long since expired, 
changed hands, and the URI is no longer accessible via HTTP.

context 2:
In another part of the world, somebody has found the RDF information 
exposed over HTTP, they've also found that a sparql endpoint is exposed 
on the same domain, and rather than using HTTP, that person uses a 
sparql construct to retrieve an RDF description of the resource, the set 
of statements which have that URI in the subject or object position.

After some time, a second level protocol is introduced, which when given 
the URI of the resource will consult the same sparql store and return 
the same RDF description, it uses a request syntax like:
   DESCRIBE http://example.org/location/uk/scotland#nn15-7qx
This second level protocol has different mappings behind it, and it can 
use & map to many different transports and query languages to do it's job.

People are now dereferencing the same URI, via a completely different 
protocol, one which does not consider the component parts of the URI, 
only the opaque name.

As time progresses, statements are made to say that 
http://example.org/location/uk/scotland#nn15-7qx refers to the same 
thing as http://postcodesrus.org/NN15/7QX and the same description can 
be gained by doing a DESCRIBE on either URI.

Later, this protocol is adopted by the big browser vendors in addition 
to HTTP, a user can simply type in either URI and receive a rendered, 
human readable description of the resource formed by pretty printing the 
RDF description, gained via this new protocol.

context 3:
The original domain owner decided to sell the domain to a large 
corporate entity, that corporation removed all content from the website 
and put up a temporary holding page.

In the meantime, both contexts 1 and 2 continued to work as always, 
unaware, however some people took the URI and typed it in to a browser, 
they saw the temporary holding page and concluded the obvious, somebody 
else has bought the domain.

Later, the new owners of the domain finish getting their "new website" 
made, and launch it in a blaze of publicity with all new URIs for each 
postcode, of the form http://example.org/NN15/7QX - the owner of the 
corporation, incidentally, has a new sat nav system, and he sees the old 
URIs being used in it, and finds that they 404 on his new site. 
Realising the obvious potential business he's missing out on, he 
immediately informs the developers of the situation, they respond by 
serving HTML pages at the old URIs, which detect the fragment then 
redirect to the new URI relating to the same postcode.

Some time passes.. a branding expert tells middle management that the 
domain "example.org" is pretty poor, and they need a snappier name - the 
company opts for the domain "postcodesrus.org" - the developers map the 
example.org names through to the new domain, responding with 301 status 
codes via HTTP.

..and that's where this story ends, for now.

I don't see a problem with any of the above, neither does anybody in 
this scenario afaict - can you see a problem?

Now, this example isn't constrained technically, and nothing breaks - 
however it does break current web arch rules because:
  - it doesn't use the 303 pattern
  - it fails to make any distinction between IR and NIR
  - it fails to make any distinction between primary and secondary resources
  - it names the same concept in one case as an IR, and in another as an 
NIR, although they're both the same thing
  - the cool uris, change (they're uncool)

Probably quite a bit more..

I could list examples like this all day tbh, including some quite 
interesting ones including 3D printers where you send a message "MAKE 
<uri>" and receive a real world object via the act of dereferencing.

Ultimately though, I'm increasingly thinking that any of these 
constraints added to web arch by thinking in terms of the present day, 
particular protocols, or current convention, are actually only limiting 
web arch itself, hindering innovation, and attempt to constrain the ways 
in which web arch can be used, rather than how it is used.


Received on Sunday, 16 January 2011 21:02:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC