« What would Google do? | Main | Open orienteering »

February 05, 2009

httpRange-14, Cool URIs & FRBR

The W3C Technical Architecture Group's resolution to what had become known as "the httpRange-14 question" introduced a distinction between the subset of resources for which representations may be served using the HTTP protocol - a subset which the Architecture of the World Wide Web refers to as "information" resources - and - by implication at least - a disjoint subset of resources which may be identified using the http URI scheme but which is not "representable" -  for which no representations are provided using the HTTP protocol - though they may be described, by "information resources" identified by their own distinct URIs.

A subsequent note by Leo Sauermann and Richard Cyganiak of the W3C Semantic Web Education and Outreach (SWEO) Interest Group, Cool URIs for the Semantic Web provides an extended discussion of the issue, together with a set of "patterns" for assigning http URIs and for the appropriate responses to HTTP requests using such URIs. This document uses the terms "Web documents" and "real-world objects" to refer to the two classes of resources, noting that the latter class includes "real-world objects like people and cars, and even abstract ideas and non-existing things like a mythical unicorn".

The question raised by this division is where the boundary between the two classes lies. From the viewpoint of the consumer/user of URIs, the point is somewhat moot: they simply need to follow the information provided, in the form of responses to HTTP requests by the owner of the URI (or possibly also from metadata provided by other parties). Information about the nature of the resource can be provided both by HTTP response codes and by explicit descriptions of the resource. Following the httpRange-14 guideline, if the HTTP response to a GET is 2xx, then the resource identified by the URI is an information resource. I think it's worth emphasising the point that this is the only response code which allows the user to make a "positive" inference about resource type; if the response is 303 See Other, that in itself says nothing about the type of the resource.

The URI owner, on the other hand, needs to make the choice, for each resource, whether to provide a representation or not, based on their understanding of the nature of the resources they are exposing on the Web. The Architecture of the World Wide Web document offers the following (somewhat "slippery", to me!) criterion for a resource being an "information resource": The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message.

I've been trying to think through how this set of conventions should be applied to the case of the Functional Requirements for Bibliographic Records (FRBR) and more specifically to the "FRBR Group 1 Entities", i.e. instances of the the classes of Work, Expression, Manifestation and Item which FRBR uses to model the universe of resources described by bibliographic records.

The work on the development of the Scholarly Works Application Profile (SWAP) focused primarily on deployment in the context of the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). OAI-PMH provides an RPC-like layer on top of HTTP, and SWAP focuses on how to deliver descriptions of the SWAP/FRBR entities using that RPC layer, rather than the question of how those entities could be represented as Web resources.

I'm starting from the FRBR model here; I'm asking the question, "If I'm exposing on the Web a set of resources based on the FRBR model, are there any general rules for which of these resources are 'representable'?". I'm not trying to address the broader question of whether/how the distinctions made in the Web Architecture reflect, or can be defined in terms of, the FRBR model.

Taking the "easy" cases first, FRBR defines a Work as follows:

The first entity defined in the model is work: a distinct intellectual or artistic creation.

A work is an abstract entity; there is no single material object one can point to as the work. We recognize the work through individual realizations or expressions of the work, but the work itself exists only in the commonality of content between and among the various expressions of the work.

- FRBR Section 3.2.1

It seems fairly clear from this description that a FRBR Work is a "conceptual resource", like an idea. In the terms of the "Cool URIs" document, it is a "real-world object", albeit an abstract one, and not a "Web document". And on this basis, while a FRBR Work may be identified by an http URI, an HTTP server should not return a representation and a 200 status code in response to a GET for that URI, though the server may provide access (using one of the patterns provided in the Cool URIs document) to a description of the Work, a "Web document" itself identified by a distinct URI.

A similar argument can, I think, be made for the case of the FRBR Expression:

An expression is the specific intellectual or artistic form that a work takes each time it is "realized." Expression encompasses, for example, the specific words, sentences, paragraphs, etc. that result from the realization of a work in the form of a text, or the particular sounds, phrasing, etc. resulting from the realization of a musical work. The boundaries of the entity expression are defined, however, so as to exclude aspects of physical form, such as typeface and page layout, that are not integral to the intellectual or artistic realization of the work as such.

- FRBR Section 3.2.2

Again we're dealing with an "abstraction", albeit a more "specific", less "generic" one than a Work. And on this basis, like the Work, it falls into the category of "real-world objects", and again, while an Expression may be identified by an http URI and an HTTP server may provide access to a description of an Expression, it should not provide a representation of an Expression.

