Electronic Notebooks

This page consists of my general ideas on Electronic notebooks and the software tools and research that will be involved in the Cornell proposal to the ASCI program. At the end of this note is list of references to related issues that I have run into.

Data is the basic content of the electronic notebook.Agreements are required to ensure that the data is useful as widely as possible. From a gramatical sense, this data can be viewed as the nouns of our environment. Some issues and alternatives are discussed here. The notebook will also serve as the medium by which researchers collaborate. The individual interactions can be viewed as the verbs of our envirnoment. Agreement is also needed here to ensure that the commands (e.g., solve linear equations, mesh a geometry, compute crack propogation) issued by research group are understandable by others. Some issues related to the verbs are discussed here.

Data representation

A common interchange structure is needed to allow tools to exchange information about geometry, simulation results, mathematical models, experimental set-ups, etc. Among the goals such a representation must possess are:

• It must also be possible to make these representations persistent and to store them in databases.

• The representation should be language independent.

• The representation should be able to cover a very wide range of mathematical and physical concepts.

• It should provide a plausible framework for support of search engines. How do you index experimental/simulation data?

There are two basic approaches that could be pursued. The first is to represent all concepts as objects, and the rely on the interfaces of the objects for all operations. Frame works for this approach include CORBA, DCOM and JavaBeans. CORBA and DCOM provide object sharing schemes that are independent of languages and provide mechanisms for making objects persistent. JavaBeans addresses many of these issues but is only for Java. ILU address many of the object sharing issues, other than persistence and is language independent. All schemes essentially deal with "nouns" and "verbs", both the data structures that need to be shared and the methods that operate on these data data structures. This is the basic object oriented programming model. Ultimately all of these schemes are quite complex due to the complexity of the inter-language differences and increased semantic complexity introduced by having both nouns and verbs in the standard..

An alternative approach is to exchange universal data structures that only represent the nouns of the interchange. This is the approach being taken by the MathBus term structure.

Software Architecture

The activities that will be funded under ASCI will involve researchers from different research groups, from different departments and who may not even be at or associated with Cornell at the same time. At the same time the software that is developed should be used as widely among the Cornell ASCI community as possible to gain the greatest leverage for our efforts. Continuing independently in our software development will ensure that our tools and data (both experimental and computational) are incompatible. At the same time developing a single overarching software architecture and standards will ensure that our effort will be frozen for several years. What is needed is a planning process that while keeping in mind an evolving software architecture vision, will develop useful tools that facilitate adherence to that vision and encourage, where responsible, the development of standards and policies that are consistent with the vision. Issues that should be addressed include:

• Parallelization techniques: Along with the standard need for parallelization tools need to address the fact the platforms the code will need run on will vary widely from ASCI level super-computers through networks of workstation clusters to individual workstations and laptops. It shouldn't be a major effort to move from one platform to another. What networking hardware should be recommended.

• Programming languages and development platforms: What programming languages should be encouraged, what development environments, what database frameworks, what CAD tools, what hardware platforms, etc.

• Software integration: How should modules from different groups be documented, organized, etc, to ensure that researchers in other groups will be able to use them.

• Computational tools: Which mesh generators should be used, linear algebra packages, ODE solvers, finite element packages, geometric modeling tools, etc. best meet the needs our research community and should be used.

Previous work on electronic notebooks

The following list consists of a number of items that I found on the Web. Although they are all related to our interests in electronic notebooks and share some ideas, they are fairly divergent either in scale or flexibility. We probably want to use none of these systems, but ideas from all of them.

A document produced at Cornell some years ago that touches on these ideas is given here.

• Noel Nachtigal's notebook scheme. This is just a plain Web based notebook, with some graphics faciltities. To access this URL us the user ID "guest" and the password "Demo" (case matters) http://www.epm.ornl.gov/~santa/enote/enote.html. Slides from a presentation on these ideas are contained in http://www.epm.ornl.gov/~geist/java/applets/enote/proposal.html.
• The Share project at Stanford focusses more on the collaborative engineering process, but uses the DICE electronic notebook technology http://cdr.stanford.edu/SHARE/cdr-view.html. The active documentation of engineering designs being done by Stanford is documented in http://ksl.stanford.edu/htw/dme/tour/02_Active_Documentation.html .
• For information about DICE efforts see http://www.eit.com/projects/dice/dice.html.
• The MECE notebook technology http://aims.parl.com/MECE/ . This is project being sponsored by Lockheed and is is an authoring environment for mechanical designers so that they can share ongoing design information with collaborators on the network.
• DEDAL is an intelligent tool which uses a representation of the device model for indexing and retrieving multimedia information about the device being designed. It incorporates a methodology for incremental, real time modeling and indexing of design information as it is generated during the design process so that it can be available for retrieval and reuse.
• An Electronic Design Notebook (EDN) has been built in the vmacs(TM) text-graphic editor. The EDN first supports conceptual design by providing AGILITY for initial conceptualizing, and PROCESSING for annotated drawings expressing those concepts. In addition the EDN supplies ORGANIZATION aid to help manage the complexity of design information. Navigation facilities allow the design or manager to constuct a "map" of a design information space indexed by project requirements. Explanation facilities infer the rationale of design decisions notated in notebook pages.
• The GE CE-Toolkit includes electronic notebook and manufacturing database functions.
• There is tha MatLab notebook technology.
• The Virtual Notebook System (VNS) facilitates information acquisition, sharing and management in groups. The VNS allows teams to create shared electronic notebooks upon whose pages they can place text and images and, in certain cases audio and video entities. Members of a team can interconnect the pages of a notebook with navigational links, making the notebook shared hypertext. Additionally special links, called action links, can be used to tie pages of a notebook to external programs. (This looks like it was largely supplanted by the WWW.)
• The LBL electronic notebook is the most interesting. It uses a CORBA frame for everything. Unfotunately it is often difficult to get to their Web pages http://www-itg.lbl.gov/~ssachs/notebook/report.html
• Reticular has a contract to develop an electronic notebook: http://www.reticular.com/PressReleases/Dec-6-94.html. The main issue that they bring to the table is the ability to use voice recognition. This allows the notebook to be used in a hands off fashion by experimentalists.
• In biology, there is the Gene Inspector tool: http://www.textco.com/GIadvantage.html. It is similar to much of what we want to do, but at a smaller scale. I suspect that this effort is too domain specific.
• Pad++ is a TCL toolkit for building Zoomable interfaces. The ideas contained here may be appropriate for dealing with multiscale models of materials.