What Is a URI and Why Does It Matter?
URI stands for Uniform Resource Identifier, the official name for those things you see all the time on the Web that begin 'http:' or 'mailto:', for example http://www.w3.org/, which is the URI for the home page of the World Wide Web Consortium [1]. (These things were called URLs (Uniform Resource Locators) in the early days of the Web, and the change from URL to URI is either hugely significant or completely irrelevant, depending on who is talking—I have nothing to say about this issue in this article. If you have never heard of URIs (or IRIs, the even more recent fully internationalised version), but are familiar with URLs, just think 'URL' whenever you see 'URI' below.)
Historically, URIs were mostly seen as simply the way you accessed Web pages. These pages were hand-authored, relatively stable and simply shipped out on demand. More and more often that is no longer the case; in at least three different ways:
- Web pages for reading have been complemented by pictures for viewing, videos for watching and music for listening;
- The Web is now more than a conduit for information, it is a means to a variety of ends; we use it to do things: purchase goods and services, contribute to forums, play games;
- The things we access on the Web are often not hand-authored or stable, but are automatically synthesised from 'deeper' data sources on demand. Furthermore, that synthesis is increasingly influenced by aspects of the way we initiate the access.
It is against this background that I think it is worth exploring with some care what URIs were meant to be, and how they are being used in practice. In particular, I want to look at what is to be gained from a better understanding of how other kinds of identifiers work.
The Official Version
Insofar as there are definitive documents about all this, they all agree that URIs are, as the third initial says, identifiers, that is, names. They identify resources, and often (although not always) allow you to access representations of those resources. (Words in bold are used as technical terms—their ordinary language meaning is in many cases likely to be more confusing than helpful.)
'Resource' names a role in a story, not an intrinsically distinguishable subset of things, just as 'referent' does in ordinary language. Things are resources because someone created a URI to identify them, not because they have some particular properties in and of themselves.
'Representation' names a pair: a character sequence and a media type. The media type specifies how the character string should be interpreted. For example JPG or HTML or MP3 would be likely media types for representations of an image of an apple, a news report about an orchard or a recording of a Beatles song, respectively.
The relationship of these three concepts (URI, resource, representation) according to the official version is illustrated in this diagram:
Figure 1: The URI-resource-representation story, from The Architecture of the World Wide Web [2].
This cannot be the whole story, since nothing in Figure 1 above looks anything like a weather report. What Web users experience in practice involves a further relationship, between a representation and what we might call a presentation:
Figure 2: The representation-presentation story
There is significant potential for variation in two aspects of the pictures above. In the first aspect, different representations may be available for the same resource, in at least four ways:
- Different technologies, manifested as different media types, for example GIF or JPG or PNG for an image, PDF or HTML or XHTML or TXT for structured text;
- Different intended presentation platforms, for example desktop screen versus portable device;
- In the case of text, different natural languages, for example the weather report in English or Spanish;
- Different versions, either as a document evolves, or, more interestingly, because a resource is time-varying by nature, for example today's weather report.
In the second aspect, different presentations may be determined by the same representation, ranging from simple changes in size, scale or fonts to changes in modality (digital display, print, even audio or braille) or even non-physical presentation for non-human consumption, for example, by the Web crawlers used by search engines.
Figures 1 and 2 above illustrate the static relationship between the various constituents of the URI story. There is also a dynamic story, which is where the Web comes in:
Figure 3: The HTTP request-response story
The underlying mechanism for accessing representations via the Web, the HyperText Transfer Protocol, or HTTP, provides for control over the first three kinds of variation. That is, by specifying parameters in the request from client to server to access a URI, the consumer can determine which representation the server responds with. In Figure 3 above, for example, we see the initial request includes an Accept header which specifies the XHTML media type, and that is indeed what the server sends back in the response.
The fourth kind of variation, variation of representation over time, is quite different, and leads on to some new and very interesting issues. In the cases of the Oaxaca weather report or the home page of your favourite online newspaper, it does seem right to say there is only one resource, despite the fact that the representations you can retrieve of such resources will vary a great deal from day to day.
There is an illuminating parallel here with the class of words in ordinary language which linguists call indexical, words such as this, here and tomorrow, as well as you and I. An indexical such as now has a single meaning but multiple interpretations. The meaning is something like 'the time at which the utterance containing the word is made', and is the same for every use of the word. But the interpretation is, well, whatever time it happens to be when the word is used, and this of course changes all the time. More generally, the meaning of an indexical can be understood as a function from contexts (that is, contexts of utterance) to interpretations.
The situation with time-varying resources is just the same—indeed the gloss we gave to the examples above (yesterday's weather report, etc.) underlines this. Once the parallel is pointed out, it can be seen to apply to other, admittedly more specialised, URIs, such as http://localhost/... or file:///home/ht/...., which identify resources whose representations depend not (or not only) on when they are accessed, but also where.
To sum up: Although historically URIs were understood as a kind of Web-enabled file name, with a simple 'URI points to Web page' model, the move to separate conceptually the (stable) resource identified by a URI from its (potentially varied) representations was necessary to make sense of actual practice. The resource abstraction has gone on to provide powerful new functionality, a subject we will return to below.
The Actual State of Play
The phrase 'Web 2.0' means many different things, but one thing it is often used to refer to is a significant change in the way representations determine presentations. What a user sees on the screen today as a result of accessing a resource identified by a URI often depends as much, if not more, on running Javascript programs embedded in the retrieved (X)HTML representation, and on the results of other, behind-the-scenes, resource accesses, as it does on the (X)HTML itself. The coinage AJAX refers to this approach. For example, the presentation of a map which a user sees when accessing Google Maps is entirely constructed from images retrieved behind the scenes by the Javascript which makes up virtually all of the original representation as retrieved from the Google Maps URI.
As the proportion of a presentation that depends directly and declaratively on the initially retrieved representation diminishes, and the proportion based on local computation and representations retrieved behind the scenes increases, there is a kind of historical regression going on, which goes back to treating URIs instrumentally, as ways of moving data. What you can send and retrieve is all that matters, and the resource-representation distinction no longer seems to be doing useful work.
There are two things underlying this blurring of the resource-representation distinction in Web 2.0 usage:
- The kinds of flexibility provided by the kind of variation discussed above, in particular variation with respect to media type or natural language, are just not relevant to most behind-the-scenes Web access;
- The distinction between the URI as such, and the rest of the request to the server, particularly with respect to explicit parameter specifications, is much less evident from the standpoint of the Javascript programmer. Both URI and parameters are things which have to be specified as part of a Web request, and this encourages the viewpoint that taken together they identify what is wanted.
If behind-the-scenes URI usage tends to encourage a near-equation of resource and representation, other aspects of sophisticated Web 2.0 usage tend in the opposite direction. If the presentation experienced by a user varies independently of any user-controllable aspect of URI access, or evolves in response to user actions, the sense in which the URI visible at the top of the browser can be said still to 'identify' a representation which corresponds to that presentation has become attenuated almost to the point of vanishing.
If what you see depends on a cookie, you cannot post a pointer to it in an email message, because the recipient will not have the right cookie. That is not necessarily a bad thing (you probably would not want to be able to send an email message which lets someone into your bank account), but does act to diminish the connection between URI, resource and representation. If what you see depends on the IP address your request comes from or on a radio button value that does not show up as a URI parameter, then not only can you not point to it in email, but you cannot (reliably) bookmark it; nor does Google index it, because its crawlers will never see it: crawlers do not tick boxes or share your IP address.
The original value proposition of the Web was produced by the network effect: for anything you were interested in, someone else somewhere was too, and they had produced a Web site about it, and search engines could find it for you.
But the Web as information appliance has evolved: not only are large amounts of Web-delivered information not available via search engines, for the kind of reasons discussed above, even the famous pagerank algorithm which launched Google's success does not work particularly well anymore. This is because the proportion of hand-authored pages has declined, and information access is increasingly controlled by a self-reinforcing feedback loop between Google and the big players in the information aggregation game, such as Wikipedia, Tripadvisor and MedicineNet: page ranking in Google today depends to a substantial extent on statistics over search terms and clickthroughs.
From the user perspective, a related phenomenon which threatens to erode the centrality of the URI-resource connection further is the use of the search entry field in browsers instead of the address field. Already in December of 2008, for example, 8 of the top 15 search terms reported by one service over the last five months were in fact the core parts of domain names (non-www., non-.com), and some actual domain names, such as myspace.com, yahoo.com and hotmail.com, were in the top fifty.
Arguably the time when URIs were the primary currency of the Web is past, and they will disappear from view and consciousness for the vast majority of Web users in much the same way as the angle brackets and equal signs of raw HTML have done.
The Emerging Future
As long ago as the mid-1990s, information scientists had taken the URI-resource-representation split to its logical conclusion: it was OK to create URIs for resources for which no representation existed yet (for example a planned but not-yet-drafted catalogue entry), or even for resources for which no (retrievable) representation could in principle ever exist (a particular physical book, or even its author). By the end of the 1990s, the generalisation of the resource concept was complete, and we find, in the defining document for URIs (since superseded, but without significant change in this regard):
A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., 'today's weather report for Los Angeles'), and a collection of other resources. Not all resources are network 'retrievable'; e.g., human beings, corporations, and bound books in a library can also be considered resources [3].
Since then the principle that a URI can be used to identify anything; that is, that there are few if any limits on what can 'be a resource', has assumed more and more importance, particularly within one community, namely the participants in what is termed the Semantic Web programme. This move is not just a theoretical possibility: there are more and more URIs appearing 'in the wild' which do not identify images, reports, home pages or recordings, but rather people, places and even abstract relations.
But this in turn has lead to a problem. Time was, when you tried to access a URI, you either succeeded or failed. Success, as illustrated in Figure 3 above, and specifically signalled by the first line of the response message, HTTP/1.1 200 OK, meant a representation was coming next, and all was well. Failure meant the infamous '404 Not Found' (whose official rendition is HTTP/1.1 404 Not Found) and no representation. Furthermore, success meant that the presentation determined by the representation you retrieved could be counted on to pretty well reproduce the resource identified by the URI itself. You could look at the image, or read the report, or listen to the recording, etc.
But what if we have a URI which identifies, let us say, not the Oaxaca weather report, but Oaxaca itself, that city in the Sierra Madre del Sur south-east of Mexico City? What should happen if we try to access that URI? If the access succeeds, the representation we get certainly will not reproduce Oaxaca very well: we will not be able to walk around in it, or smell the radishes if it happens to be 23 December.
This is the point at which the word 'representation' is a problem. Surely we can retrieve some kind of representation of Oaxaca: a map, or a description, or a collection of aerial photographs. These are representations in the ordinary sense of the word, but not in the technical sense it is used when discussing Web architecture. Unfortunately, beyond pointing to the kind of easy examples we have used all along (a JPG is a good representation of an image, a HTML document can represent a report very well, an MP3 file can represent a recording pretty faithfully), it is hard to give a crisp definition of what 'representation' means in the technical sense, in order to justify the assertion that, for example, an image of Oaxaca does not 'represent' Oaxaca. The definition implied above, namely that a representation of a resource should determine a presentation that reproduces the resource for the perceiver, begs the question of what is meant by 'reproduce'. The Architecture of the World Wide Web [2], which is a systematic attempt to analyse the key properties on which the success of the Web depends, coined the term information resource for those resources for which a representation is possible. It defines the term in this way: 'The distinguishing characteristic of [information] resources is that all of their essential characteristics can be conveyed in a message.'
This may seem like an academic question, one which indeed has important connections to both philosophy, particularly the philosophy of aesthetics, and to information science and the notorious question concerning 'the nature of the work of art'. But it has real practical consequences. There is real debate underway at the moment as to exactly what it means for a Web server to return a 200 OK response code, and about exactly what kind of response is appropriate to a request for a URI which identifies a non-information resource. This question arises because, particularly in the context of Semantic Web applications, although no representation of the resource itself may be available, a representation of an information resource which describes that resource may be available. So, to go back to our example, there may be a representation available for a report on a visit to Oaxaca, or for a collection of images of Oaxaca, or even a set of formally encoded propositions about Oaxaca. Such descriptions are often called metadata.
Figure 4: The URI-resource-metadata story
Conclusions
URIs are at the heart of the Web: we use them both intentionally and without realising it every time we take advantage of the myriad possibilities the Web offers us. Their use is evolving in a number of directions, not all obviously compatible with one another, or with their original conception and the basic technical framework which supported them when the Web was young. Understanding all this is a necessary and worthwhile challenge, both from the perspective of scientific enquiry (just what are these things?) and from the perspective of stewardship (how do we ensure that the Web will continue to work well for everyone?). Insights into these questions may come from surprisingly distant quarters, as well as from observation of everyday use and practice.
The intention of this brief introduction has been to introduce the terminology and issues surrounding URIs and their role on the Web, and as such cannot have done justice to the complexities involved in many areas. The next section points the way for those who want to dig in and explore the details.
Further Reading
The Technical Architecture Group (TAG)[4] of the World Wide Web Consortium (W3C)[1] was established to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary, to resolve issues involving general Web architecture brought to the TAG, and to help co-ordinate cross-technology architecture developments inside and outside W3C (from the TAG charter [5]). The TAG's largest piece of work to date is The Architecture of the World Wide Web by editors Jacobs and Walsh [2], sometimes referred to as 'WebArch' or just AWWW. It contains definitions, principles, constraints and best practice, set out in a relatively informal way, with motivating examples. Further TAG work has been published as separate 'findings', which are listed, along with other information about the TAG's work, on the TAG home page [4].
The Internet Engineering Task Force (IETF) [6] is responsible for the formal specifications at the heart of the Web. Recent IETF publications of particular relevance to the issues discussed here are:
- Berners-Lee, Fielding and Masinter 2005 RFC 3986, Uniform Resource Identifier (URI): Generic Syntax [3]
- Duerst and Suignard 2005 RFC 3987, Internationalized Resource Identifiers (IRIs) [7]
- Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1, 1999 [8]
References
- World Wide Web Consortium (W3C) http://www.w3.org/
- Ian Jacobs and Norman Walsh, (Eds). "Architecture of the World Wide Web", Volume One, W3C Recommendation 15 December 2004
http://www.w3.org/TR/webarch/ - T. Berners-Lee, R. Fielding, U.C. Irvine & L. Masinter. Uniform Resource "Identifiers (URI): Generic Syntax", 1998 RFC 2396
http://tools.ietf.org/html/rfc2396 - The Technical Architecture Group (TAG) http://www.w3.org/2001/tag/
- Ian Jacobs, (Ed). "Technical Architecture Group (TAG) Charter", 27 October 2004
http://www.w3.org/2004/10/27-tag-charter.html - The Internet Engineering Task Force (IETF) http://www.ietf.org/
- M. Duerst & M. Suignard, "Internationalized Resource Identifiers (IRIs)", January 2005
http://tools.ietf.org/html/rfc3987 - R. Fielding, UC Irvine, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach & T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999
http://tools.ietf.org/html/rfc2616