In considering the other two FRBR Group 1 entity types, Manifestation and Item, it is perhaps easiest to consider the application of FRBR to physical resources and to digital resources separately.

Considering the physical world first, it is perhaps helpful to consider the Item first, as it seems to me it also sheds some light on the nature of the Manifestation. The FRBR definition of Item is very much grounded in the physical:

The entity defined as item is a concrete entity. It is in many instances a single physical object (e.g., a copy of a one-volume monograph, a single audio cassette, etc.). There are instances, however, where the entity defined as item comprises more than one physical object (e.g., a monograph issued as two separately bound volumes, a recording issued on three separate compact discs, etc.).

- FRBR Section 3.2.4

These Items are the "real world objects" which traditionally libraries have been concerned with managing (acquiring, storing, maintaining, providing access to, distributing, disposing of). From the perspective of httpRange-14 and the "Cool URIs" document, then, these "real-world objects" may be described by Web documents, but they are not themselves Web documents. So a physical Item may be identified by an http URI, and an HTTP server may provide access to a description of such an Item, but it can't provide a representation of it.

Now take the case of the Manifestation:

The third entity defined in the model is manifestation: the physical embodiment of an expression of a work.

The entity defined as manifestation encompasses a wide range of materials, including manuscripts, books, periodicals, maps, posters, sound recordings, films, video recordings, CD-ROMs, multimedia kits, etc. As an entity, manifestation represents all the physical objects that bear the same characteristics, in respect to both intellectual content and physical form.

- FRBR Section 3.2.3

Again a Manifestation is dealing with physical form, but furthermore, a Manifestation is still an abstraction: its role in the FRBR model is to capture characteristics that are true of a set of individual Items which "exemplify" that Manifestation (even in the case where a unique Item which is the sole exemplar of a Manifestation). Seen in this light, then, I think a Manifestation also falls into the category of things which may be described by one or more Web documents, but is not itself a Web document.

In turning to the context of the digital world, I think it's worth highlighting that although the FRBR specification contains some references to "electronic resources", the coverage of digital resources in the text very limited, and indeed the introduction acknowledges that "the dynamic nature of entities recorded in digital formats" is one of the areas that require further analysis.

It seems relatively straightforward to transfer the concepts of Work and Expression into the digital sphere, as they are independent of the form in which content is "embodied".

The question of what constitutes a FRBR Item in the digital domain is rather more difficult to pin down, particularly since the FRBR document itself focuses exclusively on the physical in its discussion of the Item. Ingbert Floyd and Allen Renear take on this challenge in their poster, "What Exactly is an Item in the Digital World?" (ASIST, 2007)

In the physical world, they argue, the thing which carries information is the same thing for which information managers typically describe characteristics such as provenance, condition, and access restrictions - the attributes of the Item in FRBR. In the digital world, this is no longer true: information is carried by the physical state of some component of a computer system, something the authors call an instance of "patterned matter and energy" (PME) - but information managers rarely concern themselves with managing such entities and recording their attributes. Entities such as a "file", however, are the focus of management and description - but a digital "file" isn't really the "concrete entity" that FRBR calls an Item. Two approaches to the Item are possible, then: the Item-as-PME approach, which "maintains that a fundamental aspect of being an item is being a concrete physical thing", or the Item-as-"file" approach which addopts the pragmatic position that "items are the things, whatever their nature (physical, abstract, or metaphorical), which play the role in bibliographic control that FRBR assigns to items".

The question I'm posing here is, I think, a different, and narrower, one from the broader one grappled with by Ingbert and Renear: if we are treating a FRBR Item as a Web resource, for the case of an exemplar of a Manifestation in digital format, is that resource an "information resource", for which a representation can be served? From the Web Architecture perspective, it seems to me that it is the case that "all of their essential characteristics can be conveyed in a message". The Scholarly Works Application Profile takes this approach: the copy of a PDF document available from an institutional repository server, or the copy of an mp3 file constituting an episode of a podcast, is the FRBR Item. These, after all, are the things which, "play the role in bibliographic control that FRBR assigns to items".

A further issue here is that FRBR lists "Access Address (URL)" as an attribute of a Manifestation, rather than of an Item, and I'm not sure whether this is compatible with the SWAP approach.

