Re: Comments on NODAL paper, 14 June 2001 version

[Lee Iverson <leei@ai.sri.com>]

In message <Pine.LNX.4.33.0108082256160.1197-100000@hugh.burdenslanding.org>, E
ugene Eric Kim writes:
>I know this is a very delayed response, but I thought I'd go over Lee's
>stuff and comment on a few things before his talk tomorrow.  In short, I
>agree with Eric's comments, especially his first.  The white paper,
>especially the section on ubiquitous collaboration, is very well done.  I
>think that it should be split up into two white papers -- a conceptual
>whitepaper, and a technical introduction to NODAL.  The first, in turn,
>could be used as a more general whitepaper for the OHS.    (01)

I do agree in the general principle.  What I have found though, is
that unless you get into the technical aspects (at least at some
level), a big part of your audience doesn't *get* the power of the
approach.  It is very hard to sell a "we want to solve everybodies
problems with computer-mediated collaboration" without a fairly
thorough description of how you plan to do that.    (02)

>I have one major question.  The data model, as described in the document,
>seems more focused on defining a data model for storage, rather than a
>data model for addressability.  This is a key difference between NODAL and
>groves.  However, what if you want to specify an alternative data model
>for addressability?  Do you use groves, or is there some mechanism for
>doing this within NODAL?  For that matter, what if you want to define
>alternative data models for storage?    (03)

Actually, it is designed for both.  There is a direct mapping from the
data model to the navigation model to addressability (via paths and
their translations to URIs).    (04)

>For instance, how would you model a raw text document?  If I created a
>schema that represented raw text as a sequence of characters, then I would
>only have one node -- the root node.  However, what if I want to represent
>raw text as a sequence of paragraphs?  In this case, you would have a node
>-- and node ID -- for every paragraph.  Also, under this data model,
>version control would also presumably be more granular.  So what do you
>do?  Do you have two different data models for the same document, and
>store it in two different ways?    (05)

There is a data model for a raw text document provided.  It allows for
a very traditional kind of addressability: line number + character
number.  One thing that is not discussed in the paper is defining the
relationships between data models.  The "raw text" document type you
describe above is a much higher abstraction than the one I've given as
an example.  It demands answers to a number of different questions.
How are paragraphs separated? Is there a separate header and trailer?
If so, what are their formats?  Do we want to address sentences as
well?  What is their format?    (06)

What we're talking about is a quite different document type and data
model.  One way of supporting that kind of addressability would then
be to define a bidirectional, lossless transformation from one to the
other.  A new document (with a different MIME type) can then be entered
into the system such that it shares content with the line-addressed
raw text document.  If we do this right, then an edit on either side
will be properly reflected in the other.    (07)

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