Skip to content
Solely for the Purpose of Catching $PAMRZ

Working With the Web Architecture

As you may have noticed, the web has evolved a set of common principles that are a mix of ratified standards and ad hoc practices. The notion of a Web Architecture was codified in a W3C technical report called “Architecture of the World Wide Web” http://www.w3.org/TR/2004/REC-webarch-20041215/ or simply ‘Web Architecture.’ Those projects and protocols that align with the ‘Web Architecture’ are more likely to be picked up and used than those that do not. As a result, the OAI Object Reuse and Exchange (ORE) project seeks to provide an infrastructure for web-based information systems that exploit and enhance the Web Architecture, and therefore overlay cleanly on the existing web.

Given that we want to align closely with this ‘Web Architecture’ how far does the Web Architecture report go to define what is needed to make an ORE environment happen? The answer lies in the definition of three terms and the interaction of these three concepts.

  • Resource: “A network data object or service that can be identified by a URI…. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.” 1
  • Uniform Resource Identifier (URI): “A compact string of characters for identifying an abstract or physical resource.” 2
  • Representation: “An entity included with a response that is subject to content negotiation…. There may exist multiple representations associated with a particular response status.” 1
Illustration shows the relationship between identifier, resource, and representation.

This is perhaps best explained by this graphic from the “Architecture of the World Wide Web” document. All three terms are included: a URI identifies a resource which is in turn expressed as one representation. The key part of how the web works, though, lies in the definition of “representation” — that there may exist multiple representations for a single URI. Believe it or not, you already know this. The representation of the resource identified by the URI ‘cnn.com‘ at noon today is different from the one that existed at noon yesterday. You might say, “well so what…it is a dynamic website,” and I would agree — what is important here is that the web architecture does not give you a way to identify with a URI that representation of the cnn.com resource at noon yesterday. Put another way, in the words of the Web Architecture technical report, “Agents [web browsers and the like] may use a URI to access the referenced resource; this is called dereferencing the URI.” 3 The representation comes into being as a result of a service request by an agent for a resource via a URI.

The Web Architecture technical report lists four factors that determine which representation(s) are retrieved as a result of a service request: 4

  1. Whether the URI owner makes available any representations at all;
  2. Whether the agent making the request has access privileges for those representations…;
  3. If the URI owner has provided more than one representation (in different formats such as HTML, PNG, or RDF; in different languages such as English and Spanish; or transformed dynamically according to the hardware or software capabilities of the recipient), the resulting representation may depend on negotiation between the user agent and server.
  4. The time of the request; the world changes over time, so representations of resources are also likely to change over time.

When a URI is accessed by a browser, one goes through a content negotiation to get a representation. Representations may vary by device or time or IP address or authorization or any number of factors. In a graph or type-based thinking, a resource is a first class object: it is linkable — one can cite a resource. Representations, on the other hand, are second class objects: identified only in the context of a resource. A representation is not linkable, there may be many representations per resource, and a representation only comes about as a result of an action.

Observations


This notion of the ‘Web Architecture’ is clearly dominant now, so what does the Web Architecture — resources, URIs, and representations — mean in the context of the OAI Object Reuse and Exchange work? One would be well advised to use its existing capabilities where they are appropriate and build specialized extensions that sit on top in such a way as to not contradict its fundamental aspects. This means cleanly layering new capabilities that meet the needs of our problem space. In a subsequent posting, I’ll outline the need for some ORE-specific extensions to the Web Architecture.

Footnotes

  1. “Hypertext Transfer Protocol — HTTP/1.1″ RFC 2616. Available from http://www.ietf.org/rfc/rfc2616 Accessed Feb 15 2007. [] []
  2. “Uniform Resource Identifiers (URI): Generic Syntax” RFC 2396. Available from http://www.rfc-editor.org/rfc/rfc2396.txt Accessed Feb 15 2007. []
  3. “Architecture of the World Wide Web, Volume One” paragraph #117. Available from http://www.w3.org/TR/2004/REC-webarch-20041215/#p117 Accessed Feb 15 2007. []
  4. “Architecture of the World Wide Web, Volume One” paragraph #122. http://www.w3.org/TR/2004/REC-webarch-20041215/#p117 Accessed Feb 15 2007. []
(This post was updated on 16-Feb-2007.)

4 Trackbacks

  1. [...] In a subsequent postings, I’ll go into some detail about the inner workings of “The Web Architecture” and how it is both a help and a hindrance to the interaction of compound digital objects in our domain, and how it is a force too powerful to be ignored in either case. [...]

  2. [...] Two previous posts on dltj.org have described the OAI Object Reuse and Exchange (ORE) project and the theory behind what has become known as the ‘Web Architecture’. These two areas meet up now in this post which describes the issues surrounding the raw Web Architecture as applied to a web of scholarly communication and a basic outline of what the ORE project hopes to accomplish. [...]

  3. pintiniblog | February 18, 2007 at 12:37 pm | Permalink

    links from Technorati de C. Lagoze et H. Van de Sompel sur le projet OAI-ORE. Repérée sur Disruptive Library Technology Jester dans une série de posts à propos de l’architecture web et de l’information académique: ici, ici et ici.

  4. DZone: Working With the Web Architecture | February 19, 2007 at 10:33 pm | Permalink

    Kramer auto Pingback[...] 5 votes [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *
Human Detection Scheme
(What's this?)
Comment Preview

Additional comments powered by BackType

Subscribe without commenting

From the Disruptive Library Technology Jester (http://dltj.org/), printed on Friday the 12th of March 2010 at 8:24:06 AM EST (-0500). The URL to this page is http://dltj.org/article/web-architecture/

[Creative Commons Logo] This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.