Re: Mike Healy's question about AI and math

Re: Mike Healy's question about AI and math

[zdiskin]

The discussion around the question in Re:above is expired but it seems
not too much was said that might be directly related to problems in the
applied domains in question and, thus, be really understood and
appreciated by  the corresponding part of  the audience. Bill Lawvere is
of course right  in his << strong advice to actually learn some category 
theory, rather than resting content with slinging back and forth 
ill-defined epithets like "set theory", "contingency", etc >> but  still 
there are no King's ways in math,  and learning  CT, as any other rich 
math discipline, needs efforts and time. Well, efforts and time is not a 
problem for students but a working specialist will reasonably require a 
certain motivation and justification for investing his resources into 
CT-studies.

No doubts, the best justification is a host of examples of real 
successful
applications ("success stories"), and in a discussion in this list in 
1997 
few were described. However, the NCDoms (Newly Created Domains as
Lawvere called them) is an enormous territory and a few discrete example
in particular areas do not set enough motivation/justification for the
entire region. What is needed is a representative net of examples but
still
we have no it. So, for a while, a discrete set of new  examples, and
substantial conceptual / theoretical considerations too,  would not be
useless and a few were presented in the discussion. I'm afraid however
that for a non-CT-part of the audience the arguments may seem far  too
general and/or too abstract, and we again come to the same issue at the
beginning of the posting...

There is a general problem of  applying math to engineering domains and, 
correspondingly, of interaction between  mathematicians and engineers. 
The former must respect a lot of formal details (in order to exist, the 
construction has to be formally consistent) and hence must go into the 
depth of consistent formalization. The latter must respect a lot of 
obstacles of the real world (to exist, the construction has to work) and 
hence must go into the width of  functioning in the real world. 
Amalgamation of math depth with engineering width is a non-trivial task 
that needs working out a spacious array of details (every mathematician 
who ever tried to work in an industrial environment knows it) but at the 
end you have some kind of 3D vision beneficial for the both sides. (This 
general opposition "depth vs. width" in the case of "Math vs. NSDs" has 
some quite concrete technical aspects, see below). 

In these terms, an overall picture appeared in the discussion so far is 
somewhat like a discrete collection of  bore-pits (well, they are 
connected at a depth, but it's hardly visible from the surface). To get 
a presentation more relevant for NCDs, I've tried to write a text 
integrating these pits into something wider ("a foundation pit" :). That 
is, I've tried (i) to trace some of the lines appeared in the discussion 
and add a bit of engineering width to them, (ii) to integrate them into 
an observable picture, (iii) to make some details a bit more 
understandable for the "foreign" part of the audience (and probably 
annoying for the "native" part so that my head is on the two platters 
simultaneously), and finally (iv), to explain something for myself.

The resulting text  turned out very bulky and can be found on 
http://www.cs.kuleuven.ac.be/~frank/Diskin.ps
(thanks to Frank Piessens for hospitality).

Below is a brief summary of the text and the table of contents to look
thru before starting, or not starting, the tour.

Regards,
--Zinovy Diskin

 BRIEF SUMMARY   

(I)   OBSERVATION.  In many newly created domains (NCDs)  they deal
with a stuff in much similar to that managed in mathematics. Like a
mathematician, an NCD-specialist deals with design (definition),
presentation and reasoning about structures modeling a piece of reality
(material, informational, "computeral") in an abstract  way, suppressing 
some details (irrelevant for the model)  and explicating others 
(important 
but often residing in intuition / default  assumptions and therefore 
implicit).
Hence,  to look for a suitable math framework(s) for NCDs, one should 
look at *meta*mathematics  -- a part of mathematics  aimed at  modeling
mathematics by mathematical means. 

(II)   OBSERVATION.  Category theory  (CT) is, in essence,  a consistent 
*meta*mathematical framework  where relations, manipulations and 
transformations of / between  math structures are considered in an 
abstract and precise way.  In a sense, CT is a discipline and framework 
for 
mathematical structure engineering.  It is abstract enough to provide an 
extreme flexibility and simultaneously concrete enough to discover CT-
structures in applications in a quite immediate way.  In addition, this 
framework is essentially algebraic (and in some precise sense too), well 
structured itself  and hence is quite manageable and effective. 

(III)  It follows from (I) and (II) that CT appears to be a  good 
candidate  for 
an integral math framework, and effective machinery too,  for 
applications 
in NCDs. Of course, in each particular context suitable CT-patterns 
should 
be found and adjusted, and their match with NCDs-structures to be
managed should be checked. An example (rough sketch) of such an 
activity for the case of software engineering is presented below.

(IV) OBSERVATION: CT vs. SE (software engineering in a wide sense 
including business modeling and knowledge representation). It appears 
that some of major mechanisms invented (and implemented!) in SE to 
manage the complexity of structures involved  -- object orientation, set 
orientation, graphic notations, multi-level system   architectures -- 
are 
based on ideas very close to those developed in CT. To wit: object and 
set 
orientations together appear as a kind of SE-realization of the arrow
thinking underlying CT, and graph-based syntax and multi-level
organization of  the CT-stuff  are evident and speak for themselves.

(V) SPECULATION. While the theoretical part of the NCDs community is
discussing whether CT is relevant or not, the (software) engineering 
part is 
already using categorical, in essence, ideas in a implicit way. Nothing
surprising: the same goal of  building a framework where complex
structures (computational and specificational) could be managed in a 
systematic and effective way has led engineers and mathematicians to 
close results. Making this implicit partnership explicit would benefit 
the
both sides.

END OF SUMMARY  



CT as a mathematical framework for software engineering, AI, cognitive 
science, and other newly created domains (NCDoms).
http://www.cs.kuleuven.ac.be/~frank/Diskin.ps

Table of contents.

1 About  NCDoms.
1.1  NCDoms as mathematics.
1.2. Peculiarities of NCDoms' mathematics: length and width vs. depth.
1.3   SE's mechanisms to manage complex structures.

2 CT in a SE-View: Object-Oriented, Setwise And Graph-Based Mathematics
with Multi-Level Architecture.
2.1 CT as OO-language: Math structures via arrows.
2.2 CT as a setwise language. Toposes.
2.3  CT as a graphic language. Sketches.
2.4  CT as a language for multi-level specifying architectures.

3 CT vs. SE.
3.1  Graphic notation and sketches.
3.2  CT as an integral specification framework.
3.3 Three final remarks.

REFERENCES

Appendix O. MODELING AND MATHEMATICAL MODELING
O.1   General schema of modeling (something by something)
O.2   Examples
O.3  Some peculiarities of applying math to natural sciences
O.3.1. Semi-formal deduction.
O.3.2  "Unreasonable effectiveness".

Appendix A. MECHANISMS FOR MANAGING NCDs' STRUCTURES
A.1 Object  orientation.
A.2  Set orientation.
A.3 Graphic syntax of specification languages: Notational Babylon
A.4 Multi - level specification architectures.
A.5  The challenge of integration.

Appendix B.   ABOUT METAMATHEMATICS
B.0   "Business structure"  of meta-mathematics.
B.1   Metamath I: CatST vs. FrmST.
B.2  Metamath II: CatLogic vs. Tarskian MetaMath.
B.3  Metamath III: abstract mathematical structures engineering.
B.A(ppendix): Bourbakian way of setting math structures and CT.

Appendix C.  CT vs. SE: EXAMPLES
C.1 Relations: Categorical vs. Element-oriented treatment
C.2. Semantic database theory:  Toposes and Database design.
C.3  Whether schema integration is an associative operation?