Requirements for Any Theory of "Information Resource"

Jonathan Rees
25 February 2011
This version:
Latest version:


Dereferenceable URIs (loosely speaking, those you can 'GET') are used both imperatively, as protocol elements, and declaratively, in metadata and references. A technical term "information resource" (replacing "resource") was introduced by Architecture of the World Wide Web for the entities that metadata and references are "about". This report describes the author's understanding of what must be true in any adequate theory of "information resources" in order for them to play this explanatory role. By focusing on requirements, expressed as logical axioms, we postpone or avoid the question "what is an information resource," which inevitably leads to philosophical wheel-spinning and vexing paradoxes.

The challenges to explaining "information resource" are: (1) to make "information resources" logically independent of Web dereference (and in particular the HTTP protocol), while saying rigorously what it means for one of them to be "on the web" at a given URI; and (2) understanding the role of "information resources" as subjects of metadata and reference, given the potentially arbitrary variability in dereference behavior (HTTP 200 responses to GETs) for that URI.

The main contribution of this note is to say that the properties of an information resource are those that are invariant over its "representations". If one knows the properties of an information resource, one can make falsifiable predictions about its retrieved "representations", and knowing about the "representations", one can conclude properties of the information resource.

It is a purpose of this document to help explain "information resource" and the misunderstood httpRange-14 rule, not to defend either. It is hoped that this treatment will be useful in future discussion of whether any technical specifications require modification, and if so now.

Status of this document

This document presents the author's views, which have been developed with help from the informal AWWSW task force of the W3C Technical Architecture Group. It is presented as a first step toward consensus first within the task group, and then in larger forums. Comments for the purpose of repairing deficiencies and building consensus are welcome.

This document is likely to be revised. When citing please look for the latest revision.


This report seeks to shed light on the nature of "information resources" and their role in Web Architecture. The term is used in Architecture of the World Wide Web and in the httpRange-14 resolution and in various writings of Tim Berners-Lee [TBD: cite Generic Resources and various pieces of email], but never operationally enough for the general reader to be able to reason about them reliably or to be clear about their function.

The word "information resource" has been used in a variety of ways. Here we take the view that an "information resource" is whatever it has to be in order to be something that can be (a) the subject of metadata and (b) "on the web". "Metadata" is defined conventionally, not rigorously. The sense is "data about data" or more generally "information about information". Examples of metadata would be statements or records written using FOAF, Dublin Core, or Web Linking vocabularies.

In order to avoid having to answer the apparently futile ontological question "what is an information resource," we focus on requirements on what any such answer would have to be like. The requirements take the form of logical axioms. There may be many ways to fulfill the axioms. Each way would involve an interpretation or translation of the terms of the axioms into some particular informal or formal system, checking to make sure that the axioms, as translated, are true under that interpretation.

Just to help you along: Your interpretation of these axioms might be mathematical (as lattices, functions, etc.), or in terms of your favorite ontological framework (Sowa KR, BFO), or in terms of your favorite information ontology or vocabulary (IAO, FRBR, genont).

As is appropriate for requirements, the axioms leave many details unspecified, leaving calculated misinterpretation and interoperability risks. Readers are challenged to find creative ways to misinterpret the axioms, so that any needed but missing axioms can be added.

My plan is to transcribe all the axioms into OWL-DL (work in progress here), so that I can check for consistency and adequacy, but first I want to lay them out and see whether they make sense to reviewers.

Each axiom is accompanied by commentary. The commentary is meant to provide motivation and intent, but should be considered informative, not normative.

Web-independent axioms

Our first challenge is to abstract "information resources" (roughly speaking, things that can be put "on the web") away from the Web. To do this we need a set of axioms that have no mention of URIs or protocols.

There is a class of 'information resources'.

This is a troublesome one, so to be careful, please interpret the term as constrained by the following axioms, not according to your impulse.

We need this term in order to explain the intent behind AWWW and the httpRange-14 resolution, although I don't promise that an interpretation compatible with these writings exists.

