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

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

What is *really* significant here is that the link to "University and K-12 
Educators Collaborating and ..." from below, lead to the home pages of the 
Interactive University.
where they discuss the Berkeley Open Learning Environment.    (01)

It's going to be very interesting to contrast the Interactive University 
with MIT's Open Knowledge Initiative http://web.mit.edu/oki/    (02)

Imagine a battle of the titans (universities).  Imagine some European and 
Asian learning institutions joining the competition to put OHS-like tools 
"out here".  I can imagine a lot!  It's happening :o)    (03)

Jack    (04)

At 01:19 PM 3/8/2002 -0800, you wrote:
>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 >
>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 
>"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 
>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 
>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."
>Multivalent Documents & Browser Review - platform for new ideas
>(Open-source, UC Berkeley style: "You can do anything with it ... but just 
>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 >
>Multivalent Documents (MVD)
>The MVD architecture heralds a document model supporting deep extension to 
>and arbitrary aspects of document functionality, even distributed in situ
><  http://www.cs.uwm.edu/classes/cs790/digdoc-f2001/p82-phelps.pdf >
>“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 >
>University and K-12 Educators Collaborating and ...
> >
>"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 
>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 
>functionality can be shared, so that, for example, the same behavior that 
>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 
>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. ....
>.... "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 
>platform for working out new ideas. Another goal, equally important, is to 
>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:
>    * 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%.
>    * 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
>    * 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.
>    * 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."
>"For example, the following behaviors and tree node types are some of the more
>than 150 packaged with the base system:
>    * 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, 
>      Zip files (with extraction), local directories.
>    * 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.
>    * Lenses: magnify, show OCR/image, decypher (rot-13, Pig Latin, ...), 
> plain
>      view, ruler, bounding boxes.
>    * 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.
>    * 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.
>    * Debugging: Live document tree data structure display."
>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.
>The primary data structure for multivalent documents is the document tree. 
>document consists of a document class, which is a tree node. All document 
>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 
>implemented as document specific Java classes, a style sheet, and the URL 
>for its
>underlying data.
>The graphical user interface is implemented at the document’s top level as 
>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.
>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.
>The API, along with other developer resources, is available for download at
>< http://http.cs.berkeley.edu/~phelps/Multivalent/download.html >
>System Requirements
>The Multivalent Browser requires Java 2 v1.3 running under Solaris, Linux,
>Macintosh OS X, or Windows.
>Future Directions
>Multivalent documents and the multivalent browser are under active 
>In future versions, the researchers hope to improve the handling of 
>annotations, incorporate new media formats (the complete specification for 
>4.0, CSS1, QuickTime, Flash, MP3, PDF, SVG, etc.), incorporate native XML 
>along with style sheets, and provide full text searching of all document 
>We will integrate the Java Media Framework (JMF) [17] for QuickTime and Flash
>support and Netscape's Rhino [10] JavaScript-in-Java implementation, to 
>the Web browsing aspects of the platform.
>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].
>We eagerly welcome third party developers.
>MVD vs. Mozilla and Other Open Source Projects
>As compared to proprietary web browsers, the Mozilla browser [9] seems to 
>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 
>[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].
>But the situation is not ideal. In the first place, retrofitting a feature 
>the browser for one document format still neglects all the other document 
>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++ 
>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.
>When it comes to the essential point of distribution, Open Source systems 
>are not
>necessarily an improvement over closed source.
>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 
>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.
>    * 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.
>    * 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.
>    * 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.
>More info
>A Survey of Complex Object Technologies for Digital Libraries
>< http://techreports.larc.nasa.gov/ltrs/PDF/2001/tm/NASA-2001-tm211426.pdf >
>Excellent list of general readings & references on Digital Libraries and
>Distributed Information
>< http://www.cs.cornell.edu/Courses/cs502/2002SP/readings.htm >
>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 >
>"John J. Deneen" wrote:
> > 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
>Sign Up for NetZero Platinum Today
>Only $9.95 per month!
>http://my.netzero.net/s/signup?r=platinum&refcd=PT97    (05)