comp.lang.ada
 help / color / mirror / Atom feed
From: brbarkstrom@gmail.com
Subject: Re: ANN: Introducing AdaBase - Thick database bindings for Ada
Date: Sun, 22 May 2016 08:06:15 -0700 (PDT)
Date: 2016-05-22T08:06:15-07:00	[thread overview]
Message-ID: <fba4d26a-8adb-4778-832f-7fc830ca491c@googlegroups.com> (raw)
In-Reply-To: <d7d3f9d8-4514-4794-bfc9-b835e7a2eac4@googlegroups.com>

This isn't the first project to have pleasantries with naming conventions and nomenclature -- nor will it be the last.  The upper case, lower case, camel case and use of other conventions has certainly bedeviled the folks trying to use XML and XML Schema for naming concepts.  This is one of the sources of "semantic heterogeneity" that still bothers the semantic web community [see
the references to a Google search for this term, particularly Halevy, Bergman, and the Web page on the Open Semantic Framework].

There's an excellent summary of the issues involved in naming in

Schneider, D. C., 2009: Quantitative Ecology: Measurement, Models, and Scaling,
Second Edition, Academic Press, Amsterdam, NL

The author notes "Good notation is a tremendous aid in working with [a subject]. ... [When a subject] lacks a clear and consistent notational system [an author is tempted to create such a system] that, once proposed, will, of course, be immediately adopted.  The lessons of history are otherwise.  New notation, if noticed at all, typically passes into oblivion [Cajori,F., 1929: A History of Mathematical Notations, The Open Court Publishing Company, Chicago, IL].  ... This is largely due to the effort required to learn new notation.  Once a notation has been learned ..., it resists replacement by another ... .

A second reason for slow diffusion of new notation is that only experience will tell whether ... [an innovation] is indispensable.  It could take years or decades to find out if ... [an innovation] is worth keeping.  Why go to the effort of learning a new notation unless it is already known to aid comprehension or simplify computation?

Good notation would seem to require little thought.  In fact, there are principles of good notation based on historical experience [Cajori, 1929] ..."

This author tabulates five criteria for good (mathematical) notation:

"
1.  Consistent with current usage
2.  Reduces the burden on memory
3.  Demonstrated utility ...
4.  Brevity
5.  Lends itself to computer applications
"

Then he notes

"The first criterion, consistency with current usage, is important because of the perpetual temptation to improve existing notation.  The reason for listing this criterion first is that notational improvements do not take root and flourish until they are adapted by a nonconferring group of specialists [Cajori, 1929].  Notation that is consistent with current usage increases the communication of ideas.  Novel signs and symbols usually hinder communication.

...

The third criterion ..., utility in application, can really only be determined from experience of groups of people working on similar problems.  This can take decades.  Thirty years between the proposal and eventual adoption of a [notation] ... has not been unusual in the past [Cajori, 1929]."

Biological notation provides one example of the difficulties involved.  It took about a century and five or six international congresses of biologists to settle on the usual Linnean nomenclature [p. ix in Britton, N. and Brown, A., 1913 and republished in 1970: An Illustrated Flora of the Northern United States and Canada, Second Edition, Vol. I, Dover, New York, NY].  Of course there's more nomenclatural turmoil when taxonomists turn to cladistics and the use of DNA and evolutionary models to classify based on the "tree of life".

Bruce B.


  parent reply	other threads:[~2016-05-22 15:06 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13 20:37 ANN: Introducing AdaBase - Thick database bindings for Ada jrmarino
2016-05-13 21:44 ` Per Sandberg
2016-05-13 23:37   ` Randy Brukardt
2016-05-14  6:59     ` gautier_niouzes
2016-05-16 20:06       ` Randy Brukardt
2016-05-17  7:35         ` gautier_niouzes
2016-05-17  9:38           ` G.B.
2016-05-17 23:29             ` Randy Brukardt
2016-05-29  3:45     ` David Botton
2016-05-14  6:22 ` Dmitry A. Kazakov
2016-05-14 10:41   ` jrmarino
2016-05-14 11:31     ` Björn Lundin
2016-05-14 17:11     ` Jeffrey R. Carter
2016-05-14 12:22 ` AdaMagica
2016-05-14 13:27   ` Georg Bauhaus
2016-05-14 13:50     ` Dmitry A. Kazakov
2016-05-15 13:59     ` Shark8
2016-05-15 17:03       ` Björn Lundin
2016-05-19 15:50         ` Shark8
2016-05-15 14:23     ` AdaMagica
2016-05-15 19:38       ` jrmarino
2016-05-16 19:45 ` Olivier Henley
2016-05-18 17:13 ` Anh Vo
2016-05-19  8:16   ` jrmarino
2016-05-20 15:18 ` Martin
2016-05-20 17:44   ` jrmarino
2016-05-20 20:36     ` Jeffrey R. Carter
2016-05-20 23:44       ` jrmarino
2016-05-21  1:12         ` Jeffrey R. Carter
2016-05-21  7:01           ` jrmarino
2016-05-21 10:37             ` Georg Bauhaus
2016-05-21 17:49             ` Jeffrey R. Carter
2016-05-21 18:14               ` jrmarino
2016-05-21  5:11         ` J-P. Rosen
2016-05-21  6:43           ` jrmarino
2016-05-21 11:09             ` J-P. Rosen
2016-05-21 16:54 ` jrmarino
2016-05-21 18:20   ` Jeffrey R. Carter
2016-05-21 18:44     ` jrmarino
2016-05-22 21:35       ` Martin
2016-05-23  0:33         ` brbarkstrom
2016-05-23 11:40           ` Martin
2016-05-23 12:46             ` AdaMagica
2016-05-23 22:03               ` Martin
2016-05-24  7:28                 ` jrmarino
2016-05-24  9:09                   ` J-P. Rosen
2016-05-24 15:27                   ` Simon Wright
2016-05-23 20:28             ` Jeffrey R. Carter
2016-05-22 15:06 ` brbarkstrom [this message]
2016-05-24 10:16 ` Graham Stark
2016-05-26 22:59 ` jrmarino
2016-05-30  9:19 ` karsar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox