W3C home > Mailing lists > Public > www-tag@w3.org > October 2004

RE: [Fwd: RE: "information resource"]

From: <Patrick.Stickler@nokia.com>
Date: Mon, 18 Oct 2004 12:27:26 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A56471E5@trebe051.ntc.nokia.com>
To: <algermissen@acm.org>, <www-tag@w3.org>

> -----Original Message-----
> From: www-tag-request@w3.org 
> [mailto:www-tag-request@w3.org]On Behalf Of
> ext Jan Algermissen
> Sent: 17 October, 2004 23:24
> To: www-tag@w3.org
> Cc: www-tag@w3.org
> Subject: Re: [Fwd: RE: "information resource"]
> Sandro Hawke wrote:
> > A 404 implies something quite
> > different (something about the URI owner I guess!) 
> AFAIK it implies: "(Currently) no representation available", IOW: the
> resource maps to the empty set (of representations).
> > but says nothing
> > about whether it's an information resource.
> Well, if on Monday the 200 (as you suggest) indicates that the
> resource is an information resource, then a 404 on Tuesday IMHO
> equally well indicates the contrary - that it is *not* an information
> resource.
> I think the whole issue about 'resource kind' is pointless 
> (as has been
> said already). Consider a trouble ticketing system with a certain
> ticket identified by http://example.org/tts/tickets/66546. A 
> GET on the
> URL returns an HTML page with all the metadata (owner, dates, etc.) in
> there and the complete history of the ticket.
> Is the resource (the ticket) 'a document' (roughly: "the 
> stored bytes") or
> is it the abstract concept of 'the ticket' (independent from 
> any notion
> of physical substance)? Both answers make sense and even if 
> you were able
> to clearly choose one, it is pretty likely you'll find 
> yourself using the
> other answer in other circumstances in the future.
> IMHO the issue is not solvable at the WebArch level and should not be
> tried to be solved there.

Agreed. At least not by the core web machinery.

However, IMO it would ideal to be able to ask

   MGET /tts/tickets/66546
   Host: example.org

and be told what that URI identifies. I.e. the necessary SW machinery
can be deployed atop the web, fully compatible with the traditional
web functionality for providing access to representations, without
forcing the machinery dealing with access of representations to
deal with the broader semantic questions asked by SW agents.

> Personally I favor the approach that if you want to know what 
> a URI identifies,
> you go look at how the URI is (collaboratively) used.

Well, seems like you'll end up with the old "blind men and an
elephant" syndrome. Why not just ask the web authority of the
URI for an authoritative description of the resource identified
by the URI and be done with it?!

Yes, common usage can be informative. But if you want precise
behavior from your agents, you'll need precise knowledge.

I wouldn't want to see agents dealing with banking, travel,
or (gasp) medical issues guessing about the meaning of URIs
based on what other agents are using them for.


Received on Monday, 18 October 2004 09:50:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:43 UTC