To say 'class' is not to say 'natural category' or 'ontologically coherent class'. The most natural model of the axioms might well make this class the Scylla that Alan Ruttenberg has been menacing us with. [citation needed]

For now just bear in mind: An information resource is whatever it has to be in order to explain how Web metadata expresed in RDF seems to work.

There is a class 'simple information resource' (or 'simple IR') that is a subclass of 'information resource'.

This might be what you get when GET, were the simple IR to be on the Web.

I'm introducing this term distinct 'representation' so that I can explain metadata, which is most easily seen as applied to IRs and not representations; see below.

It is supposed to be consistent to assume that this class coincides with TimBL's class 'fixed resource'. Historically, you could take 'simple IR' to be the class of hypertext nodes of of the early Web, before conneg and dynamic content came along and anyone worried about the resource/representation distinction.

If you are FRBR-inclined you might be able to be interpret 'simple IR' as a subclass of FRBR 'Manifestation'.

'Has content' is a total function mapping a 'simple IR' to a string, perhaps the empty string. 'Has media type' is a partial function mapping a 'simple IR' to a string.

The intent is that 'simple IRs' are "mostly" syntactic; any other properties they have are. This should become clearer further on.

This axiom does not rule out IRs having other syntactic parts as well, such as charset, content-language, or expiration date, but that would depend on how exactly you interpret these axioms.

Even given an enumeration of syntactic parts, a simple IR's identity is not determined - two simple IRs might have all the same parts yet have distinct origins (provenance). Compare FRBR 'Manifestation'. No need to go into detail here as the provenance aspect of the theory is not developed here.

Not to get too technical, but I'd permit 'octet sequence' as a particular kind of 'string'.

There is a relation 'has reading' between 'information resources' and 'simple IRs'.

'Has reading' is not functional, because we want to admit interpretations where readings vary by media type, language, session, time, whim, etc. And it's not inverse functional, as a simple IR can be a reading of multiple IRs (e.g. itself and some non-simple IR).

Example under one interpretation: a serial publication, where the January issue (encoded as a particular octet sequence) is a reading of the serial in January, and the February issue is a reading of the serial in February.

Other example: an "abstract document" (or "generic resource"), with readings ("fixed resources") in particular languages.

Compare HTTP Content-location: header.

TBD: Whether this holds may depend on circumstances (time, conneg, weather, etc.). Until circumstances are axiomatized (in some future version?) you can imagine the relationship holds if any such circumstances exist. If the axioms listed here conflict with circumstance dependence, that's a bug.

'has reading' is reflexive on simple IRs, and total on IRs.

That is, a simple IR is its own and only reading, and every IR has at least one reading.

(candidate requirement) An IR that has only one reading is a simple IR.

This seems plausible but I can't think why it would be needed.

(candidate requirement) A simple IR is its only reading.

This seems plausible but I don't know why it would be needed.

Connecting to other vocabularies

The goal here is to force consistency with (and explanation of) deployed use of dereferenceable URIs in RDF statements. To do this we need to tie these axioms into other ontologies.

'simple IR' is a subclass of 'foaf:Document'

This seems both desirable and safe, given how foaf:Document is both defined and used.

This does not rule out the possibility that other 'information resources' are also foaf:Documents as well.

'simple IR' is in the domain of 'foaf:sha1', which is functional on it and factors through 'has content'.

This makes sense because 'has content' is functional - not varying by time or any other circumstantial variable.

Agnostic on how content-encoding figures into this.

Metadata properties

The axioms quantified over 'metadata properties' create a pattern that can be repeated for a selected but large set of properties from FOAF, Dublin Core, Web Linking (RFC 5988), XHTML, and elsewhere, substituting each property in turn for 'P'.

I don't know how to define 'metadata property', nor would it be appropriate to do so here; the best I can say is that they are properties that 'make good sense' as providing information about simple IRs. In a future version of this report I may include a list of properties from the above ontologies that I would consider metadata properties. The more of these there are, the harder it becomes to misinterpret the axioms.

Following is the central idea of these requirements:

