David, Formal English, or any formal language, is not meant for direct use by end users, because end users (shop floor users) will still use the conventional user interfaces of applications. Thus they don’t need to use Formal English directly, but indirectly they will use it when programmers have built databases that are based on it or create export and import message files that are expressed in the common Formal Language, so that every enabled system can interpret the expressions by using the same Dictionary-Taxonomy and language definition.
Formal English is not imposed on people, but IT professionals should be educated in a using some kind of Formal English and older staff should become convinced that this new technology is far better than the old and finally solves many of the problems they always struggled with.
Bye the way, I use the term Formal English, to indicate that I talk about a language that includes only natural English names (terms and phrases) and definitions of natural language concepts, although they are formally defined and included the language definition. On the other hand the theory of formal languages usually creates languages with their own artificial ‘words’ and derivation rules.
I appreciate that your (not mine) financial services experience was far less disciplined than mine, although there are area’s in procurement and accounting with strict rules and procedures that are suitable to be modeled in a Formal Language.
But if you exclude the possibility on beforehand you will never succeed.
You state that in conventional database systems “The language & the data structures will not be hierarchical.”
That is only partially true, because even in natural languages the definitions of concepts in dictionaries have a basic hierarchy, otherwise definitions would become circular. It is even a valuable rule for (formal) dictionary developers to begin definitions with “… is a (subtype of) … thus mentioning the supertypes of the defined concepts (according to ISO 16354).
It is indeed an essential element of the new technology of Gellish Formal English that new database systems are based on a taxonomy (subtype-supertype hierarchy) that includes synonymous and homonymous names for concepts, including kinds of relations. This enables companies to maintains their own synonym terminology. It is not sufficient to base systems on ‘namespaces’ only.
By the way, the users of applications may not be aware of the taxonomy, they only experience the favorable effects of inheritance and semantic verification, which normally comply with their intuition.
I agree that many conventional databases and file structures are terribly structured, but they are nevertheless reasonably well defined by a data model and are not as ambiguous as natural languages. Therefore I said we STARTED from data models for databases. We improved and generalized them into a ‘generic data model’ that appeared to be an upper level ontology, extended it with lower level formal domain dictionaries-taxonomies and then converted the result into Gellish Formal English. That process is very different from developments that start from natural languages. (the process is described in the summary of my PhD).
With kind regards,
Andries
Van: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] Namens David Eddy
Verzonden: vrijdag 31 augustus 2012 21:52
Aan: [ontolog-forum]
Onderwerp: Re: [ontolog-forum] Accommodating legacy software
Andries -
My experience has been primarily with financial services—insurance, mutual funds, banking—which may very well be far less disciplined than physical engineering work.
I imagine—since I've never worked for an organization that dealt with physical things other than paper—that financial services is rather chaotic & tremendously ill-disciplined. Financial services is a fashion driven business. If my competitor is making a lot of money selling a new product, by golly I'd better have that same product on the street by the end of the week... which typically means taking an existing system & mangling the hell out of it. Does not make for well engineered systems.
On Aug 31, 2012, at 12:37 PM, Andries van Renssen wrote:
“The language on our shop floor, being entered as data in databases, uses words for concepts that appeared to have definitions that perfectly fit into a hierarchical taxonomy. “
If the structure of the databases/files/systems already exists & has most likely been modified for decades by many business needs as expressed by programmers, the language is going to be all over the place. The language & the data structures will not be hierarchical.
I have been told more than once that it is "common" to find flat file structures on RDBMSs... say a single table with 1500 columns. Hierarchical?
So this means you will IMPOSE a different language structure than the existing/known ones?
Perhaps to their credit (maybe not) humans are incredibly flexible... they can work with something labeled M0101 for years & literally not know an alternative name is MSTR-POL-NO.
On the other hand, if the organization does have a process in place—some do, but they're few & far between—where FIRST project managers/analysts/programmers reference a "central" (doesn't mean it's all in the same place... just looks that way) resource to research what already exists, I'm willing to sing a different tune.
The far more common process that I've experienced & seen is that eventually work lands on the programmers queue & given they can't find what already exists, they simply make up something "new."