The concept of Manifestation in the digital case seems the most difficult to categorise. On the one hand, as noted above, FRBR states that a Manifestation is an abstraction corresponding to a set of objects with the same characteristics of both form and content. On the other hand, it seems to me that one could argue that for Manifestations in digital form, it is true that "all of their essential characteristics can be conveyed in a message", since the notion of Manifestation encapsulates that of specific intellectual content "embodied" in a specific form. For consistency with the physical case, I guess the former would be best, but I'm not sure on this point.

So those rather lengthy musings might suggest the following (tentative, I hasten to add... I'm mostly just trying to think through my rationale here) approach to identifying and serving representations/descriptions of the FRBR entities, at least using the approach that SWAP takes to the Item:

Entity Type HTTP Behaviour

Identify using http URI

Provide description of Work. Either use a "hash URI", or respond to GET with 303 See Other and http URI of description (generic or using content negotiation.


Identify using http URI

Provide description of Expression. Either use a "hash URI", or respond to GET with 303 See Other and http URI of description (generic or using content negotiation.

Manifestation Physical

Identify using http URI

Provide description of Manifestation. Either use a "hash URI", or respond to GET with 303 See Other and http URI of description (generic or using content negotiation.


Identify using http URI

Provide description of Manifestation. Either use a "hash URI", or respond to GET with 303 See Other and http URI of description (generic or using content negotiation.

Item Physical

Identify using http URI

Provide description of Item. Either use a "hash URI", or respond to GET with 303 See Other and http URI of description (generic or using content negotiation.


Identify using http URI

Provide representation of Item. (Respond to GET with 200 and representation).

One final point.... The use of HTTP content negotiation on the Web introduces a dimension which I'm not sure sits very easily within the FRBR model. Using content negotiation, I may decide to expose a single resource on the Web, using a single URI, but configure my server so that, at any point in time, depending on a range of factors (the preferences of the client, the IP address of the client, etc.) it returns different representations of that resource - representations which may vary by (amongst other things) media type (format) or language. From the FRBR perspective, such variations would, I think, result in the creation of different Manifestations (for the media type case) or even different Expressions (for the language case). In the SWAP case, I think the implication is that Item representations should not vary, at least by media type or language.


TrackBack URL for this entry:

Listed below are links to weblogs that reference httpRange-14, Cool URIs & FRBR:


Nice analysis,

I disagre about Expressions. Given content-negotiation, a plain text version and an HTML version of the same text could be served from the same URI. The "common" resource would be the Expression, and each Content-Location a Manifestation, in my view.

I.e. Web Architecture allows for a URI to contain some inherent abstraction, as long as the "information content" is the same.

I believe the expression "the specific words, sentences, paragraphs, etc. that result from the realization of a work in the form of a text" is specific enough to be "representable".

This is really interesting, Pete.

The question seems hinge on what you serve as the representation. I agree with your table, which tells me that excepting item, I'm *always* serving a description.

I'd say that content negotiation should not be used to offer different representations of digital items if FRBR's at the heart of this. Those different representations would get their own URIs before the point of content negotiation. However, in 7 of the 8 rows on your table, you're serving a surrogate/description, which can have as many representations as you want without breaking FRBR. Or, at least until you catalog your catalog... :)

To follow up on Mikael's point, I'd agree with you that the expression's an abstraction. It might be useful, though, to make it easy to cascade a user down to a digital "Item" from anywhere below the "Work" level, if one is available . Is it possible that in these cases content negotiation or HTTP status codes could trump explicit FRBR relationships between group-one entities?

@Mikael: Good point. As I added the note about conneg, it did cross my mind that maybe this fitted with "representability" (urgh!) at the Expression level, as you suggest.

I think I'm probably being over-influenced by my (fairly limited experience of) "repository" systems (mostly "eprint" repositories), where I don't see much use of conneg, at least in this way.

Bur, yes, I can see the argument for it.

I'm trying to get my head around this. The truth is that trying to equate the digital and physical worlds is always going to be a problem, and FRBR is rooted firmly in the physical world.

I would guess that either you say that digitally the manifestation/item entities merge in some way, or you decide to stick with the model and say that the digital object is the item equivalent to the physical one.

The more I think about it, the more I start to believe that there is at the least a one-to-one relationship between manifestation and item digitally. It maybe that if you approached this purely from a digital perspective you would not draw a distinction, and so if you want to use FRBR as is, you just have to fudge one way or the other.

Finally, I don't agree with Mikael about the Expression. As soon as you have anything you can consume I'm pretty convinced it has to be regarded as the item (or item/manifestation). At the very least it doesn't make sense to say that the digital item is the 'thing', and also allow the digital expression to be the 'thing' - once you have the thing, I can't see how you can have any finer grain of entity.

@ostephens: Thanks :-)

For now just responding to one particular point. You said:

"At the very least it doesn't make sense to say that the digital item is the 'thing', and also allow the digital expression to be the 'thing'"

Ah, but Mikael isn't saying that, and serving a representation of an Expression wouldn't be saying that.

I think the issue here is around what the Web Architecture means by "representation".

Suppose I issue an HTTP GET for URI-X, and an HTTP server responds with a message including a response code of 200, some header data, and, say, an HTML document as representation of the resource identified by URI-X.

And then I issue an HTTP GET for URI-Y, and an HTTP server responds with a message including a response code of 200, some header data, and, as representation of the resource identified by URI-Y, a bit stream which is identical to the representation in the previous example i.e an identical HTML document.

i.e. (at this point in time), the server (or indeed two different servers, for that matter) provides identical representations for the resource identified by URI-X and for the resource identified by URI-Y.

It does not follow from that that URI-X and URI-Y identify the same resource. They might do, or they might not. Identity of the representations doesn't in itself tell us enough to decide one way or the other.

So in the example here, if we accepted Mikael's position that the Expression is "representable", a server could return the same HTML document as a representation both of the Expression, E-1 (based on the server's decisions about media-type variation), and of an Item I-1 which exemplifies a Manifestation M-1 (in HTML format) which embodies that Expression E-1, without there being any conflation of the two resources.

The Expression E-1 and the Item I-1 remain distinct resources.

So this behaviour is not saying that the Item I-1 and the Expression E-1 are both the same thing, only that the server-side algorithms which determine what representations are to be provided resulted - at that point in time, in response to those particular requests - in the provision of identical bitstreams as representations of the two resources.

If, as Mikael suggests, HTTP content negotiation was supported for the URI of the Expression, E-1, then a different client request, expressing different content/media-type preferences, might obtain a different representation (e.g. a plain text document), which in turn was identical to the representation provided for a different Item I-2, exemplifying a different (plain text) Manifestation M-2 which embodies that same Expression E-1.

I'm pretty sure that I don't understand this!

Perhaps the following will help:

I see the Expression as an abstract concept which represents (not in a Web Architecture sense!) all possible realisations of a work in a particular way - whether they currently exist or not.

In this sense my naive position was that you couldn't represent (in a Web Architecture sense) the Expression. I can see that you might have a URI that can deliver varying manifestations/items to different requests - fair enough, but it still doesn't represent an Expression, because it can only deliver what it knows, not all possible manifestations/items, some of which may not yet exist.

Make of that what you like - either you feel this is still 'representable', or you disagree with the way I think about an Expression, or I've just come up with a cunning argument that you could put a tail on :)


I just happened to find this discussion today, and it struck a chord about exactly what I've been doing in the past two years.

As author and main maintainer of the UN-sponsored Akoma Ntoso data format for the XML expression of parliamentary documents in Africa (http://www.akomantoso.org), as well as of the CEN Metalex interchange standard for legislative documents in Europe (http://www.metalex.eu/) I found our group quite often struggling with the concepts of physical vs. conceptual representations of documents, and found good enlightenment in FRBR concepts.

I'll confess, after reading your notes, that I am not so sure that our interpretation of the FRBR proposal is the correct one, but it seems to work for us. If you care to keep on reading a bit, I'll try to express it, and I would appreciate your opinions on it.

First of all, the only "existing" level of the FRBR suit is the Item. Just like in reality the physical book object I hold in my hand is the only realization of Shakespeare's Hamlet I will ever experience, similarly, the file on a specific computer in a specific path is the only realization of an electronic document I will ever experience.

The Manifestation (a specific edition of the Hamlet), the Expression (a specific version of the Hamlet) or the Work (Shakespeare's Hamlet) are never really experienced, because they do not exist in reality except through their exemplification, the exemplification of their embodiment, or the exemplification of the embodiment of their realization, respectively, i.e., by holding the physical book in my hand. Similarly, what we are really exchanging in HTTP interactions are * always * Items, physical exemplifications of a Manifestation of a document, which is a embodiment of an Expression which is a realization of a Work, as usual. And within Items I can probably find the traces of the upper levels, but I can not directly experience the upper levels myself.

As such, we have been struggling to find the characteristic features of each FRBR level that help us associate the right properties to the right level. The documents we are dealing within Akoma Ntoso and CEN Metalex are acts and other Parliamentary documents, and we find interesting and useful examples there. This is where we are so far:

The characteristic feature of Works is the IDENTITY. Any time in which we take two apparently completely different Items and affirm they are the same document (e.g., a printed book of the English version of the First Folio version of the Hamlet, and a MS Word file on my computer of the Italian translation of the Second Quart) we are being witnessing the IDENTITY enjoyed by a Work. In a parliamentary system, the Work is the Act that enjoys a specific number, year and promulgation date. Even after amendments and abrogations, the Act will remain the same in number, year and promulgation date. For instance, most times, when an Act refers to another Act, it refers to it in an absolute, time-independent way that survives any content change in the destination Act. Thus we say we have a time-independent work-level reference that the jurist needs to traverse in a time-dependent manner (today it may lead him to an Expression, tomorrow to another one).

The characteristic feature of the Expressions is the CONTENT. Any time we identify and freeze into a unit a specific selection of words (or video frames, or sound bites, etc.), we are in front of an Expression. The author of the Expression is not necessarily the author of the Work: for instance, the author of First Quarto, Second Quarto and First Folio is possibly William Shakespeare (in the sense that - had he existed in reality - he actually overviewed the final selection of words) but the author of the 1996 movie Hamlet is whatever equipe of individuals we deem responsible for the generation of the final shots of the movie and their selection and taping in its final form. Similarly, in the parliamentary domain the Expressions of a Work include language-specific variants as well as time-dependent versions of the act. Some acts are authored by the Legislator (a mythical figure), e.g., all original acts as well as a few formally approved amended acts, while some others are authored by a specific editor that reads the officially approved amendments, and manually cuts, adds and changes the original content to obtain the amended text.

The characteristic feature of the Manifestation is the FORMAT. An MS Word file containing some content, a PDF containing the same content, and XML representation of the same content using XHTML and another using the Akoma Ntoso data format are all different Manifestations of the same Expression. Indeed, the specific choice of markup and the corresponding siding of the content with metadata is, in Akoma Ntoso, the act of creating a specific Manifestation of the act, and the editor providing this markup is the author of the Manifestation. Note that not the metadata, but the specification of the metadata in the XML document is part of the Manifestation in this vision.

Finally, the characteristic feature of the Item is the LOCATION. Every time I exemplify the Manifestation, i.e. I generate a new copy of the same Manifestation, I necessarily obtain a different Location. My copy on my computer of the document is a different Item from your copy on your computer. Items are byte-by-byte identical but differ in the location they are stored. In Akoma Ntoso we do a slight departure from such strict equivalence, in that we allow item-level metadata to differ while at the same time maintaining the sameness of the Manifestation. Item-level metadata include digital signatures, and location oriented and service-level information such as URL, server info, download date, price, etc.

Thus an HTTP request of a document is the spawning of a new Item as a copy of the one stored at the server, and in no case and no situation you will ever interact with the corresponding Manifestation, Expression or Work, since they do not physically exist in any form.

This brings the discussion to URIs: in Akoma Ntoso, URIs are systematically used at all levels of the FRBR suite to identify different aspects of the document. A Work-level reference (e.g., a reference to an Act in the version that is actually in force in the moment the link is traversed) will use a Work-Level URI, while an Expression-level reference (e.g., a reference to an Act by an Amending Act, and therefore referring to a very specific version of the Act itself) will use an Expression-level URI, and a Manifestation-level reference (e.g., a reference within the Akoma Ntoso markup of a multimedia object to be shown in the final presentation of the document) uses a Manifestation-level URI.

But in all cases, since the HTTP level only deals with physical files, a resolution engine exists to deliver the Item URI best matching the Manifestation, Expression or Work being sought, according to a number of (context dependent in most cases) resolution rules. The Item URIs are always URLs, while no upper-level URI is a locator, as Works, Expressions and Manifestations are never located anywhere.

Akoma Ntoso defines thus a Naming Convention, that describes and qualifies the URIs for Works, Expressions and Manifestations of parliamentary documents, and steers clear of defining a physical architecture of URLs for the Items, since it tries to remain independent of architectural choices, and a configurable resolution engine for the Akoma Ntoso documents exists at http://akn.web.cs.unibo.it

I would very much appreciate your opinions on this.



The comments to this entry are closed.



eFoundations is powered by TypePad