[Axiom-mail] Re: [Axiom-developer] ADVI browser

[root]

David,

I might as well bore you with my long-term thoughts about pamphlets.

If you do the ADVI browser think of it as the front end to a new kind
of automated book. The browser is intended as a viewer for the dvi
files generated from pamphlets. (Ideally the browser would handle the
dvi generation from the pamphlets but you can assume that's been done)
But the pile of pamphlets will eventually provide an N-dimensional
matrix of information. We want to support at least 7 different views
off the same data in this big pamphlet matrix:

View 1 is a top-to-bottom path. At the top you start with a technical
paper that provides the mathematical description. For example, looking
at the area of integration starting with Barry Trager's Ph.D. thesis.
>From there you eventually work your way down to executable code. Thus
you move from theory to practice.

View 2 is a side-to-side path. Here you are staying at the same level
of abstraction. You would be exploring, for example, all of the matrix
capabilities provided by Axiom by looking at the mathematics of each one.
Or looking at the implementation of each one.

View 3, unlike View 1 and 2 which remain within the text area of the 
pamphlet files, would wander among the code area of the files, say, 
finding the pamphlet which contains the source code of a function 
called from the current pamphlet.

View 4 is a "threaded walk". ADVI allows embedded graphics and active
terminals. View 4 is intended to allow professors to develop course-related
paths thru the pamphlets.  A particular course, say commutative algebra,
could develop a "textbook" which visits subsections of pamphlet files
in a particular order. This would also be used to construct further
pamphlet files. These will also contain embeded active graphics for
explaining things in class.

View 5 is a "slide show" kind of presentation intended for classroom
or lecture use. This would visit code, pop up graphics and active
windows (hence use ADVI), etc so you could give a lecture using Axiom
within the slides.

View 6 follows "document structure" information such as following 
bibligraphic references to other pamphlets or combining index information
for cross-reference purposes. In general the browser will end up doing
searches (e.g. looking for the pamphlet containing a function for View 3)
and caching the results (e.g. building a file-based hashtable of 
function->pamphlet cross-references).

View 7 is a "concept map" form. This is the hardest to do as it
requires input from the user to construct. There is technology
available from the early 90s called KREP (Eric Mays's Knowledge
Representation) which, combined with OPS5 (Charles Forgy's thesis work
on rule based programming) forms a system called KROPS (my research
work at IBM). KROPS is a ( concept graph / rule graph ) that 
automatically classifies "concepts" based on subsumption. It "learns" 
as you add concepts to the graph. The long term use of this in Axiom 
is intended to support the ability to "shape" the pamphlet files matrix 
based on the understanding of the user of the system.  

There will be a large amount of mathematics in the pamphlet pile. We
need to control the complexity. So the idea is to watch what the user
visits and "learn" what he already knows. This gets added to a
"concept graph".  The "concept graph" of a linear algebra professor
would differ greatly from the concept graph of a group theory
professor. This learned information feeds rules to drive the
presentation of information. Note that this functionality is "a long
way off". However you can see that the "30 year view" of Axiom's
mathematics is somewhat beyond what is available today (but barely
uses the technology available in the 1990s. sigh).

So, in general, the pamphlet file is not intended to be a monolithic object.
It is rather a sequence of chunks, subsections, and references that can be
visited and recombined at will.

There needs to be some sort of a "construction" support which will record
visited or needed links into some sort of a tree structure. Think of it as
a method of dynamically constructing a book by ripping out sections of
other books, adding your own notes, and combining them to form another
booklet. It's the "big staple" method of construction. Take a bunch of
existing subsections and chunks and "staple" them together. This is
different from the standard "back button history" trace because you 
indicate things you want to keep and re-arrange. Ideally this would "save"
as a booklet file format for later hand-editing. Using this mechanism
authors can build on previous work and professors can construct class
notes from existing work.

Initially I don't expect any of these views to be supported. All we need
in the beginning is some sort of a book-like front end. The "top level"
file will just be a pamphlet file that is a table-of-contents containing
"pamphlet" chunks using the "booklet" function you created:

This is the first chapter
<<pamphlet:src/doc/first.pamphlet>>
This is the second chapter
<<dvi:src/doc/second.dvi>>
...

I laid out the various views to give you some idea of the needed
generality in the long term.

Tim
address@hidden
address@hidden