[Top] [All Lists]

Re: [ontolog-forum] intangibles (was RE: Why most classifications INare

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 5 Aug 2011 14:40:21 -0700
Message-id: <53AA73C9427544BFA024F197534D26AB@Gateway>

Dear John,


There are some interesting and major differences in our world views, which show up in this latest difference in our convictions.  Comments below,





Rich Cooper


Rich AT EnglishLogicKernel DOT com

9 4 9 \ 5 2 5 - 5 7 1 2


-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Friday, August 05, 2011 11:52 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] intangibles (was RE: Why most classifications INare fuzzy)


JFS:>  On 8/5/2011 12:04 PM, Rich Cooper wrote:

> An engineering model is in no way even remotely

> similar to a possible world.


The difference between your two definitions is not only insignificant,

it's almost nonexistent:


  1. "A possible world is, for the most part, a fantasy of what

     might possibly happen, but can't be experienced in this



  2. "a model (for us engineers) is an abstraction of reality

     subject to validation."


The word 'fantasy' is a value judgment.  A more neutral term

is 'specification'.  The term 'abstraction of reality' is

another term for 'specification'.


RGC:>  Here we disagree on nomenclature based on world views.  An abstraction of reality is not usually a specification, though a specification is often an abstraction of reality. 


A model is based on past history – the reality comes first, not last.  So an IDEF0 process model, for example, is based on experiences in the history of similar projects analyzed statistically, compared and merged to create a set of constraints that serve to constrain the fantasy to something that might someday be real. 


A requirements specification (as used in engineering) is a document describing a fantasy which may someday be realized – that specification comes first, and the realization may or may not ever be realized.  Many projects end with the requirements specification once the estimates of cost and schedule to complete are filled in.  Other projects are only constructible using unobtainium – like fusion for example.  Richard Feynman’s statement that antimatter is matter moving backward in time is a good example of an untestable hypothesis with current technology.  So constructing a time machine is, as I say, pure fantasy at this time until we get some unobtainium.  Likewise, effective fusion seems to be a fantasy until we find a way to get huge amounts of tritium from the moon, where it may not even actually be found as expected in scientists’ fantasies. 


A formal specification of a standard (like SQL-92) is (in nearly all cases) a description that encourages producers to develop products and services that meet the said specification.  In math, you use the word “specification” in a formal way such that a possible world is anything that can be forward chained from a set of axioms and rules.  In engineering a specification is an elaborate document with equations and NLP statements that codifies the nature of a fantasy in vivid language, yet to be realized, and will ultimately be only an approximation thereof, not a rigorous mathematical construal of a set of axioms and rules whose closure is adequate for implementing the desired fantasy. 


My sentence above “a model … is an abstraction of reality” is only the first part of the definition.  The “subject to validation” phrase is more cogent to the definition than the “abstraction of reality” phrase for those reasons above.  I understand that you are used to a certain format for mathematical language which can make a complete definition in a single sentence or equation cast as a definition, but it takes much more than that to complete an engineering definition.  There are many more “is-a” terms conjoining the specification part. 


The only question is whether there is any detectable difference

between the two qualifying phrases.


As I discussed this above, I consider the differences to be huge, not just detectable, but different in quality and structure. 


For the first, the term 'possible' means that the specification

is sufficiently similar to our real world that it could be

realized by some modification.  Before that modification has

been made, it couldn't be experienced.  But afterwards, it could.


I prefer “by some realization” to “by some modification” since modifications may not often be necessary, but the specification is only partially complete by definition in engineering, and not adequate for constructing even a plausible design document, which is much more detailed and elaborate.  Specification requires about 8% of a system development effort, while design, if properly performed and validated, takes about 30% and testing takes about 50%.  The other 12% is chewed up in document production for the various developmental stages. 


For the second, the term 'subject to validation' means that one

could verify that the specification is consistent with the laws

of the world (i.e., sufficiently similar) that it could be

"validated" (i.e., realized by some modification).  Before that

modification has been made, the model couldn't be experienced.

But afterwards, it could.


Engineering specifications for most purposes aren’t expected to conflict with laws of nature in any way, but often they do in subtle ways not evident in the specification until realization brings out the errors and inadequacies of the specification.  Even large projects that are supposedly new (think the first space vehicles) are based on well known laws, but the closure of the specifications contain many requirements for unobtainium and inconsistencies that are not known in the specifications. 


Those two qualifying phrases were stated in different ways,

but their implications are either identical or sufficiently

similar that they have a very high overlap.


Again, if you use the term “engineering model” I disagree.  If you are discussing math, then you may have a valid point. 


I'll admit that some modifications necessary for some possible

worlds could be difficult or impossible to achieve by modifying

our current world.  An example would be a trip back in time to

meet Beethoven, Julius Caesar, or Moses.  But it could be solved

by an engineering model of a time machine, which would be equally

difficult to validate.


There is no engineering model of a time machine; it is a fantasy specification not an engineering model. 


So the only difference between the two is a matter of degree.

If we allow mental models and/or virtual reality as well as

ordinary engineering models, that difference vanishes.


If we allow virtual reality, we are indulging fantasies.  Only real reality is the end product of engineering.  It could be an engineering task to develop a virtually reality simulation, but then the reality is the construction of the virtual reality simulation, but the virtual reality is not itself the engineering part. 


> The world is much larger than FOL and ontology can

> possibly enfold.


I'll admit that the world may be more complex than we can

imagine.  But any specification that we can imagine and

put into words could be translated to FOL.




Someone famous (you probably remember who) said something like “reality is more complex than we can even imagine”.  Do you recall the exact phrase, and perhaps who it was that famously said that?  Engineering is concerned, in practice, with what is not known about a specification’s applicability to reality, and which must be planned, validated and tested to become functional. 


I think a lot of our disagreements are based on these differences in world view, which acknowledges the subjectivity of our separate world views.  Ontology, to be useful in engineering must address these subjective issues or it will fail to be useful in engineering applications. 




Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)

<Prev in Thread] Current Thread [Next in Thread>