[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] FW: PARC Forum March 7 - Robert Wilensky

Well yesterday, Doug and I saw Robert Wilensky talk and demonstrate the
"Multivalent Browser Document" (MVD). This technology is under development, based
on an extraordinary Ph.D. Dissertation by Tom Phelps (1998), for the
"open-source" UC Berkeley Digital Library project. Since the results are very
impressive, I thought you'd all like to know more by just downloading the
presentation from their web site.
< http://http.cs.berkeley.edu/~phelps/Multivalent >    (01)

But, since UC Berkeley's web site has been down for many hours (or maybe even
days?) due to a campus-wide power outage, I founded the following info and links:    (02)

"Multivalent documents are designed to be "anytime, anywhere, any type, every way
user improvable digital documents and systems" (Phelps, 1998). Multivalent
documents are constructed as layers, allowing heterogeneous file types to be
brought together into one semantically connected document. Basic document
operations are defined as a set of protocols to allow functionality components,
called behaviors, to act as a seamless unit even if they have been authored
independently. The idea is not to create a new document format that incorporates
all of the myriad file types, but rather to create a small core that can
associate pieces of content with different file types with one another
semantically, and that can call upon specific behaviors dynamically in order to
manipulate those pieces of content while maintaining their place within the
document as a whole."    (03)

