Re: Do resources have representations?

Hi Patrick,

Patrick.Stickler@nokia.com wrote:
> I saw nothing in your summary that I would disagree with. In
> fact, I think it captures the key issues. It's very similar
> to a recent post of mine on the TAG list
> 
> http://lists.w3.org/Archives/Public/www-tag/2003Jul/0172.html
> 
> And I see nothing wrong with your summary. 
> 
> You seem to think there is a problem lurking in there somewhere,
> and I'd like to understand why?

It may just be my mental model that was wrong so far.

Somehow I've assumed that all that a URI "does" is:

- it denotes a resource
- it is associated with some authoritative information

Further, I assumed that representations are properties of a resource, 
that is:

     <http://example.org> hasRepresentation "<http><head>..." .

When I type <http://example.org> in my browser I would see one of the 
representations associated with it.

But in fact, the actual model is different: It's not the resource that 
is associated with a (set of) representation(s), it's the URI, because 
two URIs can denote the same resource yet have different sets of 
representations.

In fact, two people can create two URIs, denoting the same resource, but 
having different representations, and yet think exactly the same things 
about a resource: If the W3C and I both create a URI denoting the W3C, 
we can have exactly the same idea of what the W3C is, yet our URIs can 
have different representations (web pages).

So a URI does *three* things:

- it denotes a resource
- it's associated with authoritative information
- it is associated with a set of representations

And the RDF description of this fact looks more like,

     <http://foo.bar/uri?http://example.org>
         hasRepresentation "<html><head>..." .

where <http://foo.bar/uri?http://example.org> denotes the URI 
<http://example.org>.

This has practical relevance for me because I'm toying with creating a 
web server that uses descriptions similar to this to define what a 
resource is and which representations it has. For example, you could say

     <http://example.org/img/logo> hasRepresentation
         <http://example.org/img/logo.svg> .
     <http://example.org/img/logo.svg>  mimeType  "image/svg+xml" .
     <http://example.org/img/logo.svg>  preference  "1" .

     <http://example.org/img/logo> hasRepresentation
         <http://example.org/img/logo.png> .
     <http://example.org/img/logo.png>  mimeType  "image/png" .
     <http://example.org/img/logo.png>  preference "0.5" .

The server could use this information when serving 
<http://example.org/img/logo>. (This could then also be served through 
e.g. URIQA, so a client can discover all available representations for a 
given resource through this mechanism.)

Now assume that <http://example.org/> shall denote Example, Inc., and 
<http://example.org/home> shall denote the home page of Example, Inc. I 
cannot say,

     <http://example.org/> hasRepresentation <http://example.org/home> .

Rather, I have to say,

     <http://foo.bar/uri?http://example.org/> hasRepresentation
         <http://example.org/home> .

This looks ugly to me, and doesn't fly with the usual language that we 
serve "representations of resources."

There's one alternative that comes to mind: We define that resources 
have representations (i.e., <http://example.org> hasRepresentation 
<http://example.org/home>), and two people can give two different sets 
of representations without contradicting each other; i.e., when I give 
the above representation for <http://example.org> and you give another, 
then the resource simply has two representations. BUT, at a given URI, 
we only serve those representations that are included in the 
authoritative information about that URI.

That is, the set of representations served at a URI isn't simply a 
function of the resource denoted by that URI; it's a function of the 
resource denoted by that URI and of the authoritative information 
associated with the URI.

It seems like a somewhat 'hackish' definition -- avoiding a problem by 
redefining your terms -- but on reflection, this still seems the best 
way to proceed...

Cheers,
- Benja

Received on Monday, 28 July 2003 08:09:13 UTC