- From: Rhys Lewis <rhys@volantis.com>
- Date: Tue, 2 Oct 2007 05:57:08 -0600 (MDT)
- To: "'Williams, Stuart \(HP Labs, Bristol\)'" <skw@hp.com>
- Cc: "'Pat Hayes'" <phayes@ihmc.us>, "'Booth, David \(HP Software - Boston\)'" <dbooth@hp.com>, "'Technical Architecture Group WG'" <www-tag@w3.org>
Hello Stuart, > > But in this particular case, (information resources referred to by > http > > URIs) my description of the process says that they are the same. To > > clarify, the webarch:resource referred to by the racine is an > > information resource and hence is the http:resource. > > So why add yet another term to an already confused and > confusing space? > Won't webarch:Resource or plain Thing (and > webarch:InformationResource if you have to distinquish) serve > in this case? > To be fair, I don't think I added it. It's already there in RFC2616. I just called attention to it. That may be just as bad, of course :) > [Being a little picky, without having tried to poke the > racine referenced resource we know very little about it. > Unless it is a given in the scenario I don't know that it is > an information resource (and even if it 303's or 404's or > something other that 200's - I won't know from that alone > whether or is not it's IR). I might expect it to be due to > the context of the reference... but I don't know.] Agreed, which is why I limited my assertion to being about information resources referred to by http URIs. Actually, the scenario where the racine returns a 303 is interesting. I don't recall us discussing that explicity within the TAG, but I could be wrong. Presumably it means all bets are off in terms of interpreting the secondary resource. Any representation, found by nose following, is not of the racine. Best wishes Rhys
Received on Tuesday, 2 October 2007 11:57:25 UTC