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 don't know why you think every information resource has to have
representations served for it at some some (one?  many?) URIs.  That
seems non-sensical to me.  Obviously many information resources are
not served with any representations and don't even have a URI.  (For
example: my personal calendar, which is currently only encoded in
notes in various (non-web) files and scraps of paper.)

> 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.

There is a challenging ontological question here about what
constitutes "a ticket".  I agree with you that use should dictate
modeling, and whether or not a "a ticket" is a kind of document is an
issue for the system ontology developers.  I also agree it's an issue
on which they should only decide if it seems likely to matter.

> IMHO the issue is not solvable at the WebArch level and should not be
> tried to be solved there.

The issue comes to WebArch, I think, because there is a long-standing
debate about whether all HTTP URIs identify documents (httpRange-14).
The current text at least gives us more terminology for the debate,
and may help further it in a productive way.

> 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.

With that approach to life, you have no need for any standards or
specifications.   Personally, I've found it a lot easier when writting
network software to read the relevant specifications than to
survey all deployed systems with which my system might need to
interoperate.
 
       -- sandro

Received on Monday, 18 October 2004 10:02:53 UTC