Virtually all notations are Incomplete Notations because they tend to address a limited domain such as algebra, calculus, plane geometry, various programming languages -- especially those that are focused on a particular domain like Cobol or APL ... the list goes on and on.
The closest thing that human beings have to a complete notation is natural language and its textual counterpart. It will be interesting as computers become ever more powerful, whether we can capture cognitive acts in a sufficiently universal manner to allow computers to think -- then we will have a CompleteNotation? perhaps. --RaySchneider
How does this related to TuringCompleteness? -- DaveHarris
If we can teach a TuringMachine to think, then it would suggest that a TuringComplete language is actually a CompleteNotation?. However, since the TuringMachine was AlanTuring's response to the Entscheidungsproblem, whose purpose was to prove that a TuringMachine is a necessarily incomplete symbolic system, we already know something's amiss. Also, all formal systems are incomplete as KurtGoedel proved in his answer to the Entscheidungsproblem. (See GoedelsIncompletenessTheorem)
Aren't all forms of modelling exercises in abstraction? If we employed no abstraction there would be no distinction between the model and the subject being modelled. All models are therefore incomplete when compared with their subjects? (otherwise they are their subjects.)
We choose what to ignore - for example Ohms law is a useful modelling abstraction in physics, despite the fact it can't cope with non ohmic conductors and changing temperatures. If the temperature doesn't change significantly and you have only ohmic conductors in your problem domain, you don't care about the incompleteness of Ohms' law.
There is also the notion that any sufficiently complete model can stand in for the real thing. This is especially true of software where organizations, such as Rational, go to great pains to stress the difference between VisualModeling and VisualProgramming, since there is some blurred distinction between the two. The creators of some notations (most notably, Shlaer-Mellor) actually advertise that you can create models that are complete enough to faithfully generate the systems being modeled, while others (like the UML) deliberate go after system abstraction and don't try to precisely replicate the underlying semantics of the target environments. -- DionHinchcliffe
Here is a quick reminder, just to clear up speculations :
1. Godel's solution to Hilbert's problem relates to truth. Basically, he proved that truth of a Language (I think your concept of Notation is close enough) belonged to a stronger one. Logicians talk about completeness, for this designates a Notation that can generate only statements that we KNOW are true or false. In extenso, that we are sure as hell in a complete language that there are no statements we don't know nothing about. If this sounds metaphysic to you, then you can understand Turing's motivation.
2. Turing's solution relates to decidability. Basically, he proved that even the strongest machine of its class (the class of the ones that reads, writes, moves or stops) would not be able to determine the result of every proposition of some strong language. For we aren't sure that this machine would stop for every problem it is set to CALCULATE, if mathematical problems could be translated into arithmetical ones.
3. This just put a stop to the formalist dream of Hilbert : reducing maths to purely formal means, there is at least two big problems : truth and decidability.
4. A very basic notation could still be complete and decidable. Godel and Turing examined Notations that could include arithmetics. In fact, Godel proved that some are complete. So to say that all notations are incomplete is just untrue.
I am not saying this to put a stop to all the analogies and metaphores I've read so far. Just a quick note to reorient your pattern-mongering, aside lamenting the resurfacing formalism latent into "patternalism".
(BTW, this site is just amazing! I was looking for a few methodology tips and found plenty!)
Benoit St-Pierre Universit� du Qu�bec � Montr�al benoitstpierre@internet.uqam.ca