[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on NODAL paper, 14 June 2001 version



In message <3B3A55F0.200CEF9@eng.sun.com>, Eric Armstrong writes:
>Herewith, my comments.
>
>1. What's there is excellently written. The background section
>   (Ubiquitous Collaboration) was particularly well done, and
>   quite motivating.    (01)

Thank you.    (02)

>2. The document did confuse two important notions:
>      a) Indirect addressing
>      b) Path addressing
>
>   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.
>
>   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.
>
>   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.    (03)

Actually, the document is making a different distinction between a
"grounded" path and one that is not, and I called the difference
"direct" vs. "indirect".  Rather than saying I got them wrong, I'd
rather you suggest an alternative terminology.  In my description, all
addresses are paths, we distinguish between those that include a
"direct" description of their starting node and those that can be
applied to any starting point.    (04)

I agree that a dereferencing operator (for what you call an indirect
address) is an important one, but at this point I limited my
discussion to the "canonical" path operators.  There are many more
that can be introduced later and this one should definitely be included.    (05)

>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)
>
>   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.    (06)

I am assuming that all addresses can be expressed as URIs and
exchanged without ambiguity in this form.  How they are represented
internal to an implementation is, as you say, open.    (07)

>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.    (08)

In a certain respect, this is covered, but only implicitly.  You're
correct that it should be more explicit.    (09)

Since we assume that a legacy document format is
represented as a (MIME type, encoder, decoder) triple, then
pre-existing documents can be read into the repository and then
addressed via the NODAL paths.  I think there may be great advantage
to having a different kind of document type (a specialization
probably) such that the document is explicitly associated with an
external URI and the NODAL representation is simply a cache in the
repository for that document.  In this form, NODAL would essentially
be acting as a WBI kind of middleware component that adds addressing
and reusability of content to the external file.  There are, however,
unresolved issues with version control of an external entity that I'm
not entirely clear on yet.    (010)

>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.
>
>   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").
>
>   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.    (011)

I agree. I've felt the lack of meaty bundling of the two halves in
rereading the paper for myself.  The problem here is one of assumed
audience.  I'm not sure who to target that level of the vision to.
The introduction and technical parts are both pretty general (although
the technical description *is* pretty technical).  I don't want to go
down the path you're describing (with this presentation) because it
almost makes it sound like that knowledge aggregation is the only good
reason to do this.    (012)

This system is designed to be sneaky.  It can be a simple typed,
version-controlled filesystem for people who think they only want
that.  It can be a database backend for a PHP or Perl or JSP web
publishing system.  It can be a subsystem on which to build new
systems for handling online dialogue (starting with email and instant
messaging or chat).  It can be a repository for all kinds of explicit
knowledge infrastructure as you describe it above.  Most importantly,
it can be all of these things *at the same time!* and in such a way
that you can layer on new higher-level representations and
personalities as your social and organizational models demand.    (013)

I think that is kind of the message I want in a conclusion, but I'm
not sure how to get there yet.  Give me a day or two.    (014)

Thanks for the detailed feedback.    (015)

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307    (016)