Comments on NODAL paper, 14 June 2001 version

[Eric Armstrong <eric.armstrong@eng.sun.com>]

Herewith, my comments.    (01)

1. What's there is excellently written. The background section
   (Ubiquitous Collaboration) was particularly well done, and
   quite motivating.    (02)

2. The document did confuse two important notions:
      a) Indirect addressing
      b) Path addressing    (03)

   An indirect address points to a location which contains an
   address. That provides a single point of change, so that
   an item can change it's address, and everyone who depends
   on it unknowingly uses the new address, rather than the 
   old. This kind of addressing is highly valuable, and 
   frequently desirable.    (04)

   A URI is a great example of an indirect address. (It's an
   index, really, but it functions in much the same way.) You
   use the URI to look up the address. That way, the address
   can change (be a local copy, for example) without modifying
   the document that references the targeted item.    (05)

   What was described in NODAL as indirect addressing was, in
   reality, path-addressing -- an equally valuable form of
   addressing that defines a path from one node to another.    (06)

3. Given the liklihood that true indirect addressing will be
   desirable (it was in NLS/Augment), that leaves open the
   distinct possiblity that NODAL needs either:
     a) an Address data type, or
     b) an Address node (which contains an address)    (07)

   Now, it could be that the atomic NAME type would qualify
   as an Address data type. But that would require that all
   address are represented as URIs. I suspect that different
   implementations will want to vary on how they construct
   internal addresses. On the other hand, allowing each
   implementation to provide its own unique Address poses
   interoperability problems. So I suspect that the notion of
   an Address does need to be formally defined.    (08)

4. One thing I never really saw in the document was the notion
   of addressing into an existing document! I believe NODAL
   started out as a improvment on Groves. And my limited
   understanding of Groves leads me to conceptualize it as an
   addressing mechanism that adds granular addressing to 
   a specified document type. At this point, NODAL seems to have
   evolved into an abstract data model, which is also a good
   thing. But I no longer see the connection between it and
   Groves -- or at least, I didn't see it in the paper.    (09)

5. The exposition of the grand vision is extremely well done.
   The description of the storage repository is similarly 
   detailed and thorough, with IDL and lots of information.
   But, in between, there is a huge, gaping hole. What is
   needed to "fill the void" is a depiction of the kind of
   architectures that are expected to use NODAL -- for 
   example, a protocol-based, web-accessible repository, or
   peer-to-peer programs that interact via proxies.    (010)

   In general, the architectural issues are those of knowledge
   insertion and extraction (adding and retrieving knowledge
   via some interface), as well as knowledge navigation and
   representation (finding and storing knowledge). There are
   also related issues of knowledge reduction (collapsing
   redundant information) and elimination (throwing away
   useless or inaccurate "knowledge").    (011)

   In other words, what kinds of architectures have the ability
   to solve the grand problems posed in the first section, and
   how might they take advantage of NODAL?? Some plausible
   hand-waving is needed here to connect the two visions.    (012)