Re: comments on Web Architecture First Edition

>Pat,
>
>With reference to:
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2004Mar/0016.html
>
>At 16:38 17/03/04 -0600, Pat Hayes wrote:
>>The following are some personal comments on 
>>http://www.w3.org/TR/2003/WD-webarch-20031209/
>
>[...]
>
>It's difficult not to be overwhelmed by your missive.  I think it 
>raises many important points, but I'd be concerned that an attempt 
>to follow the detailed recommendations proposed without some 
>broader-level initiative could lead to a document that fails to 
>educate any of its intended audience.

Why? All I'm asking for is a few clarifications of the terms used; as 
I said, it could be done by adding a glossary. I would offer to try 
to write some of the entries, except that I don't know what it is 
that the authors are trying to say.

The reason it comes out as rather overwhelming is that Ive asked for 
this before, several times, and to my surprise the request has met 
with strong opposition; so I felt it was important to explain what 
*I* meant as clearly and unambiguously as I could, and to document in 
detail why I think it is important to get the meanings clear.

>
>I found the explicit distinction between the terminology surrounding 
>Computational (C) and Descriptive (D) languages was very helpful in 
>drawing out the problem areas.  I'd like to pursue this line a 
>little.
>
>Historically, the World Wide Web has been a computational system 
>(notwithstanding the semantic aspects that were apparently part of 
>TimBL's early vision), and the language with which it has been 
>described draws upon computational terminology, and did not cause 
>any obvious conflicts.  But with emergence of the Semantic Web comes 
>a need to also use descriptive terminology.  It seems that the 
>confusion we face is needing language to describe a system that is 
>both computational and descriptive.

Right. More particularly the problem I see is that the same 
terminology is being used in more than one sense. I think we have 
enough *ideas* to do the explaining adequately, as long as we can be 
clear about what we are intending to say.

>Further, it seems to me that the vast majority of people who build 
>software for the WWW have a distinctly computational bias.  It seems 
>it is a very small minority who have any real understanding of the 
>implications of the descriptive approach (I think the model theory 
>document goes a long way to explain these issues, but it still takes 
>a great effort of understanding for someone steeped in computation 
>to "get it").
>
>It now seems to me that this combination of computation and 
>description is somehow right at the heart of Web architecture, and 
>needs to be elucidated.  Especially for the armies of software 
>developers, steeped in computational understandings, who write the 
>software that makes the Web a reality.  This is, I think, a 
>non-trivial challenge of education.
>
>I find myself wondering if Roy Fielding's REST architecture can be 
>seen as an early attempt to bridge this gap, at least for 
>computational artifacts that have a concept of state.  But there 
>remain holes, especially in the articulation of resources.  How well 
>would REST fare if Resources were cast as those things (anything) 
>that can have a formal description (ala RDF, or KIF), and some 
>mediating abstraction used to be the computational thing that has a 
>state whose data-representation can be presented on the web? 
>(Hmmm... This starts to sound like TimBL on 
>http://www.w3.org/2001/tag/issues.html#httpRange-14 and fragments, I 
>think.)

It seems clear that the original usage of "resource" was the C sense. 
That is what the early hypertext folk were talking about, for 
example.  (Hypertext is text with access-providing links in it, not 
text which merely refers to other text: that's been around ever since 
the first critical essay was written. ) At some point a few years 
ago, some of the W3C mavens decided that they didnt want to limit 
themselves to talking only about hypertexts or webpages or whatever 
they had been talking about up to then, because the WWW was already 
going beyond that with new MIME types and so on, and so they tried to 
re-state the ideas on a broader canvas, using terminology which 
allowed, as it were, for future expansion. I think that REST is a 
very impressive piece of work on these lines which clearly has that 
intent, to describe the essentials of the Web architecture without 
limiting itself to any particular stage in the Web evolution.  All of 
which is fine, except that the terminology that got used already had 
an established meaning; and even that would be OK, in fact, as long 
as the context of use clearly distinguished these 
Internet-Web-Architecture uses from the established uses: after all, 
many terms are re-used in several disciplines. The real problem 
however is that this other, older, usage has now become technically 
relevant to the Web itself. So now now there is a real need to 
disentangle the terminology used in the various senses.

It seems to me that REST is just fine, as long as the terminology it 
uses is understood properly: in particular, as long as one 
understands its use of 'representation' in a special way, different 
from the logical-semantics sense.

>Maybe the biggest challenge is to find appropriately distinguished 
>terminology that allows us to talk about computational and 
>descriptive matters in the same sentence?

See below.

>Is there anything here that could be summarized in a couple of 
>pages, and which might provide a skeleton around which to arrange 
>the remaining aspects of the Web architecture descriptions?

Well, I did make a tentative suggestion, which was to distinguish the 
two senses by a choice of vocabulary. My own preferences would be 
something like this:

Distinguish resource (D) from web resource (C); or possibly, use a 
more conventional terminology by using 'entity' rather than 
'resource' for anything referred to (D) and reserve 'resource' for 
the C sense;

Distinguish 'refer'  (reference, etc) (D) from 'identify' (C). This 
conforms with established usage in linguistic and logical semantics, 
and in programming language terminology, respectively. Then for 
example one of the current debates about 'bare URI' meanings in RDF 
could be characterized as a debate about the relationship between 
reference and identification of such URIs, and Tim BL's position 
could be characterized as the view that reference should not diverge 
from identification when there is something identified, so that the 
(undisputed, architecture-mandated) thing identified by (identifyee?) 
a URL, ie a web resource located by HTTP protocols, should be 
required to be the referent of that URL when it is used to refer 
(sense D). This way of expressing the matter clarifies the issues 
somewhat, it seems to me. I would anticipate that most of the 
document would be about identification rather than reference, which 
seems quite appropriate for an architectural description.

Is that any help?

Pat


>
>#g
>
>
>------------
>Graham Klyne
>For email:
>http://www.ninebynine.org/#Contact


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 19 March 2004 12:58:42 UTC