Re: Fwd: TAG issues during technical plenary

>I received the message below from a member of the new Technical 
>Architecture Group.
>
>I'm thinking of sending a response along the lines of:
>
>I would like the TAG to define the foundations of the architecture 
>of the web.  The concept of a resource is fundamental to web 
>architecture, yet it is very hard to pin down exactly what it means 
>and how it relates to the concepts of URI, URI reference and 
>namespace.  I suggest the TAG publish a W3C recommendation 
>containing a description and a formal model explaining:
>
>   o what is a resource
>   o How URI's relate to resources (e.g. can the same resource
>     be named by more than one URI)
>   o what is named by a URI reference and how does this relate to resources
>   o what is a namespace and how do the names within it relate to URI's and URI
>     references
>   o the operation of the http protocol within the context of this model.
>
>I would welcome comments on the above and other suggestions in 
>response to the TAG's request.  I can respond with either a 
>suggestion from the WG as a whole, or with a collection of 
>suggestions from individual members of the WG.

I agree that these issues need to be addressed, but I would try 
wording the questions a bit more carefully. For example "what is a 
resource?" sounds like an invitation to try one's hand at 
metaphysics, which may be mistake when addressed to the TAG. How 
about making the questions more pointed, along the lines:

What is a 'resource'?

The central term "resource" is nowhere clearly defined, and seems to 
be surrounded by unspoken assumptions and even internal 
contradictions. The commonly used citation (ref RFC2396) seems to 
simultaneously imply a very large scope ("a resource can be anything 
that has an identity", which seems to cover everything in the 
universe, and maybe some things that are not in it, such as unicorns) 
and also a rather restricted scope ("having identified a resource, a 
system may perform a variety of operations on the resource", which 
seems to imply that resources are computable entities that can be 
manipulated by machines.). In fact, it seems to contradict itself in 
several ways, eg in explicitly stating that a resource may be 
something that is not web-accessible, such as a book, but then going 
on to talk of manipulating the resource. It also implies that a 
(singular) resource may retain, or perhaps consist of, an unchanged 
'conceptual mapping' while also changing its 'content', apparently 
assuming an underlying temporal model that is nowhere defined or even 
stated explicitly. In general, the intended nature of "resources" is 
left very vague and ill-defined.

How URIs relate to resources.

Several different kinds of relationship are possible. One is that a 
URI should be thought of as a generic kind of name, and its 
connection to the resource it identifies is like that of other naming 
expressions in logical or natural languages. Another is that a URI is 
a kind of global addressing scheme, which can be used to retrieve 
some computable structure, document or text; this is the older sense 
of URL, of course. Another is that a URI implicitly identifies a 
process which when set in motion will result in some value (which 
might itself be a name or referring expression in the first sense, or 
a document or structure in the second sense) being 'delivered' to the 
'caller', ie as a kind of computational identifier whose value 
reflects the current 'state' of the Web itself. (This latter would be 
one way to make sense of the above-mentioned discussion of 'mapping' 
versus 'content' in RFC2396, for example.) No doubt there are other 
possibilities. Some clarification on which of these are intended 
would be valuable (or even a clear statement that they all can be, 
and that no restriction to one over the other is intended; in which 
case it would also be useful to have some guidance on what kinds of 
relationship are intended among the various possible 
interpretations.) Currently, the 'content languages' being developed 
for web use make overly simple assumptions about URIs, eg  the RDF 
model theory assumes that URIs are logically the same as simple 
names. This is obviously a simplification of the true state of 
affairs; but without some clarification, it is difficult to do any 
better. Progress in making more sophisticated (and hence useful) 
standards is currently blocked by the lack of clarity on these 
central issues.

A more recent document (http://www.w3.org/TR/uri-clarification/) 
unfortunately only adds to the confusion. It notes that a 'classical' 
view partitioned URIs into names (URNs) versus location identifiers 
(URLs), but goes on to describe a 'contemporary' view which fails to 
classify them in any meaningful way. This does not add any clarity to 
the overall framework, however. This document for example states that 
according to the contemporary view,  "a URL is a type of URI that 
identifies a resource via a representation of its primary access 
mechanism (e.g., its network "location"), rather than by some other 
attributes it may have." This seems to imply that the resource *is* 
the document that is retrieved by using the URL (since that is the 
entity that can be said to have a network "location"), rather than 
anything that such a document may indicate or name, such as a book in 
a library (cf. RFC2396).  It also assumes that location is an 
attribute, which raises a number of other questions, including 
whether or not the same entity (resource) might have different 
locations at different times (by changing this attribute).

All these documents leave open a large number of issues connected 
with how to refer to *parts* of a document that has a URI.

For an example of the kind of confusion that results from the lack of 
clear statements in this area, suppose that an RDF document has a URI 
which is used as the subject of an RDF triple in another document. As 
things stand, this might mean that something is being asserted in the 
second document about the first document; about some thing mentioned 
in the document; about the content of the document more generally (eg 
that it implies some other document), about the history or provenance 
of the document, about the current state of the document, or about 
the current content of the document.

Pat

>Brian
>
>
>
>>Dear chairs,
>>
>>The TAG requests your assistance in two matters.  Firstly, the TAG solicits
>>your input on topics that the TAG should address.  The TAG has the charter
>>to publish recommendations on issues.  We believe in surveying a wide
>>spectrum of parties for issues to address, and your help would be
>>appreciated.  Secondly, some members of the TAG also believe that the TAG
>>should provide artifacts/documents that provide context for Recommendations.
>>One example of the context is an architecture document with various text and
>>diagrams.  The TAG solicits your input on what forms of context would be
>>useful to you.
>>
>>The technical plenary agenda [1] has a portion of time for the TAG.  We
>>would like to present information on our documentation deliverables and
>>issues list during the session, so your feedback sufficiently before then
>>would be much appreciated.
>>
>>Cheers,
>>Dave Orchard
>>
>>[1] http://www.w3.org/2001/07/Plenary/Agenda.html


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 22 January 2002 19:04:30 UTC