Jonathan Rees
25 February 2011
Latest version: http://www.w3.org/2001/tag/awwsw/ir-axioms/
This version:
(no URI assigned yet)
Previous version:
http://www.w3.org/2001/tag/awwsw/ir-axioms/20110225
The imperative use of URIs as hyperlinks that one can use to access documents is familiar, but URIs are also used as in Web metadata (expressed perhaps in RDF, the Resource Description Framework) to refer to those documents. A technical term "information resource" (replacing "resource") was introduced by Architecture of the World Wide Web for the entities that hyperlinks and metadata are "about". This report describes the author's understanding of what must be true in any adequate theory of "information resources" in order for Web metadata to make sense. The approach is axiomatic, so as to skirt questions such as "what is an information resource" that historically have led to unproductive debate.
The challenges to explaining "information resource" are: (1) to make "information resources" logically independent of Web dereference (and in particular the HTTP protocol), while being able to say 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 - dynamic content, content negotiation, session specificity, and so on.
The main contribution of this note is to say that many important properties of an information resource are invariant over its "representations" (in the Web Architecture sense of the word). If one knows such a property 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. That is, the generation and interpretion of metadata pertaining to the IR are determined by an IR's representations.
It is hoped that this treatment will be a useful reference in future discussion of whether any technical specifications require modification, and if so now.
This document presents the author's views, which have been developed with help from the informal AWWSW task group of the W3C Technical Architecture Group. It is presented as a first step toward consensus within the task group. Comments for the purpose of repairing deficiencies and building consensus are welcome.
It is a purpose of this document to help explain the value proposition for the TAG's httpRange-14 rule.
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, in the TAG's httpRange-14 resolution, and in various writings of Tim Berners-Lee [TBD: cite Generic Resources and various pieces of email], but is never defined in operational terms so that the general reader can 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.
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.
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 expressed in RDF seems to work today.
This class could be interpreted as either a superclass of http://www.w3.org/2006/gen/ont#InformationResource or identical to it.
A 'simple IR' is one with unvarying content, media type, and language. In Web Architecture terms, a 'simple IR' is one that has only one 'representation'.
I'm introducing this term distinct from 'representation' so that I can explain metadata, which is most easily seen as applied to IRs and not representations; see below.
It's supposed to be consistent to assume that this class coincides with TimBL's class 'fixed resource'. See http://www.w3.org/2006/gen/ont#FixedResource . 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. I'm not sure the I can prove 'fixed resource' is adequate.
If you are FRBR-inclined you might be able to be interpret 'simple IR' as a subclass of FRBR 'Manifestation'.
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'.
'Has reading' is not required to be functional (i.e.: we don't require that x has reading y and x has reading z implies y=z), 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.
Compare TimBL's http://www.w3.org/2006/gen/ont#fixedResource property.
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.
That is, a simple IR is its own and only reading, and every IR has at least one reading.
This seems plausible but I can't think why it would be needed.
This seems plausible but I don't know why it would be needed.
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.
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.
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.
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:
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)".
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).
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
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.
"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.
This formalizes "on the web", at least in part. (You might expect other things to hold as well.)
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'.
[This is badly expressed. Need to recast in terms of authorization.]
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.
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?).
These axioms are intended to help rule out degenerate models.
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.
This could be two readings at the same time, or at different times. Time and other circumstances are not treated, yet.
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.
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)
@prefix irx: $lt;http://www.w3.org/2001/tag/awwsw/ir-axioms/ax#> . @prefix log: <http://www.w3.org/2000/10/swap/log#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> .
(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.
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'.
I need a section that talks about how you could have different interpretations depending on time scope. If you're using the theory within a narrow time window or within a particular conversation there may be more or different entailments than if you're using it across a very long time span. E.g. if you're talking to your bank it might be understood that the IR is one specific to your session, while someone doing a review of the bank's web site might interpret the symbols in the theory as associating the same URI with a different (more generic) IR.
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).