It helps to get the date and time of the meeting, where it occurred, any agenda,
attendance, and action items, if available. This takes extra time, but is
helpful for context.
Otherwise, great notes.
Eric Armstrong wrote:
> In a continuation of Saturday's meeting, Ken Holman
> met again with several members of the OHS design
> As a result of that meeting, the design focus is
> shifting away from "lets transcode every document into a
> common XML form" and towards "lets define the functional
> interfaces and only after that is done done figure out
> what XML is needed for data interchange."
> As part of that shift, rather than conceptualizing the
> OHS as XML-versions of documents, we're thinking of it
> as a repository that contains pointers to legacy-documents
> plus whatever additional data is required to provide OHS
> This focus strikes me as very promising. The strategy
> wins on several levels:
> 1. As Ken mentioned, it allows others to differentiate
> and innovate on the implementation, using different
> internal representations to provide the requisite
> functionality in a way that preserves interoperability.
> 2. It lets us think in terms of defining an abstract
> "viewer" for legacy documents. (E.g. word documents
> spreadsheets, diagrams, etc.) People who are close
> to those formats can build specific viewers, while
> the OHS provides a common ground for the additional
> data necessary to use them effectively.
> 3. As more interesting views are constructued, they are
> stored in the OHS. Over time, the OHS becomes more
> and more central, and legacy documents become
> secondary, the OHS therefore grows "organically" from
> its legacy-document beginnings.
> 4. As we discovered at Tuesday's meeting, the process
> of defining the requisite functionality and structures
> is tantamount to a specification (or anthropolical
> rediscovery) of Augment's "ontology". (It turns out
> that the "ontology" defines the functional interactions,
> as well as an abstraction-tree that leads naturally
> to an object hierarchy.) Casting the problem in these
> terms lets us use our ontology gurus (Jack and Howard)
> to advantage. They intend to start mining Augment
> documents in order to extract that ontology. (Eugene
> will use his Augment to HTML converter to make sure
> they get what they need.)
> Ken also pointed us towards a better use of the terms
> "HyperScope", "HyperDocument", and "OHS". He intuitively
> (mis)undestood them to mean the viewing engine (HyperScope),
> the repository (OHS), and the thing viewed (HyperDocument).
> The original meanings of the terms had been something more
> along the lines of HyperScope is a mini-OHS that works
> with legacy documents, while the OHS was the full monty,
> or words to that effect. But the meanings that the terms
> intrinsically suggested to Ken make a lot of sense. They
> suggest an appropriate division into viewers, entities, and
> And rather than having a "HyperScope" that one day
> evolves into a "OHS" (how do we know when it has happened?)
> we have both a HyperScope and an OHS on day one -- where the
> OHS starts small and grows larger, containing more flavors
> of HyperDocuments over time.
> At the moment, we seem to have factored the problem in a way
> that lets everyone bring their skills to bear simultaneously
> on different aspects of the problem. Odds are good that
> we'll be able to continue down this road for awhile, and
> potentially make substantial progress as a result.
> eGroups Sponsor
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-IIfirstname.lastname@example.org
> Unsubscribe: unrev-IIemail@example.com
> List owner: unrev-IIfirstname.lastname@example.org
> Shortcut URL to this page:
-------------------------- eGroups Sponsor -------------------------~-~>
It's Easy. It's Fun. Best of All, it's Free!
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Sat Nov 18 2000 - 23:48:01 PST