Re: comments on Web Architecture First Edition

>On Wed, 2004-05-05 at 15:00, Pat Hayes wrote:
>>  > On Wed, 2004-03-17 at 16:38, Pat Hayes wrote:
>[...]
>>  > > Which could be paraphrased as "A resource can be anything, and
>>  > > everything is a resource".
>>  >
>>  > yes, quite.
>>
>>
>>  Well, then, it is hard to resist asking the question, why did y'all
>>  feel obliged to (mis)-use a word when there already were perfectly
>>  good words you could have used, such as "entity" or even the plainer
>>  "thing" ?
>
>Fair question...
>
>The term 'resource' was chosen as the universal set in web developer
>discussions so old that I can't even find the archives.
>The usage goes back to at least 1994, with
>discussion of URLs, URIs, and even URCs (a precursor to RDF).
>   http://lists.w3.org/Archives/Public/uri/1994Dec/
>
>The XLink spec followed suit, to some extent:
>
>[[
>The notion of resources is universal to the World Wide Web. [Definition:
>As discussed in [IETF RFC 2396], a resource is any addressable unit of
>information or service.] Examples include files, images, documents,
>programs, and query results.
>]]
>  -- http://www.w3.org/TR/xlink/#N789
>
>I suppose that just re-raises the question of whether 'resource'
>is the universal set or something smaller.

Seems pretty clear to me that it is much smaller, by that term 
'addressable unit'. Most things in heaven and earth are not 
addressable units of anything.

That definition makes sense. It is clearly the C sense in my C/D 
contrast, and it fits with the now venerable discussions of 
hyperlinking in Engelbart's stuff, cited in the architecture 
document. So why not just stick with that? Then it all makes perfect 
sense as an architecture document. All you need to do is elide or 
modify the few places where the text goes off on some kind of riff 
about resources being anything and everything being a resource. None 
of these have any bearing on the technical content of the document in 
any case: everybody knows you can't send a book or a galaxy (or the 
weather in Oaxaca) over a network, in fact, so who are y'all trying 
to kid?

>I suppose we could choose 'thing' as the universal set, but that
>would be a pretty major educational undertaking in at least some
>communities. Maybe those communities are smaller than the ones
>that use 'resource' as the universal set.

Well, re-education is better than confusion. I don't think, frankly, 
that "resource" was EVER supposed to mean the universal set. I'm not 
sure now where the historical roots of that idea come from, but they 
can't be found in the older material anywhere Ive looked.  For 
example, with the understanding of "resource"  outlined in the Xlink 
spec and the 1994 discussions you cite, which notably seem to think 
of the Web as a kind of world-wide *library* , that choice of word 
makes perfect sense: the things in a library, even an extended 
world-wide hyperlinked electronic library, can indeed be reasonably 
thought of as resources, things that are accessible for use, things 
that provide functionality. The mistake arises when the library is 
identified with the entire universe.

But OK, if you really want "resource" to mean the universal set, now, 
then please say so very clearly and explicitly, but then read over 
the document with that meaning in mind very critically, because with 
that reading, much of what it says about resources really does not 
make sense. You can't send weather over a network; grains of sand 
don't have (or need) URIs, most resources have no owners, etc..

[later]

Maybe I have found the source.

A bit more reading found this, 
http://ftp.ics.uci.edu/pub/ietf/uri/rfc1737.txt  written by Sollins & 
Masinter in Dec 1994, defining the URN idea and possibly one source 
of this confusion that I am trying to root out. It has some nice 
prose in it, let me number the sections for later comment:

1.
The requirements for Uniform Resource Names fit within the overall 
architecture of Uniform Resource Identification.  In order to build 
applications in the most general case, the user must be able to 
discover and identify the information, objects, or what we will call 
in this architecture resources, on which the application is to 
operate. Beyond this statement, the URI architecture does not define 
"resource."
2.
  A URN identifies a resource or
    unit of information.  It may identify, for example, intellectual
    content, a particular presentation of intellectual content, or
    whatever a name assignment authority determines is a distinctly
    namable entity.  A URL identifies the location or a container for an
    instance of a resource identified by a URN. The resource identified
    by a URN may reside in one or more locations at any given time, may
    move, or may not be available at all.  Of course, not all resources
    will move during their lifetimes, and not all resources, although
    identifiable and identified by a URN will be instantiated at any
    given time.  As such a URL is identifying a place where a resource
    may reside, or a container, as distinct from the resource itself
    identified by the URN.
3.
  Requirements for functional capabilities

    These are the requirements for URNs' functional capabilities:

    o Global scope: A URN is a name with global scope which does not
      imply a location.  It has the same meaning everywhere.

    o Global uniqueness: The same URN will never be assigned to two
      different resources.

    o Persistence: It is intended that the lifetime of a URN be
      permanent.  That is, the URN will be globally unique forever, and
      may well be used as a reference to a resource well beyond the
      lifetime of the resource it identifies or of any naming authority
      involved in the assignment of its name.

    o Scalability: URNs can be assigned to any resource that might
      conceivably be available on the network, for hundreds of years.
....

4.
    One of the ways in which naming authorities, the assigners of names,
    may choose to make themselves distinctive is by the algorithms by
    which they distinguish or do not distinguish resources from each
    other.  For example, a publisher may choose to distinguish among
    multiple printings of a book, in which minor spelling and
    typographical mistakes have been made, but a library may prefer not
    to make that distinction.  Furthermore, no one algorithm for testing
    for equality is likely to applicable to all sorts of information.
    For example, an algorithm based on testing the equality of two books
    is unlikely to be useful when testing the equality of two
    spreadsheets.  Thus, although this document requires that any
    particular naming authority use one algorithm for determining whether
    two resources it is comparing are the same or different, each naming
    authority can use a different such algorithm and a naming authority
    may restrict the set of resources it chooses to identify in any way
    at all.

