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.
http://interactiveu.berkeley.edu:8000/iu/
and
http://interactiveu.berkeley.edu:8000/newIU/
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)
Cheers
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
>links:
>
>"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."
>
>
>REFERENCES & ABSTRACTS
>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 >
>
>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
>annotation.
>< 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 ...
><
>http://interactiveu.berkeley.edu:8000/newIU/Filer/filetree/techpapers/yee_y
>oes_iu_ole_2001_08_31.pdf
> >
>
>"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.
>
>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
>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:
>
> * 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,
> ASCII,
> 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."
>
>MVD-Architecture
>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.
>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.
>
>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.
>
>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.
>
>MVD-API
>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
>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.
>
>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
>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].
>
>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.
>
>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
>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.
>
> * 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)