Let P be a metadata property, let R be an 'information resource', and let x be a member of the range of P. Then P(R,x) if and only if P(S,x) holds for all readings S of R.

In the 'only if' direction this says that a metadata property 'spreads' from an IR to all of its readings. In the 'if' direction, it says invariant properties of readings 'gather' into the IR.

This precludes using P with, say, a serial publication where different issues are created by different agents.

The IR must 'fess up' to things that all of its readings do. This rules out pathologies where something is P-related to all of a document's translations but not to the IR itself. The practical benefit is that it lets you 'gamble' on hypotheses of an IR formed by investigating a number of its readings. You're not guaranteed to be right, but you may be willing to act on the hypothesis.

This gamble happens all the time when putting links on web pages. You look at a document and decide it has the properties of something you'd like to link to. Then you add the link, perhaps reporting some of those properties ("a cool picture of a fish") in the anchor. You can get different readings at different times as long as you still think the picture is suitable for your purposes. The URI authority can change the picture out so as to make it unsuitable, but the risk of that happening is often judged to be low enough to be acceptable. If it's not, you do something else.

Example to think about: "serializes an inconsistent RDF graph (or OWL ontology)".

dct:creator, dct:subject, dct:title, dct:date, foaf:topic, and foaf:primaryTopic (among others) are metadata properties.

The inverses of foaf:homePage, foaf:interest, foaf:openid, foaf:publications, foaf:tipjar, and foaf:weblog are metadata properties.

'has content' and 'has media type' are metadata properties.

This implies that if an IR has readings with distinct content then the IR does not have (particular) content. Similarly for media type (and presumably the other string parts of a simple IR).

'serializes RDF graph' is a metadata property.

Details TBD, but this would be a function of the content and media type. If the media type is application/rdf+xml or a type appropriate for turtle or N-triples, and the content is syntactically well-formed, then this property would relate the IR to the serialized graph.

Compare TimBL's 'log:semantics', which has as its range 'log:Formula'.

This is a made-up property for the purposes of this exposition. In the intended model, if the IR is subject to, say, text/plain vs. application/rdf+xml content negotiation, then this property would not hold, unless a deterministic mapping from text/plain to RDF were assumed and it yielded the same graph. This makes it somewhat different from log:semantics.

(TBD: Need to figure out how to obtain the base URI! - from the provenance component of the reading(s)?)

TBD: Consider owl:imports owl:versionIRI rdfs:seeAlso rdfs:isDefinedBy

Web-relating axioms

Not every IR needs to be 'on the web', but it should be possible to put many of them 'on'.

We don't require that every dereferenceable URI be related to an IR, but we do need to say what the special relationship is, when it exists.

(def) A simple IR is 'authorized for' a URI in certain circumstances iff it would be a correct result when dereferencing (sensu RFC 3986) the URI in those circumstances.

"Correct" means technically correct per consensus specification (e.g. RFCs) and recognized authorities (e.g. DNS). This would be hard to formalize, and I hope we won't have reason to.

'Authorized for' is similar to 3986 'dereferences to' (inverse) but (a) we want to rule out the case of unauthorized dereference (system got hacked, etc.), and (b) no actual dereferencing act has to happen in order for this to hold (e.g. data: URIs?).

We may need to account for the circumstances of authorization in order to admit intended interpretations and rule out incorrect ones. A particular simple IR might be authorized for a URI in a secure session with one user, but not in another. Or if the domain has multiple A records, the simple IR might be authorized when the request is processed by one server, but not by the other. I would prefer to avoid this issue if possible.

I'm pulling a fast one here since 'dereferences to' is defined in 3986 to yield a 'representation' but here we need a 'simple IR'. The parts (content, media type) of the simple IR I have in mind are those of the representation. The provenance (or whatever) should be determined not arbitrarily, but by in a way determined by the authorization trail. (And I'm not sure what has to happen or not happen to that trail as the 'representation' passes through proxies and caches.) Perhaps this should be axiomatized.

(def) An 'information resource' is 'bound to' a URI iff every simple IR that is 'authorized for' the URI 'is a reading of' the information resource.