Multivalent Documents & Browser Review - platform for new ideas
(Open-source, UC Berkeley style: "You can do anything with it ... but just don't
try suing us.")
< http://www.cs.uwm.edu/classes/cs790/digdoc-f2001/phelps-doceng2001.pdf >
<  http://www.sims.berkeley.edu/~sumeet/cs294c/project/projectreport.doc >    (04)

Multivalent Documents (MVD)
The MVD architecture heralds a document model supporting deep extension to novel
and arbitrary aspects of document functionality, even distributed in situ
<  http://www.cs.uwm.edu/classes/cs790/digdoc-f2001/p82-phelps.pdf >    (05)

“Multivalent Documents: Anytime, Anywhere, Any Type, Every Way User-Improvable
Digital Documents and Systems", Ph.D. Dissertation (1998), Tom Phelps
<  http://www.cs.uwm.edu/classes/cs790/digdoc-f2001/phelps-diss.pdf >    (06)

University and K-12 Educators Collaborating and ...
>    (07)

"The Multivalent Browser (700 KB Java application) is built on an architecture
that separates functionality from concrete document format. Almost all
functionality is made available via relatively small modules of code called
behaviors that programmers can write to extend the core system. Behaviors can be
as significant and powerful as parser-renderers for scanned paper, HTML, or TeX
DVI; as fine-grained as hyperlinks, cookies, and the disabling of menu items; and
as innovative or uncommon as in situ annotations, "lenses", collapsible outline
displays, new GUI widgets, and Robust Hyperlink support. Behaviors can be
combined in arbitrary groups for each individual document, in effect
spontaneously creating a custom browser for every one. Common aspects of document
functionality can be shared, so that, for example, the same behavior that handles
multipage support for scanned paper documents also provides such support for DVI
and PDF; similarly, the behaviors that support fine-grain annotation of HTML also
support identical annotation on scanned paper, UNIX manual pages, DVI, and PDF.    (08)

We have designed and implemented this architecture, and implemented behaviors
that support all of the above functionality and more. Here we describe the
architecture that allows such power and fine-grained access, yet composes
disparate behaviors and resolves their mutual conflicts. ....    (09)

.... "It is a primary goal of the Multivalent project to provide inventors with a
system of sufficient power and fine-grained control that they find it an inviting
platform for working out new ideas. Another goal, equally important, is to enable
distribution of new ideas by not requiring source code changes to the core and by
coordinating possibly conflicting behaviors from diverse parties. To this end, we
have developed an architecture with the following key features:    (010)

   * a document tree core data structure sufficiently flexible to support scanned
     paper, HTML, UNIX manual pages, TeX DVI, PDF, and potentially any other
     concrete digital document format — as well as the system's graphical user
     interface widgets. Cross format support is crucial, for most of us regularly
     deal with many different document formats, such as HTML, PDF, Microsoft
     Word, PowerPoint, email, DVI, and so on, and any work on a system that
     supports just one neglects the other 75%.    (011)

   * a well defined extension mechanism called behaviors, which can implement
     functionality as powerful as a new document format or as fine-grained as
     disabling menu items, all without modification of or special case support
     from the core system a behavior management scheme called hub documents,
     which list behaviors applicable to the system as a whole, various document
     genres, or specific documents, and whose manifestation in effect gives every
     document a custom browser    (012)

   * a framework for open participation by behaviors in high-performance
     low-level communication protocols, which address all aspects of what we term
     the fundamental document lifecycle: restore from disk/network, build data
     structure, format document tree, paint document tree, process keyboard and
     mouse events. Conformance to protocols distinguishes the behavior from other
     object-oriented classes. To a remarkable degree this conformances suffices
     to compose behaviors without conflict.    (013)

   * a framework for high-level semantic events so that logical activities of the
     document are open to participation by arbitrary behaviors, same as for
     low-level events a set of ad hoc communication mechanisms for highly
     specialized needs not addressed above."    (014)

"For example, the following behaviors and tree node types are some of the more
than 150 packaged with the base system:    (015)

   * Media adaptors: scanned paper (two kinds: XDOC and PDA), HTML 3.2 with most
     of CSS1, PDF 1.3, UNIX manual pages (with volume listings), TeX DVI, ASCII,
     Zip files (with extraction), local directories.    (016)

   * Annotations: highlight, hyperlink, floating note, short comment,
     bold/italic/underline/..., font face, font size, foreground/background
     color. Executable Annotations: move text, replace with, bold/italic/
     underline/..., delete, uppercase/lowercase/ capitalize.    (017)

   * Lenses: magnify, show OCR/image, decypher (rot-13, Pig Latin, ...), plain
     view, ruler, bounding boxes.    (018)

   * Tools: table sorting, speed reading, send selection to a web server (as for
     dictionary definition or language translation), telephone touch tone of
     selection, scrollbar search result visualization, slide show, and a novel
     focus+context visualization called Notemarks.    (019)

   * Multivalent-native GUI widgets: button, checkbutton, radiobutton, menu,
     scrollbar, single-line type-in box, multi-line type-in box, frame, dialog.
     Widgets compose, so rather than needing a parallel set of widget buttons to
     function within menus as other widget sets do, the standard button types can
     be used. Likewise, menus can be cascaded and function as both pulldown and
     popup.    (020)

   * Debugging: Live document tree data structure display."    (021)

The architecture is centered around the document as the core unit. So all of the
functionality built into the system either serves to build documents or to
support them in some way.    (022)

The primary data structure for multivalent documents is the document tree. Each
document consists of a document class, which is a tree node. All document content
is also constructed from tree nodes, so that documents and their contents can be
nested inside one another. In addition, the document can contain behavior layers,
implemented as document specific Java classes, a style sheet, and the URL for its
underlying data.    (023)

The graphical user interface is implemented at the document’s top level as nodes
that implement interface features such as buttons and menus, and each document
has a root that communicates events and coordinates screen redrawing with the
browser window, which is defined to the operating system as the container for a
document, its graphical user interface, and any documents that may be nested
within it.    (024)

The leaf nodes of the document tree are responsible for displaying content of
some recognized type, such as images, text strings in UNICODE format, or Java
applets. While documents in HTML or plain text might not require document
specific leaf nodes, other
kinds of documents will define their own leaf types. An example of this would be
a scanned paper image that defines a hybrid image OCR text type.    (025)

The API, along with other developer resources, is available for download at
< http://http.cs.berkeley.edu/~phelps/Multivalent/download.html >    (026)

System Requirements
The Multivalent Browser requires Java 2 v1.3 running under Solaris, Linux,
Macintosh OS X, or Windows.    (027)

Future Directions
Multivalent documents and the multivalent browser are under active development.
In future versions, the researchers hope to improve the handling of distributed
annotations, incorporate new media formats (the complete specification for HTML
4.0, CSS1, QuickTime, Flash, MP3, PDF, SVG, etc.), incorporate native XML display
along with style sheets, and provide full text searching of all document types.
We will integrate the Java Media Framework (JMF) [17] for QuickTime and Flash
support and Netscape's Rhino [10] JavaScript-in-Java implementation, to complete
the Web browsing aspects of the platform.    (028)

We plan to take advantage of media adaptors for manual pages, PDF, and other
document formats to provide access to text for use in constructing a full-text
index, probably implemented by the search engine Lucene [4].    (029)

We eagerly welcome third party developers.    (030)

MVD vs. Mozilla and Other Open Source Projects
As compared to proprietary web browsers, the Mozilla browser [9] seems to offer
inventors an inviting playground in which to execute their ideas. As an Open
Source project, the browser's source code is available for arbitrary changes.
Likewise, Open Source viewers can be found for most but probably not all other
document formats. Several researchers have taken this path, extending NCSA Mosaic
[11] to experiment with annotations in Stanford's ComMentor [16] and advanced
style sheets with Proteus [8], and others have taken advantage of W3C's
experimental browser Amaya [18] for constraint-based style sheets [1].    (031)

But the situation is not ideal. In the first place, retrofitting a feature into
the browser for one document format still neglects all the other document formats
one works with regularly. Moveover, in the case of Mozilla, the system is
enormous: the current version as this writing (v0.9.1) comprises 3817 C++ files
and over 1.6 million lines of code (compared to Multivalent's 287 files and
54,000 lines of code). While it is modularized, there is nevertheless a
significant amount to master before one can work on the new idea — which was the
reason for working with the system in the first place.    (032)

When it comes to the essential point of distribution, Open Source systems are not
necessarily an improvement over closed source.    (033)

Open Source proponents claim that one can simply redistribute the source with
changes, and this can be done. In practice, however, such systems are evolving
and one would want to track new versions, but revising one's changes to match new
mainline source changes is tedious at best. One can contribute the changes back
to the main project developers, but they may not be accepted, especially if they
are of limited applicability or if they are large and thus hard for the main
developers to maintain.    (034)

   * DOM is language neutral. In practice, the language is JavaScript, whose sole
     virtue is that it is the only way to script web pages. As a programming
     language, Java is vastly better designed.    (035)

   * JavaScript can be associated with individual pages, whereas one wants some
     functions to operate on all pages or all pages of some genre. One could
     conceive of running through a proxy server that spliced arbitrary JavaScript
     into all pages, but aside from a decided lack of aesthetic appeal, that’s
     awkward and introduces new security risks.    (036)

   * Since it is difficult to package JavaScript from different sites, it is not
     surprising that there is little thought given to composing the scripts and
     mediating conflicts, a situation which Multivalent has addressed with
     several mechanisms.    (037)

More info
A Survey of Complex Object Technologies for Digital Libraries
< http://techreports.larc.nasa.gov/ltrs/PDF/2001/tm/NASA-2001-tm211426.pdf >    (038)

Excellent list of general readings & references on Digital Libraries and
Distributed Information
< http://www.cs.cornell.edu/Courses/cs502/2002SP/readings.htm >    (039)

E.G., The ABC Ontology and Model
The result is a metadata model with more logically grounded time and entity
semantics. Based
on this model we have been able to build a metadata repository of RDF
descriptions and a search interface which is capable of more sophisticated
queries than less-expressive, object-centric metadata models will allow.
< http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Lagoze/lagoze-final.pdf >    (040)

"John J. Deneen" wrote:    (041)

> I'm planning on attending too. .... any others?
> Eugene Eric Kim wrote:
> > I plan on attending this tonight.  If anyone else from the group is
> > planning on attending, and would like to meet up afterwards for drinks or
> > dinner and discussion, drop me an e-mail.
> >
> > -Eugene
> >
> > --
> > +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
> > |       "Writer's block is a fancy term made up by whiners so they        |
> > +=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+
> ----------------------------------------------------
> Sign Up for NetZero Platinum Today
> Only $9.95 per month!
> http://my.netzero.net/s/signup?r=platinum&refcd=PT97    (042)

Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97    (043)