Re: Mathematica doesn't know what it's doing.
- To: mathgroup at smc.vnet.net
- Subject: [mg67173] Re: [mg67146] Mathematica doesn't know what it's doing.
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Sun, 11 Jun 2006 02:18:03 -0400 (EDT)
- References: <200606100854.EAA01437@smc.vnet.net> <firstname.lastname@example.org>
- Sender: owner-wri-mathgroup at wolfram.com
Please forgive the following ramble: This problem goes far deeper into the realm of cognitive science than I had realized when I first began struggling with it years ago. If I pick up a book on mathematical physics, it appears very organized. Frank W. Warner's _Foundations of Differentiable Manifolds and Lie Groups_ is the paradigm to which I appeal.  The work is arranged hierarchically in a very traditional and universal manner. We can find this structure exhibited in every ancient text of ponderable extent, regardless of the culture which produced it. The structure is that of a tree. It is the same structure that all Mathematica expressions take. In the case of Warner's book, there are elements for which the publishing industry has established codifications applicable to virtually all products called 'books'. Other parts are specific to mathematics, with some overlap into other technical fields. There are theorems, proofs, definitions, examples, lemmas, etc. These are constructed of conceptual units such as paragraphs, ordered lists, numbered expressions, etc. There are rules of containment for these units. That is to say, there are right places and wrong places to put certain things. A list item, for example, must be place in a list. OTOH, several of these block structures can contain substructures permissible for other 'peer' block structures, e.g., a definition is as likely to contain an ordered list as is a theorem, or an example. Though I have never seen examples of this, I have read that the publishing industry has long used a formal system of markup to communicate to the typesetter how a document is organized. With the advent of electronic computers, the publishing industry came up with SGML as an electronic analog. Then came Lord Berners-Lee. Sir Tim took this idea and created HTML - and things have gone downhill ever since. There is now a __ML (not to be confused with SML - which is respectable) for every conceivable area of intellectual activity, with the exception of structuring mathematical publications. These markup languages are codified using DTDs (Document Type Definitions) or other formal meta-metalanguages (AKA schema languages). On Saturday 10 June 2006 07:11, Chris Chiasson wrote: > Instead of trying to make a TheoremBox (first), why not make a symbol > called Theorem that holds the content you want to present. Then you > can add appropriate transformations via Format and MakeBoxes, or > possibly the notation package, to create the appropriate typeset > presentation. If your intent is to separate document _structure_ from _presentation_ , then I congratulate you for having an insight that is both profound and astonishingly uncommon. As for the details, I'm at a loss for the best approach within the framework provided by Mathematica. There seems to be a role for style sheets in all of this. In this aspect Mathematica is like LeX. Containment is implied by ordering, and not state explicitly by bracketing. This is somewhat surprising since all Mathematica expressions are structured by containment. > If you would like to be able to copy/paste the output back to input, > then you will need to use TagBox to embed the semantic meaning into > the output. I have decided that the goal of trying to codify all of my textual presentation in a form that can be input to Mathematica for evaluation is misguided. > Direct input of a theorem could be accomplished by means of a pallet > that will insert the appropriate TagBox(es). All of that is secondary to having the foundational structure. [...] > IMHO, if document processing can be done with XML technology, it > should also be doable in Mathematica. That said, if you build a good > notebook to docbook converter with high quality output of graphics to > pdf, html, xhtml, svg, mathml, etc ... well, let's just say I think > you will have a lot interest from both communities. This is an approach that a lot of people take when it comes to dealing with document structure in various application-specific environments. For example OpenOffice tries to produce DocBook structure from their native structure. This is the wrong approach. The right approach is to base document structure on DocBook - or similar. DocBook itself is overly verbose in areas which are superfluous to mathematics publishing, and lacks features which are essential. Nonetheless, it is a fantastic example of correct use of markup language as it was originally intended. So what is needed? A schema for mathematical publication which is both sufficiently complete to be useful, and sufficiently flexible to be usable. why, oh why, out of the 6,000,000,000+ people on this planet am I the only one who seems to have this vision? The basic idea is not at all complex, and - I believe - it would be extremely useful. It seems to be to be blatantly obvious.  I concede that it is far more of a math than a physics book.  I would very much like to read the book, but alas, I spend my time on the problem currently under discussion.
- Mathematica doesn't know what it's doing.
- From: "Steven T. Hatton" <email@example.com>
- Mathematica doesn't know what it's doing.