This formalizes "on the web".

Both directions of the 'if and only if' are important. Most consequentially, if we know something about what simple IRs are authorized for a URI, we can infer properties of the IRs bound to the URI. This prevents URI authorities who say agree that x is bound to one of their URIs from denying that x has certain properties (e.g. being a serialization of some RDF graph).

To make 'bound to' inverse functional (probably impossible and perhaps undesirable), we would have to say which IR is bound, either as a least upper bound of the readings, or as determined by the authorization process. This is tough - this ought to be a matter of fact, independent of anything the URI authority says.

One case where 'bound to' might not be inverse functional is data: URIs, for the same reason that simple IRs are not the same as representations. For example, data:,chat could be independently generated by an English speaker and a French speaker, and intended to refer to simple IRs depending on context. In this case the provenance of the simple IR would be the provenance of the URI itself. Or would these dereferencings be unauthorized? Hard to say.

TBD: Need to think about 'circumstances'.

(candidate) For any set {S1, S2, ...} of 'simple IRs' there exists an IR that has S1, S2, ..., as readings, and no others.

That is, a server operator can throw whatever he/she likes at us, and we will still be able to treat their URIs as being bound to something.

This axiom is part of the httpRange-14 rule (if you get a 200 then the resource is an IR), but I don't think that's not sufficient reason to require it. The purpose is to allow you to write meaningful metadata even when the URI authority is looking for plausible deniability for it, or when an IR ight otherwise be impossible. Possible example: random page generator (suitably axiomatized) may be inconsistent with some interpretations otherwise.

If infinite sets are allowed here we would have to constrain the axiom somehow, e.g. decidable membership.

(def) An interpretation of an RDF graph 'respects IR bindings' if, for each dereferenceable URI occurring in the graph (outside of literals), the URI is interpreted to be an IR bound to that URI.

This is explicitly not an assertion that all interpretations 'respect IR bindings'. However it does let us express the first clause of the httpRange-14 rule (or rather what was intended by it) as "kindly use interpretations that respect IR bindings".

