From W3C Wiki

Back to AwwswHome

Goal: An OWL-DL ontology, replete with domain, range, subclass, disjointness, and other constraints. Intended to be utilitarian, not philosophical.

First application that the ontology will serve: To be able to express (some of) the meaning of an HTTP request/response interaction in RDF. This is not a syntactic description of requests and responses (as is HTTP in RDF), but rather a rendering of what the sender and receiver mean to say when they transmit the request or response. So the subject matter of the RDF we'll write in this application is not the form or syntax of requests or responses, but rather the subject matter of the messages themselves - the RDF would communicate whatever it is that the requests and responses mean or imply. This meaning is of course specified in RFC 2616, so the problem is that of capturing, in RDF, what these messages mean according to RFC 2616.

I'm not talking about the message content - e.g. whether a response gives a weather report or a traffic report - but rather whatever the protocol (headers, mostly) are saying about the resource, the message's protocol-level intent, and the relation between the resource and the messages. If we succeed at this then maybe we can proceed to talk about the content, but that takes us much further into Semantic Web territory.

Second application: Develop further (stronger) RDF interpretations of protocol (message meaning), following other disciplines such as AWWW, the httpRange-14 rule, REST, abstract documents, or some new thing we might come up with.

Although this is a text file, the intent is to replace it with an OWL-DL ontology once we have a solution to the collaborative ontology editing problem.

Rules of engagement

  • Request a term (eventually a URI) by adding a new entry to this file
  • A term request consists of the following components:
    1. Suggested names (labels) and kind (class, property, individual). Name is not a substitute for definition. Please capitalize class names.
    2. Who's requesting it
    3. Definition
    4. Definition source (where the definition came from)
    5. Constraints (subclass, domain, range, disjoint with, etc.)
    6. Example of use and/or use case
    7. Motivation/use case (why it might be needed in RDF assertions)
    8. Discussion
  • Use case or strong motivation is required - please don't add terms unless they serve stated goals (above). For safekeeping you can put terms in AwwswListofTerms
  • OWL-DL model theoretic semantics applies - let's not spend too much time going meta
  • For any class, adequate properties should be defined to permit meaningful discrimination between that class (or its individuals) and others. (Not sure this is being said right - just saying that classes should be grounded in the nature of properties of their individuals.)

If you don't like a name or label, please add a name you prefer to the list of names. Maybe later we'll decide on canonical names, but for now let's not fight - just let the definition be master. (Of course do not apply the same name to two different entries.)

This is patterned after the method used by any number of other collaborative ontology development efforts.

Terms needed for a treatment of RFC 2616

See HTTP 1.1 RFC 2616

Entity; Entity sensu RFC 2616; rfc2616:Entity; HTTP Entity (class)

  • Requested by: JAR
  • Definition: An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body. The information transferred as the payload of a request or response [is an entity].
  • Note: AWWSW group consensus is that RFC 2616 does not mean to say that things that are *not* transferred as payloads are disqualified from being Entities. That is, something can be an Entity even if it's not transferred anywhere.
  • Definition source: RFC 2616 section 1.3.
  • Constraints: not sure yet. At the very least Entities have to have parts metainformation (perhaps empty) and content (perhaps entity).
  • Constraints: An HTTP entity can be part of an HTTP request or response. The entity is not the entire request or response; e.g. a request also has a request-URI and request-headers, and these are not part of the entity
  • Constraints: According to TimBL (2009-04-14), an entity is a kind of awww:representation.
  • Constraints: According to Roy Fielding, every entity is an rfc2616:representation of some (state of some) resource - but not necessarily the resource named by the request-URI in the HTTP exchange. But if the response is a 200 response, then the entity is an rfc2616:representation of the (state of the) requested resource.
  • Constraints: An entity is not an event; the same entity may be part of multiple requests and/or responses.
  • Use case: We need this in order to encode that an HTTP response or request is meant to say something about the entity (e.g. that the content-type is meant to bear some relation to the content or its interpretation).
  • Motivation: This seems a logical starting point
  • Discussion: Compare to - same?
  • Discussion: Although the most obvious role of an Entity is to carry information "coming from" a Web resource (compare the various "representation-like" classes below), something can be an Entity without necessarily coming from any Web resource. For example, the payload (content + entity headers) of a POST request, or of a 4xx or 5xx response, is an Entity, but does not necessarily bear any particular relation to any Web resource.
    • Discussion: DBooth: See also rfc2616:Representation, which is a subclass of rfc2616:Entity that is restricted to responses.

