axiom-math
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-math] documentation and the crystal


From: David MENTRE
Subject: Re: [Axiom-math] documentation and the crystal
Date: Mon, 29 Dec 2003 15:14:36 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Hello Tim and Bill,

You are right, holidays are always a good period to dig into new ideas.

I think I have the same approach as both of you, Tim and Bill. Regarding
the Semantic Web, Bill, I think it is a interesting technology that we
might look at and use as a reference. But for me, it is just a
technology. We need to refine first our own ideas on what we want to not
lose our 30 years goal. That's said, you are right that smart people
have invested time in this technology and it would be stupid of us to
not resuse the wheel.

Tim, regarding your crystal approach, I particularly like it, at least
for the several "facets" to look through one complex system. However, I
would prefer to use a graph-like approach, which in my opinion is
probably more related to the Knowledge Network you have spoken about.

Usually, people have a top-down approach: they modelize a system
abstractly (using more or less formal notations as UML or SDL) and then
refine them through the actual code. But, in the case of Axiom, we need
the reverse. We need to start from concrete objects (files, lines of
source code) and add semantics to climb levels of abstraction. Of
course, you follow different ladders, in the sense that understanding
the compiler or the algebra would need different information and is
structured differently, thus the different crystal facets of Tim.


More concretely, I would propose the following approach:

 1. start from parsers for the src/ directory. Parse directory structure
    and each file, categorize them (boot, lisp, spad, ...) and construct
    basic abstractions (list of lisp and boot functions; list of spad
    categories, domains and operators; ...)

 2. from information extracted in step 1, construct one or several
    representation (knowledge graph for example) with the found
    semantics (name and body of a function for example), probably using
    a standard technology as W3C semantic web

 3. the "Axiom explorer" (Tim, Bill or I) is interested in a specific
    "crystal facet" (e.g. the compiler). He builds another tool
    (e.g. call-graph analyzer for lisp code) which in turn is used to
    construct a new knowledge graph, concretized in additional
    information in the W3C semantic web.

 4. Within the abstraction level build in step 4 (or 2), the "Axiom
    explorer" adds its own knowldege (e.g. this set of functions is used
    to parse Spad code, this other set is used for type analysis, ...)
    to the semantic web.

 5. using previous abstraction levels and probably building a new tool,
    the "Axiom explorer" iterates, climbing abstraction levels, until he
    reaches his own goal.

Repeat steps 1 to 5 with enough people to cover Axiom from A (Algebra)
to Z (zerodim). 

Ok. I might be a bit optimistic and what I have said might appear more
than abstract, but this is the current state of might thoughts. :) 

Even if you do not like above ideas, I think following "principles" are
needed for a documentation system for Axiom (principles already
formulated by Tim is his first email):

 o separation principle: in engineering, people separate a complex issue
   in _independant_ sub-issues to be able to understand them and solve
   them independently. We probably need to deconstruct Axiom in
   independent (or a least loosely connected) sub-systems to be able to
   understand them (i.e. the different crystal facets of Tim);

 o "build on giant shoulders" principle: we need a way to reuse
   knowledge from other "crystal facets". For example, I would use Tim
   knowledge of the internals of Axiom to understand how the compiler
   compiles a given portion of the algebra;

 o automation principle: Axiom is too big to add information manually on
   each function, each object, etc. We need tools to annotate a set of
   objects given a selection criteria (e.g. all operators in this Spad
   domain). 

New year wish: I'll try to write and "show you the code" for above
ideas. :) My own todo for this subproject of Axiom would be:

 - learn more about W3C Semantic Web (thank you Bill for the pointer)

 - find or write tools to manipulate Semantic Web (it might be Emacs
   with a proper mode or a more elaborated graphical tool)

 - apply above approach, starting from directory structure in src/
   directory of Axiom.

 - from this first experiment, think about what would need to be
   "standardized", like common dictionnary or vocabulary, etc. Beyond
   usual technological issues, I think this point is one fo the harder
   point. How to build a set of knowledge that will be still useful in
   30 years from now?



I wish you a pleasant new year.

Yours,
d.

By the way, does anybody knows about a library to *draw* and manipulate
arbitary graphs (in Common Lisp, C++, ML, ...) in a user interface? I
know about DOT or VCG but they dot not match my needs: I would like to
draw a graph, know when the user click on a graph node or edge and react
accordingly. Does anybody know where I could find such an already made
tool? Any knowledge of a browser for the W3C semantic web?

-- 
David MENTRE <address@hidden> -- http://www.nongnu.org/axiom/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]