If this definition makes you formally queasy (that's you, Pat) try the following alternative: A satisfying interpretation 'respects IR bindings' if it is also satisfying for the graph formed by merging (a) the given graph, (b) a set of 'binding statements', one per dereferenceable URI occurring in the graph, and (c) an appropriate RDF axiom set derived from the above axioms. The 'binding statement' for a URI uuu is defined here to be the statement <uuu> :boundTo "uuu"^^xsd:anyURI.

('Satisfying' is relative to your choice of logic, of course.)

This would be simpler if we could define which IR is implicated for each URI, but this may be both impossible (the URI authority certainly won't be helping us out) and unnecessary (the IR is already constrained as far as observable behavior goes, what else do you want?).

Nontriviality axioms

These axioms are intended to help rule out degenerate models.

'simple information resource' is a proper subclass of 'information resource'.

There exists a simple IR that has a media type.

Maybe we don't have to assume this, but the intent is to make it harder to interpret 'information resource' as being exclusive to, say, FTP resources.

There exists an IR that has at least two distinct readings.

This could be two readings at the same time, or at different times. Time and other circumstances are not treated, yet.

If P is a metadata property, then at least one simple IR is in the domain of P.

Although this is weak, it helps prevent unreasonable interpretations.

Possible generalization: for any metadata property P, there is an x and simple IRs A and B such that P(A,x) but not P(B,x). That is, metadata properties are informative.

There exists an 'information resource' that is bound to the URI "".

This is intended to lead you to interpret the axioms to apply to web pages 'in the wild'.


TBD: transcribe to OWL, and derive an inconsistency from an example (toucan, flickr, jamendo, etc)

Prefixes used

@prefix irx: $lt;> .
@prefix log: <> .
@prefix dct: <> .
@prefix	foaf: <> . 

Appendix: Assigning responsibility for metadata errors

(This probably doesn't belong in this document, but I've written it and have no better place to put it.)

Suppose that <http://example/z> is generally interpreted to be some simple IR (whether 'bound' to it or not). We can conclude that <http://example/z> foaf:sha1 12345 (if that's the IR's correct sha1), even if the IR itself says <http://example/z> foaf:sha1 56789. We can just compute the hash and express it in this way, without having to be able to parse or interpret the document first to make sure the URI isn't going to be used in some other way.

Inconsistencies always admit multiple intervention points. Someone could be misinterpreting the URI (either us or the author of the IR), it could be a simple mistake, it could be neglect (being unclear), something might have changed, etc.

A similar situation holds when an edition of The Autobiography of Alice B. Toklas (assume it's an IR), known under the URI http://example/autobiography, says <http://example/autobiography> dct:creator "Alice B. Toklas". One would correctly ignore that statement and write <http://example/autobiography> dct:creator "Gertrude Stein" in this situation. In this case the statement is neither a misinterpretation nor a mistake; it is a joke.

If those writing metadata are going to be willing to be held responsible for what they write, the correct interpretation of metadata must not involve conferring any authority to the IR. One has to be able to express what one believes about an IR without being vulnerable to anything it might say, since there is no option of fixing the IR if it's wrong - even if you wanted to, which in the case of Stein's book you don't.

It is useful to have a way to assign responsibility for inconsistencies like these. One way to do this is to agree that dereferenceable URIs are to be interpreted as the information resources to which they are bound (however you want to interpret that). Anyone who uses the URI otherwise would then be responsible for these errors. Much metadata is expressed this way today. But other designs are possible. For example, one could write the metadata's subject as [:isBoundTo "<http://example/z>"^^xsd:anyURI] instead of <http://example/z>, so that <http://example/z> is freed up for other purposes.

Questions / TBD

Consider 'specific' instead of 'simple'

Consider 'generic information resource' instead of 'information resource' to stand aside for those who want to use the word in some other way

Turn 'respects IR bindings' into a metadata property on graph serializations?

Introduce composition of graph serialization and entailment as a way to handle the partial nature of RDFa decorations (i.e. the prose says more than the RDFa does). Maybe call this 'says' and relate to Dan C's work.

Maybe rename 'metadata property' to something that reflects how specific these are - 'inherited metadata property'?

What about 301/302/307 redirects? We can decide whether the information resources bound to the source and target URIs are the same, or are related somehow. Metadata probably gets applied to the (referent of the) URI expecting redirects to take place, but that doesn't mean the information resources are the same. In fact saying they're different - or that the provenance of the simple IRs differ - gives us a way to explain browser behavior where the target URI of a 302 or 307 is displayed instead of the source URI - the browser simply doesn't believe that the simple IR from the target is authorized for the source. Making this go requires a change either to authorization or to binding.

Should a simple IR's non-string aspect be made more explicit? We could say that a simple IR's identity is defined by its string-parts (content, media-type, ...) and its 'phlogiston'. I.e. can be modeled as an (immutable) tuple. We can ask TimBL whether he is happy to call this mysterious substance 'provenance' instead of 'phlogiston'.

(optional) Information resources are not in the domain of [...].

TimBL at least has argued that information resources, whatever they may be, do not have momentum or position, and are not mathematical. Forgetting ontological concerns, functionally the purpose of saying this is to help rule out misinterpretation. Nonsense invites misinterpretation and threatens interoperability.

Strictly speaking, nonsense detection is not forced by the metadata use case, as far as I know, although it is not be too hard to come up with interoperability scenarios where nonsense would get in the way of proper function. Scenarios in which this axiom would matter are invited.

Even without this axiom, it ought to be pretty hard for a reasonable person to interpret IR-referring terms as anything other than appropriate metadata subjects, because of other axioms (below).

Change log

  1. Modifications per Alan R review, esp. concerning the way the simple IR parts axiom is phrased.
  2. 2011-02-20 Modifications per Hal review.
  3. 2011-02-21 Add some more particular metadata properties.
  4. 2011-02-22 Modifications per Hal review: combine central 'if' and 'only if' metadata property axioms into a single axiom.