Web resource; Resource sensu RFC 2616; rfc2616:Resource; Network resource; HTTP resource (class)

  • Requested by: JAR
  • Definition: "resource" per RFC 2616 = "network data object or service"
  • Definition source: RFC 2616 1.3
  • Constraints: not sure yet. Not the same as rdfs:Resource. Probably safe to assume disjoint with foaf:Person and Entity as above. May bear relationships to vocabulary that we might need in the future when talking about AWWW and the httpRange-14 rule. (Harry: (Paraphrased by DBooth) At some point we may want to define a subclass of Web resource that MUST have a URI and MUST allow access to a Web Representation/Entity, because those are kind that people often want to use, to know they can access the resource.)
    • DBooth: FWIW, this class corresponds to class ftrr:IR, though modeled/described differently.
  • Use case: According to RFC 2616, an HTTP request asks to perform some operation (GET, PUT, etc.) on a web resource, and an HTTP response reflects the outcome of performing the requested operation.
  • Motivation: Fundamental for this project
  • Discussion: JAR: Earlier I said: although if it turns out to be useless to so restrict it, we could consider extending it in obviously uncontroversial ways; I would say data: URI referents are an obvious case (both intuitively and operationally). I would like to retract this, and define a larger class to include the referents of data: URIs.

comes from (property)

  • Requested by: JAR
  • Definition: Roughly speaking: E comes from R if E is (or could be?) the Entity of a 200 response to a GET whose request-URI names R. RFC 2616 says: "The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process." When someone sends a 200 response, they are assumed to be attempting to follow this advice in good faith. 'comes from' is meant to capture whatever this paragraph means to RFC 2616 speakers: the relationship between an Entity and a Web Resource in a truthful 200 response. Elsewhere in RFC 2616 this is called "corresponds to" - the entity corresponding to a resource etc.
  • Definition source: RFC 2616, as adapted by JAR above
  • Constraints: Domain = Entity (or maybe some subclass of Entity). Range includes Web resource, but we should reserve the right (for now) to broaden the range if necessary to accommodate extensions (are the resources named by data: URIs Web resources?). Of course if it turns out we need to distinguish this property from a more inclusive superproperty then we should have two distinct terms.
  • Use case: When someone sends a 200 HTTP response, we interpret the response as saying that the entity in the response "comes from" the requested Web resource.
  • Motivation: Fundamental
  • Discussion: Nowadays we distinguish between the information and the resource, and would have to phrase the definition differently.
  • Discussion: Given what's here so far it would be consistent to say this is the same as Pat's idea of "access". (Harry: Agree! Then it seems http:request and http:response would be subsets of at least attempted access relationships.) [DBooth: Does this apply *both* to requests and responses?] [JAR: In representing what an agent "can be held to" or "means", I see no need for request or response classes. Those are source code, and we're looking for object code. In any case I don't understand what you're saying...] [DBooth: JAR, I don't understand your confusion here. Isn't rfc2616 all about requests and responses? ] [JAR: Note that this relationship is appropriate for Entities carried by 200 responses, but not for others such as one carried by a 404.]
    • DBooth: This is very close to the notion of "represents" in the diagram in AWWW , in the case when the entity is a rfc2616:Representation. However, the domain of the "comes from" property is currently defined as rfc2616:Entity instead of rfc2616:Representation (a subclass of rfc2616:Entity). I think it would be better to describe the domain of "comes from" as rfc2616:Representation.

rfc2616:Representation (class)

  • Requested by: DBooth
  • Definition: An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status.
  • Definition source: RFC2616 sec 1.3.
  • Constraints: rfc2616:representation rdfs:subClassOf rfc2616:entity .
    • DBooth: Note that an rdc2616:entity may be either for a request or response, but a representation is *only* for a response.
  • Use case: JAR: If there is no use case calling for such a class, then we should remove it from the ontology.
  • Motivation: ?
  • Discussion: ? JAR: Here is what I said about this on wiki page AwwswRfc2616: 'I would interpret "subject to" as meaning "may be chosen by" or "may be the outcome of". As a class, Representation would have to be those entities (a proper subclass) that are, or were, or might reasonably be subject to content negotiation (CN). To say that E is an entity but not a representation would be to say that no HTTP server generates E as a result of CN.' This usage seems to be obsolete, as RFC 3986 AWWW both want to say something's a representation even if no CN happens. A modern equivalent might be: Entity that is related by "comes from" to some Web resource. This is a perfectly sensible class, but I see no reason to name it.
    • DBooth: The distinction between an rfc2616:Entity and an rfc2616:Representation does not have to do with content negotiation, it has to do with *direction*: an rfc2616:Entity may be passed in either direction, but an rfc2616:Representation is *only* for responses. Content negotiation is a red herring here. It is true that content negotiation may be used in producing a rfc2616:Representation, but that isn't the key point, that is just a detail of how rfc2616:Representations relate to rfc2616:Resources.
  • Discussion: JAR: Can someone explain to me the difference (in RFC 2616) between a "representation" and a "variant"? The text doesn't make any sense to me.
     A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a 'variant'.  Use of the term 'variant' does not necessarily imply that the resource is subject to content negotiation.
  • JAR: I have read that text many times and still don't see how the two relate.
  • JAR: Roy Fielding says that every HTTP entity is a representation of some HTTP resource. HTTPbis is planning to eliminate the term "entity" in favor of "representation". I find this to be really artificial and distasteful, but at least it eliminates Representation as a class distinct from Entity, something I have been advocating from the beginning. 'Representation' should be reserved for the relationship between an entity and the state of some resource, not a class.

Terms needed for a treatment of RFC 3986

Representation sensu RFC 3986 (class)

See RFC 3986

  • Requested by: HarryH, then split off from awww:Representation by JAR
  • Definition: (RFC 3986) A "representation" is a sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated.

Terms needed for a treatment of AWWW


awww:Representation (class)

  • Requested by: HarryH
  • Definition: A sequence of octets, along with representation metadata describing those octets, that constitutes a record of the state of the resource at the time when the representation is generated. [JAR: Is this really what AWWW says?]
  • Definition source: RFC 3986
  • Constraints: Not the same as RFC 2616 Entity. Is it a sub-class? Not sure. JAR: I think HTTP Entity is a subclass of awww:Representation; TimBL confirmed this on 2009-04-14.
  • Use case: HTTP requests and responses talk about these things. JAR: This is not clear. I think HarryH means that requests and responses talk about HTTP entities that are rfc2616:representations of the network resources. But in AWWW, awww:representations belong to AWWW information resources, and we have not established any relationship between AWWW information resources and RFC2616 network resources.
  • Motivation: This word causes lots of problems, we should figure out if it can be ditched or not.
  • Discussion: History: RFC 2616 gives a different definition (see above). AWWW's glossary say "data that encodes information about resource state", which is not as specific. We may end up needed to separate the 3986 sense from the AWWW sense.
  • Discussion: We need to figure out if we can subsume this under HTTP entities or not. I think perhaps that the definition in RFC 2616 is not too good [JAR: It is what it is, and it's normative!], but the one in RFC 3986 then suggests that this is basically entity with a restriction that it must include the representation metadata, like content-type? [JAR: It additionally restricts to those entities that constitute the state of some resource. Not all entities do that.] But do HTTP entities have that restriction as well? [JAR: No, not according to section 7.2.1 of the RFC; Content-type is only a SHOULD, not a MUST.] If so, they are synonyms and we should explicitly state that in an owl:equivalentClass axiom. I'd say we should keep distinct from philosophical representation by using word "Web" in front of it. [DBooth: As noted above, an entity can be for a request, but a Web representation can only be for a response, so it must be kept separate.] [JAR: Can't a representation sensu RFC 3986 be the payload of a PUT? If not that would be very non-RESTy.] [DBooth: My opinion: No, because the term is predominantly used in the context of responses, and if the notion of representation is not restricted to responses then we would have to make up yet another term for representations that are restricted to responses.] [JAR: why? what is the use case?]

awww:Information resource (class) a/k/a awww:IR

  • Requested by: HarryH
  • Definition: Coined by the W3C TAG as "whose essential characteristics can be conveyed by a message"
  • Definition source: W3C TAG WebArch.
  • Constraints: I would say it should have some realization, and is a sub-class of Resource but a super-class of Web Resource. See discussion. It may have a URI and may have Web Representation/Entity, but unlike Web resource does not have to have a URI or Web Representation/Entity.
  • Use case: Mostly used in 303 redirection solution to httpRange-14 and linked data community vocabulary [JAR: That's not a use case]
  • Motivation: To figure out if we need to rephrase this in terms of Web Resources.
  • Discussion: The question is whether or not this most troublesome of terms should be dropped or not. I would say that it seems like there are two readings of this term. One is that it should be merged with Web Resource. The second is that it's a superclass. TimBL seems to support the second reading, saying things like "A text of Moby Dick" is an information resource, since it MIGHT be realized as a entity/Web representation accessible via a URI, even if it is not at a given time. The main issue with this is that determining whether something MIGHT be a web-resource is harder than determining if something is. Seems philosophically feasible, even if a bit confusing though, so perhaps should be kept.
    • DBooth: In my view awww:IR is definitely *not* a superclass of rfc2616:resource, because it does adequately cover cases where the representations depend on time and request inputs. Consider the Oaxaca weather report example in AWWW: . The URI is intended to identify the current Oaxaca weather report. But there is no way to convey the essence of that notion in a message. One *can* convey the weather report for a *particular* day in a message, or even several particular days, but not the notion of the current weather on any day for all time.
  • On 2009-04-14 TimBL said that AWWW information resource and TimBL Generic Resource are intended to be the same.

is named by; is denoted by; is identified by; has URI (property)

  • Requested by: JAR on behalf of HHalpin
  • Definition: (Difficult to define without appearing to simply provide synonyms.)
  • Definition source: JAR, AWWW(?)
  • Constraints: Domain is anything (rdfs:Resource), range is xsd:anyURI
  • Example: The web resource that is this wiki page is named by the URI "" .
  • Discussion: Related to cwm's log:URI. This is more naturally written the other way around (names, denotes, etc.) but RDF doesn't permit literals as subjects.
  • Discussion: I don't see how to make this very rigorous. There is the question of how a URI comes to denote, and whether denotation is context-sensitive (reasonable agents might differ in their understanding of what a URI denotes, perhaps irresolvably - cf. Hayes/Halpin ambiguity paper). I would appeal to RDF or OWL semantics and just say that in any interpretation, this property relates (inversely) each URI in the interpretation to the interpretation of the URI in that interpretation. Care must be taken to avoid self-containing sets. Cf. POWDER's treatment of a similar situation.
  • Discussion: JAR does not like "identified by" for the same reasons Pat Hayes doesn't.


REST is "representational state transfer," so an account would say representation of what, state of what, etc. The model is mutable information-carrying entities (documents, databases, etc.) that may be in different states at different times; one may set the state with PUT, modify with POST, access with GET, delete with DELETE.

REST Resource

  • Requested by: JAR, because it occurs on his diagram #5
  • Definition: Whatever "resource" means specifically in the context of the REST model; something that has at least one REST state.
  • Definition source: JAR made this up. Should look for a better definition.
  • Discussion: Roy suggests that there may be resources that are "concepts" and have no representations. These would not be REST resources by this definition.
  • Discussion: JAR: Not clear whether a REST resource is physically embodied. I think it has to be, because of mutability.
  • Note: The definition is not very operational. This is a work in progress.

is state of (property)

  • Requested by: JAR, because it occurs on his diagram #5
  • Definition: relates the REST state of a REST resource to a REST resource that is in that state
  • Definition source: JAR

REST State

  • Requested by: JAR, because it occurs on his diagram #5
  • Definition: A state of a REST resource; a condition that some REST resource is, has been, will be, or might be in. A state has at least one REST representation.
  • Definition source: JAR
  • Discussion: States are 'generic' in nature in the sense that a resource can go from one state to another and back to the first (i.e. the state is not tied to any particular time or event) and two different resources can both be in the same state (i.e. the state is not tied to any particular resource).

is representation of (property)

  • Requested by: JAR, because it occurs on his diagram #5
  • Definition: relates a REST representation of the REST state of some REST resource to a REST state of which the REST representation is a REST representation. Nowadays this might be called a "serialization" or "partial serialization" of the resource's state.
  • Definition source: JAR

REST Representation

  • Requested by: JAR, because it occurs on his diagram #5
  • Definition: bits plus metadata
  • Definition source: JAR
  • Discussion: A single REST representation can be a 'representation' or serialization of two different REST resource states.
  • Discussion: Probably the same as "representation" per AWWW.

From TimBL generic resources memo

Generic Resource (class)

  • Requested by: JAR, because it occurs on his diagram #5, and because Tim has written about it
  • Example: ?
  • Discussion: Definition not clear (to JAR at least; clear to Tim)
  • Discussion: Tim says he means for this to be the same as awww:InformationResource. JAR asks whether a POST target is a generic resource, and Tim says no, that would be something else, maybe an "HTTP resource". JAR concludes that there are HTTP resources that are not information resources.

Time specific resource, Time-invariant resource, Version (class)

  • Requested by: JAR
  • Definition: "A resource of which all representations are in the same version. Representations of the resource will not change as a result of th resource neing updated to a version with time. The dates of creation and of last modification of such a resource would be expected to be the same."
  • Definition source:
  • Example:
  • Constraint: superclass of Fixed Resource
  • Discussion: Can a single Version be a version of two distinct generic resources?

Fixed resource (class)

  • Requested by: JAR
  • Definition: a resource from which only one entity can/will ever come (this makes it derivable using OWL, I believe)
  • Definition source: JAR's way of capturing the definition in Tim's generic resources note
  • Constraints: 'comes from' is inverse functional on this class. A subclass of Web resource.
  • Example: referent of a data: URI (modulo the question of whether such resources are web resource); contents of internet archives (need to track down something solid! W3C URI stability is good but may permit CN, or be less rigorous than this in other ways)
  • Motivation: ontology practice
  • Discussion: If we start to confuse theory and truth (how do we *know* only one entity will ever come from it?), let the model theory be our guide. Someone who says something's a fixed resource may be contradicted by evidence. Inconsistency is a fact of life - something we have to deal with.)
  • Discussion: The resources named by data: URIs are fixed resources (I think Tim agreed to this)

From places other than W3C Recs and IETF RFCs, but they keep coming up!

ftrr:InformationResource (class) a/k/a ftrr:IR

  • Requested by: DBooth
  • Definition: A function from (Time x Request) to awww:Representations. These are the conceptual things in web architecture that can produce awww:representations.
  • Definition source: David Booth. Roy Fielding's definition of "resource" in @@citation needed@@ is basically a curried form of ftrr:IR.
  • Constraints: Not sure what to write here. [JAR: You could say that this is a subclass of Web resource, or AWWW info resource, or superclass, or the same; or you could say it's disjoint from Web resource [my preference since to me a function is not accessible], but that instances of it are related to instances of Web resource via some relationship - I think you said these functions are meant to "model" Web resources.]
  • Use case: If you replace the current AWWW definition of information resource with this definition, the AWWW makes a whole lot more sense. :) [JAR: Fine, but when is membership in this class going to be asserted in some curation, interpretation, or translation activity? How does this class play a role in inference?]
  • Motivation: Not sure what to write here. [Why did you feel it was important to add this class to this ontology? Please review statement of purpose at top.]
  • Discussion: DBooth: This is basically a superclass of awww:IR, because awww:IR does not adequately cover cases where awww:representations are generated dynamically based on both the current state of the resource (or time) and the request. If "Web resource" is restricted to having a URI and allowing access to awww:representations then Web resource is a subclass of ftrr:IR, because an ftrr:IR does not require them. [JAR: I don't see how you can come to these conclusions. To me, functions and Web resources are very different things, and I know of no x which is both - can you give an example?]


  • Requested by: HarryH
  • Definition: a resource from which no entity can/will ever come
  • Definition source: This term keeps coming up in discussions, far too often - mostly used in Linked Data, see [1]
  • Constraints: Disjoint/ComplementOf Information Resource
  • Example: An actual person, such as Jonathan Rees, as opposed to their web-page.
  • Motivation: A type of resource that should not respond with a HTTP 2xx, but instead should redirect using 3xx or use a fragement identifier.
  • Discussion: This term may need to be deleted, and one of the goals of modelling should be to determine if its needed. Think it should be here, but on the stack to the end.
  • Discussion: JAR strongly objects to defining this as an ontology term, as it would suggest the need to create a similar Non-X term for every other class X. TimBL has stated a similar sentiment.


  • Requested by: HarryH
  • Definition: a resource which is accessed via a redirect from a URI
  • Definition source: Used in POWDER and sometimes called "associated description" [2]
  • Constraints: A subclass of Web resource. Should have some "redirection" property from a NonInformationResource.
  • Example: An web-page such as for
  • Motivation: A type of resource that should respond with a HTTP 2xx, so Entity can be found that "describes" the nonInformationResource.
  • Discussion: This term is non-standard per se, but important to the future of the Semantic Web in practice and will become more

important in future. One motivation of this is Semantic Web or Linked Data validation.

  • Discussion: (JAR) I think any resource can be a description resource - description resource is a role, not a class. There is no way to look at a resource and determine that it is or isn't a description resource. Also, do you mean 303 redirect specifically? See

TimBL information resource

  • Requested by: Jonathan
  • Definition: Defined axiomatically, as follows: (1) You can expect to get the same information next time (typically) [meaning: you can get information for it or from it] (2) You can get different content-type of the same thing (3) Some change with time, some don't (4) Tim knows what one of these is.
  • Definition source:
  • Constraints: to be determined. Disjoint from 'city'
  • Example: ?
  • Motivation: Desire to include Tim in this discussion
  • Discussion: I am happy to have Tim modify this for precision.


A good measure of whether we're doing anything that's not just hot air is whether we can use the ontology to explain incorrect behavior - e.g. responses that "lie" about the resource.

Examples of contradictions (incorrect response given the request, internally inconsistent response, badly behaved proxy server, or two responses that are inconsistent) are difficult to track down because (1) the server is "authoritative" about just about everything - expectations are low and (2) much of the refutable content of a response (e.g. telling one client that a resource hasn't changed and another that is has) has to do with time, and we want to avoid talking about time.

But one example was given above: If the request-URI is data:text/plain,banana, and the server responds with a 200 response with Content-type: text/plain and content "plum", then the server is not "telling the truth" - it is asserting that "plum" comes from the resource, and according to RFC 2397 only "banana" can come from that resource. That is, data:text/plain,banana is a Fixed resource, there is an Entity E related to it via comes from according to RFC 2397, a different entity E' related via comes from according to the server, and since 'comes from' is inverse functional for Fixed resources, we have a contradiction.

To be done

JAR: Explain what someone who talks RFC 2616 is saying, and how one might check what is said, thereby distinguishing agents who speak the truth from those who don't. Then, after that, move on beyond RFC 2616 to RFC 3986, AWWW, and Fielding's ICSE paper (MichaelHausenblas says: maybe better Roy's ACM TOIT journal article from 2002).

  • What do 30x responses say? Is it possible for a 30x to be invalid?
  • What is content negotiation about? It is possible for one of the variants to be incorrect (given what the other variants are)?
  • Caching and proxying - certainly it seems possible for a "nonauthoritative" server to provide content that disagrees with what the authoritative server would have said - e.g. content for a resource R that did not come from R.
  • RESTful behavior - how would one describe (using OWL) a server or resource as being not RESTful, e.g. having an unsafe GET method?


  • Would like to have a general purpose way to distinguish between things that host Web resources and things that don't. PatH uses term endpoint, but maybe WebServer is better?
  • Should we think about PatH's access vs. reference distinction? [JAR: Yes - we should have two different relations that connect URIs to things... but I'd like to do redirects and CN first]
  • associated descriptions are important in Linked Data, but the term documentation resource is better IMHO. [JAR: POWDER and XRI use 'description resource']

More terms

See AwwswRfc2616, AwwswListofTerms