Classes for resources and representations

I wanted to put down in writing my summary of the terminology portion  
of last week's call. I don't claim perfect fidelity; some of this may  
have been imagined or may have taken place elsewhere.

I had proposed that AWWSW sidestep the question of forming  
definitions of 'resource' and 'representation' on the grounds that  
(a) the task is not in scope, (b) these definitions had been taken up  
in other fora without resolution, and (c) defining terms (other than  
terms as URIs in ontologies) was not necessary in order to advance  
the goal of creating ontologies and rules.

To my surprise there was pushback from Tim and Noah. I hesitate to  
speak for them but what I heard them say was that natural language  
definitions of these terms were important and should be worked out to  
general satisfaction.

There appeared to be reluctant consensus that 'resource'  was an  
acceptable category of things, and that it was the (uninformative)  
universal category. Noah wondered why his statement "anything can be  
a resource" raised such red flags with Alan and me (which it did). I  
answered, or tried to answer, that there was a world of difference  
between "everything is a resource" and "anything can be a resource".   
"Anything can be a resource" raises the possibility that there are  
things that aren't resources, and this would contradict Tim's  
definition. It would also raise the question of how any particular  
thing goes from not being a resource to being a resource. But I think  
we got past this by accepting Tim's definition, which coincidentally  
agrees with the definition of rdfs:Resource.

The question came up as to why we needed to talk about such a class  
at all, if knowing that something was a resource didn't tell us  
anything. All I could come up with was that in my experience you need  
a name for the universe of discourse quite often in talking about  
architecture. For example, consider how often 'resource' is used in  
AWWW, or 'point' is used in geometry.

(Thankfully the questions of whether this is an appropriate use of  
the term 'resource', or whether the definition was consistent with  
Fielding, didn't come up. I think that these questions have been  
beaten to death elsewhere. Personally I will probably continue to say  
'thing' and avoid using 'resource' unqualified altogether. I think  
Tim has said he'll do the same.)

We then moved on to 'representation'. In email it was asserted that  
'representation' was not a category, and I don't think we resolved  
whether there ought to be a 'Representation' class. I proposed that  
we talk about 'entities' with the definition of this term taken from  
RFC 2616 - entity = content plus entity-headers. One difference  
between 'entity' and 'representation' is that you can have an entity  
that is not necessarily the representation of any IR - e.g. the  
entity carried in a 404 response. So whether something is an entity  
does not require any historical knowledge or any awareness of  
information resources. We can then (as is done in RFC 2616) talk  
about a 'representation' as any entity that does stand in such a  
relationship to an IR. This idea would be compatible with eschewing  
'Representation' as an RDF type in favor of 'represents' (or  
'representation') as an RDF property. (On the other hand it would  
still be possible to have a 'Representation' class by saying that a  
Representation is any Entity for which there exists some IR that is  
'represented' by it - much as a 'chairman' is someone for whom there  
exists a meeting that they chair. Not clear whether this would be  

Tim wanted to be sure that the classes we use were sufficiently  
abstract, e.g. that the entity-headers in an Entity were unordered,  
and that the classes generalized beyond the HTTP protocol. The latter  
goal surprised me since I thought AWWSW was only chartered with  
explaining HTTP, and in any case I felt (along with David) that  
bottom-up design (starting with particulars, such as HTTP, and moving  
to generalities, such as web architecture) would be the most  
effective approach to take in this activity. But this approach was  
resisted on the grounds that it would lead to 'overfitting' to HTTP.  
Although we didn't have time to drill down on this disagreement, I  
imagine the fear is that effort would be wasted either because a  
downstream generalization effort would be unable to leverage previous  
work or that we'd run out of energy before getting around to it. As I  
have found bottom-up design in situations like this to be quite  
productive (similar to use case development), and find retrospective  
generalization a straightforward activity, we may just have an  
impasse of disagreement in judgment here.

To continue this I think we might have to talk about the full set of  
options: rfc2616:Entity and rfc2616:Representation specific to HTTP,  
and general:Entity and general:Representation generalized to web  

We didn't talk about the "is a representation a resource" question  
much but I think we have consensus on a trivial yes answer - a  
representation is a thing, and all things are resources. We don't  
generally give URIs to representations because we don't need to, but  
that's OK.

I hope I'm being fair.

Now, onto 'information resource'...   (just kidding)

This is not a complete meeting record. Minutes are here:


Received on Tuesday, 12 February 2008 14:33:27 UTC