Re: Uniform access to descriptions

Pat Hayes wrote:
<snip>
> OK, I take your point: that you don't disagree with me here, but 
> instead take the view that/ nothing/ satisfies the TAG criterion for 
> an information resource, at least as stated by them: "its essential 
> characteristics can be conveyed by a message"; so the entire 
> discussion is moot, since by the published criterion, according to 
> http-range-14,/ no/ http request should/ ever/ return a 200 code. 
> Which is ridiculous, etc.. But here, I simply disagree with you. At 
> best, I think what you have shown in 
> http://dfdf.inesc-id.pt/tr/web-arch is that the published definition 
> of 'information resource' is faulty. Perhaps so: along with a lot of 
> other people, I also don't like it. But surely the/ intention/ of the 
> TAG was reasonably clear. When a browser accesses something we 
> informally call a 'web site' and gets a 'web page' back to display to 
> its user, clearly said 'page' is a reasonably close facsimile (which 
> is, again informally, what webarch-representation seems to mean, most 
> of the time) of/ something/, and moreover that something has a number 
> of familiar properties: it is located on its server, it can respond to 
> http requests, it might well have been written in HTML, and so on. We 
> all know this and also know, in a pre-philosophical sense, what is 
> being spoken about. We also know that it is very hard to give a single 
> definitive characterization of these things that we can engage with 
> over the internet, partly because the technology keeps changing under 
> our feet and extending the possibilities in new ways. Nevertheless, 
> without splitting hairs about the exact boundaries of this elusive 
> concept, we can all recognize and largely agree on a number of 
> clear-cut example and non-example cases. Webpages and jpeg images are 
> examples. HTML documents are examples. Non-electronic physical objects 
> and abstract or fictional entities are clearly non-examples. The TAG 
> bravely, or perhaps foolishly, tried to give an actual definition: but 
> rather than seize on this and use it to attack the intention seems, 
> even if its good philosophy, not to be the most useful way to proceed. 
> Better to take the intention and use it to attack the definition :-)
Sure, we can take an informal definition.  But the issue becomes serious 
when the TAG intend to invoke such logic.  That is: if _:x HTTP-200 => 
_:x a webarch:IR.  The question was raised with good intention because 
if without such logic, what is the point of httpRange-14?

Then, here is the dilemma: If I publish something in RDF, I must worry 
if something is an IR or not.  Because in logic, a single contradiction 
will invalidate the entire theory.  Hence, I must know precisely the 
definition of IR in order to ensure that my data won't (unnecessarily) 
lead to such contradiction. But I cannot do that with the current 
definition.

Then, since I can always be accused wrong regardless of my best 
intension, what is the point for me to use 303 instead of 200?  The 
latter is cheaper and easier. If eventually, everyone has felt the same 
dilemma that I felt and choose 200 anyway, then by public verdict, 
httpRange-14 becomes useless.

On the other hand, if we don't invoke the earlier introduced logic, what 
is the point of httpRange-14?
    
>> In this sense, any HTML page is abstract with respect to the web.  
>> What is concrete to the web is the "representation" of the resource.
>
> Not in the webarch sense of 'representation'. Those 'representations' 
> are transient entities which exist only as they move across the 
> physical Web in an http (or xxxtp) response message. They are like the 
> photons of the Web: we become aware of them only when they have 
> already ceased to exist, by causing changes to our relatively static 
> data structures.
It is!  What is parsed in your browser is the *representation* of the 
resource denoted by that URI, which is always abstract w.r.t. to the 
web-architecture.  We always understand reality from its representation. 
What I perceived you is not you but your representation in my brain.  
When you dereference http://dfdf.inesc-id.pt/tr/web-arch, you didn't get 
that resource, you get a *representation* or *description* of that 
resource. 
>
>> Or we can take TBL's viewpoint.  To make all slash URI as an 
>> information resource.
>
> The URIs aren't the information resources themselves: the i.r.'s are 
> what are/ denoted/ by the slash URIs. And that's not really an 
> architectural decision: its more of a rule of semantic interpretation. 
> And I (now) think that its the only practical rule to adopt in this 
> case, if we have to have any rules at all. And all the rest of the 
> decision follows from that.
>
>>  This again gives IR a syntactic definition, which is O.K. and 
>> usable.  But the reality that many hash URI are used in a way that 
>> will make TBL's position difficult to accept.
>
> ? Really? But it seems to me that this position is entirely/ agnostic/ 
> about the meaning of hash URIrefs. Which indeed is one of its strengths.
Do we know what a #URI denote? Is it an IR or not? Or something-else? 
For instance, what does this URI denotes?

http://dfdf.inesc-id.pt/tr/doc/web-arch/img/fig2#rsc

Just remind you that there are a few mime-type for 
http://dfdf.inesc-id.pt/tr/doc/web-arch/img/fig2 (text/plain, text/html, 
image/svg+xml, image/jpeg, and image/gif).  This is an area that TAG 
hasn't been able to address yet.  But again, it can be consistent if we 
assume that a URI always denote an abstract resource and 
*representation* is what you get.  Hence, #URI can be explained in the 
same way.  What I mean is if we take TBL, the nature of what a #URI 
denotes must be taken into the consideration all together.

Xiaoshu

Received on Tuesday, 8 April 2008 21:31:11 UTC