Now, let me chew on this for a while. I claim that (1) makes sense 
only under the C reading, since it refers to resources as things on 
which *applications* can *operate*. You cannot operate on Santa 
Clause or unborn children or remote galaxies or sodium atoms, or 
indeed on the weather in Oaxaca, unless maybe you have a fleet of 
cloud-seeding aircraft. So "object" here must be understood as 
referring to a computational sense of "object", rather than entities 
in general: things that (have an identity, but) can be stored in RAM, 
sent over network connections, manipulated by software, tested for 
equality under various criteria defined by methods inherited from 
their defining class, etc.. These may well be objects in the sense of 
"object" used in OOP, for example, but this is still a very small 
(and highly special) subset of the universe of possible objects in 
the broader, non-computational sense.

(That last sentence, BTW, seems to be an early example of the almost 
obsessive stonewalling that the TAG group insists on doing when asked 
to define its terminology. Do y'all think that there is some actual 
intellectual merit in refusing to say what you mean in this way? 
Maybe it makes it all feel more like pure mathematics, or something?)

Let me use 'computational object' , or CO, for what this paragraph 
seems to be talking about, and 'object' more generally for, well, 
anything in or under heaven.

The wording of (2) starts to get weird. We could take it either way. 
It would be fine for URNs to be able to name anything, not just COs, 
of course: sure, names can name anything. But for most nameable 
things, the idea of their having an address, aka container, is 
strange, to put it mildly: in many cases it isn't even coherent. (I 
take it that this means 'address' as in location in memory or file 
system, not like 'street address': but its a damned odd thing to say 
in either sense about most things in the universe.) So this focus on 
things changing their address or being moved from place to place 
seems to be an implicit restriction of the topic to COs. And then 
there is that curious remark about 'instances' of resources. What can 
that possibly mean? Many of things we talk about are already concrete 
particulars, which have no instances: what would be an 'instance' of, 
say, you or me, or of the great nebula in Orion? But for COs it does 
have a way of being interpreted in many cases, since COs are often 
thought of as instances of a computational definition or 
specification (the basic intuition underlying the OOP model in many 
cases, where identity is determined by the class which provides the 
'methods' of manipulation.) So again, if this means anything then it 
seems to mean something in the context of COs rather than objects 
more generally.

Turning to (3), this could at first be read in either sense, though 
read in the wider, D, sense it seems almost insanely ambitious (there 
shall be only One true Name for any object for Ever and Ever... 
sounds like something from the Wizard of Earthsea) until you get to 
the fourth condition, which refers to resources being "available on 
the network". I can make sense of this only if "resource" is 
understood in the computational C sense: things like galaxies are 
not, in  my experience, usually available on networks. Certainly the 
things that my OWL quantifiers range over are not all on a network, 
in any sense of 'on' and 'network' that I can understand: for 
example, they may never (ever) have a identifier. But I don't think 
that this is what the authors intended.

Section (4), from later in the document, seems to me to be muddled. 
Is it talking about criteria for identity or about *algorithms* for 
determining identity? The text uses the latter terminology but the 
examples only make sense in the former. In the usual sense of 
equality used outside computer science, the idea of an algorithm for 
testing for equality is incoherent: equality simply means being the 
same thing. (What kind of algorithm could test me for equality with 
myself? What would need to be tested? Here I am, and there is one of 
me: what else needs to be said or done?) This whole discussion makes 
sense only if one thinks of the actual world as being a kind of 
algebraic object, like a giant datastructure, whose pieces look 
different depending on which category you think of them as belonging 
to. This is a fatal muddling of reality with description, a confusing 
of the map with the territory, of the model with the modelled.

I think I see what the authors are getting at: the concept of 'book' 
can be interpreted as meaning an abstraction of the actual world at 
different levels: physical objects on a shelf, print runs, editions, 
manuscripts, etc., all might be called "a book" and might have 
systematic identifiers assigned to them by various naming 
authorities: yes, indeed. But this only translates into criteria for 
*identity* if one thinks of these abstractions as *being* the 
reality: and that is a fatal slip, like identifying mathematical 
abstractions with the reality that they might model, or the Platonic 
world of ideals with the actual world of concrete referents, or (as I 
think in this case) the computational descriptions of something with 
the things described. And once that mistaken identification is made, 
it seems trivial to identify reference with linking, and naming with 
access. The whole world now seems to be made of the stuff that is 
sent over network links and processed by applications running on 
computers.

>As to 'entity'... the web specs (MIME, HTTP) use "entity" to mean
>a generalization of the RFC822 header/body structure.

So they do. Sigh.  OK, so just say 'thing'.  Plain language is 
usually best in any case.

>"entity
>         The information transferred as the payload of a request or
>         response."
>   -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1
>
>Hmm... that spec seems to use 'resource' for something smaller
>than the universal set...
>
>"resource
>         A network data object or service that can be identified by a
>         URI, as defined in section 3.2."

You omitted the next sentence, which is even more telling:

"Resources may be available in multiple representations (e.g. 
multiple languages, data formats, size, and resolutions) or vary in 
other ways."


>then in 3.2:
>
>"As far as HTTP is concerned, Uniform Resource Identifiers are simply
>formatted strings which identify--via name, location, or any other
>characteristic--a resource."
>

This is the familiar circular recursion that one finds in so many of 
the W3C glossaries. Foodles are whatever are identified by bazzies, 
and bazzies identify foodles. Thanks, that is SO helpful :-)

Pat

>[... much elided ...]
>
>--
>Dan Connolly, W3C http://www.w3.org/People/Connolly/
>see you at the WWW2004 in NY 17-22 May?


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