Resource and Representation Relationship Vocabulary Jon Hanna Talliesin 2003-01-17 17th January, 2003 2003-01-20 20th January, 2003 Cool URIs don't change Tim Berners-Lee RFC 2616: Hypertext Transfer Protocol — HTTP/1.1 Tim Berners-Lee R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach Architecture of the World Wide Web Ian Jacobs RDF Vocabulary Description Language 1.0: RDF Schema Dan Brickley R. V. Guha

A common cause of confusion and complaint about the web has been the exact nature of the relationship between a resource and the representation or representations of that resource that one can retrieve by dereferencing it's URI.

A result of this is that many RDF documents contain information about both a resource and it's representation with the same URI used to identify both, resulting in fragments like:

<foaf:Person
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <dc:format>application/xhtml+xml</dc:format>
</foaf:Person>

In the above fragment the <dc:format> predicate obviously refers to the representation (presumably a HTML page with information about the person in question), but from a naïve interpretation of the RDF it appears that it is saying that the actual person has a format of "application/xhtml+xml"!

Hence there is a need for a mechanism that allows us to both describe a resource, its representations, and the relationship between them.

Representations can themselves be considered resources, and hence we can describe them seperately in RDF, if given the predicates and classes we need to do that well.

This schema defines classes and predicates for doing exactly that. In particular the Representation class is used for a representation, the Representations class for a collection of possible representations, and the representedBy predicate is used to link a resource with its representations.

This schema also defines composedInto and its inverse composedFrom to indicate resources that are created from other resources (an example being a document that is created by combining a document contain its main content with one containing navigational information) and also canTransformTo to indicate a representation that can be converted into a different resource by the client (for example by use of XSL Transforms. While these do not fall cleanly into the brief for this schema they are included because of the following justifications:

  1. It is common for these relationships to exist between the resources which would also have representedBy relationships. As such dealing these relationships here, rather than splitting them over several schemata would prove convenient.
  2. The relationships of this nature may seem close enough to the representedBy relationship in some cases that users might be tempted into abusing representedBy to describe those relationships.

URIs of Representations

As a general rule representations should not be given the same URI as the resource it represents, to do so would violate the whole concept of a resource as something other than its representation, and hence make this schema pointless.

An important exception is when the entire point of the resource is the bytestream. As an example, if <http://www.example.com/patches/prog3.4.exe> could be derefernced to retreive a patch that would enable us to update "prog" to version 3.4 then the entire purpose of that resource is the very bytestream that would be its most likely representation. As such it may be useful to use the same URI for both the resource and the representation, in other words the representation is the resource.

It's worth noting that even in this case the bytestream of the patch isn't the only possible representation.

In most cases either no URI is needed (a blank node), or else the URI exists for the purpose of describing the representation, rather than as a target of dereferencing.

In some cases it does make sense to allow the URI to be dereferenced. Consider if the URI <http://www.example.org/> would return either a HTML document or an RDF/XML document, depending on the Accept HTTP header. In such a case the HTML document might link to <http://www.example.org/rdf> which would return the afore-mentioned RDF/XML document whatever the headers. In this case the representation is again the resource, and hence it is perfectly valid to use the latter URI as the URI of the RDF/XML representation of the resource identified by the former URI.

Jon Isn't Cool!

For obvious reasons the URIs used for the predicates and classes defined in this schema should be cool. They are not cool for two reasonsthis reason:

  1. This document is currently hosted at a location that is leant to me as a favour by my employers. It would be an abuse of that favour to somehow start asserting that they cannot discontinue its existence.
  2. This schema is a rather hastily drafted first-stab. It is intended for consideration and experimentation, rather than use as is. The use of an example.net URI is a deliberate disincentive against using it in its current form. While the RDF of this schema does use the schema of itself, this is as an example only.
Representations

A resource of class Representations is a collection (a subclass of rdf:Alt) whose members are resources of class Representation.

This collection is always used, as even in the case where there is only one representation other representations are at least theoretically possible.

Representation

A resource of class Representation is a downloadable bytestream which is used as a representation of another resource.

Generally it should not have the same URI as the resource of which it is a representation. The only exception being cases like software or software patches were the actual bytes is the primary purpose of the resource.

Most representations wouldn't be given URIs, or if they were these would not be URIs from which the resource could be dereferenced. However such URIs would have a place sometimes (for example, a URI which returned either HTML or RDF depending on content-negotiation, but where another URI could be used to retreive the RDF without negotiation).

Criterion

A criterion used in the decision-making that determines which representation of a resource is retreived.

Only Representation

A criterion that indicates that only one representation is available for a given resource, and will always be the one retreived.

Subclasses are defined which cover common cases.

Multiple Criteria

A criterion that indicates that several criteria are used to determine the representation used.

As such it is considered to be a single criterion composed of the criteria which are it's members. As it is a Seq rather than a Bag, ordering can indicate which criteria have priority, but this can only be relied on so far. In otherwords the first member may over-ride the second member, but it might not.

Content Negotiation

A criterion that operates on the basis of HTTP headers or other content negotiation mechanisms. Subclasses have been defined for common cases.

Note: This does not cover the use of headers to produce responses such as 304 Not Modified. That is an implementation issue, and conceptually the same representation is retreived as if the response had been a 200 OK with the representation bytestream.

Language Negotiation

A criterion that operates on the basis of the Accept-Language HTTP header.

MIME-Type Negotiation

A criterion that operates on the basis of the Accept HTTP header.

Client Location

A criterion that operates on heuristics for determining the client's location.

Note: There are several different mechanisms for attempting this, with different degrees of accuracy. As such this indicates an intention rather than a guarantee of success.

RequestTime

A criterion that is in some way related to the time the request is made.

Random Factor

A criterion that is based on some random, pseudo-random, or otherwise indeterminable factor.

Represented By

The subject is represented by the object. Note that the representation is always a Representations collection, rather than a single Representation, as an alternative representation is always at least theoretically possible.

Selection Decided By

The member of the subject retreived is decided on by considering the object.

Composed Into

The subject is used to create the object.

Composed From

The object is used to create the subject.

Can Transform To

The object can be created from the subject by a well-defined process (such as an XSL Transform). The object may or may not be also retreivable already composed on the web (hence there may exist both a canTransformTo and a composedInto relationship between the two resources).

No Representation

A "null" representation, indicating the possibility of no representation being returned. In combination with an OnlyRepresentation criterion this indicates that there is never a resource available. Otherwise it means that there may not be a representation under certain circumstances.

These "certain circumstances" mean an active decision not to supply the representation, rather than an error or security problem.