ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Data Models v. Ontologies (again)

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Thu, 22 May 2008 16:36:58 -0400
Message-id: <4835D96A.4060408@xxxxxxxx>
Len Yabloko wrote:    (01)

> I don't think you appreciate both: the intellectual challenge
> and practical implications of this discussion.      (02)

I'm sure I don't.    (03)

> To call something an engineering does not make it so.    (04)

Agree.  The same goes for "theory" and "science", I might add.    (05)

> Before Industrial Revolution people were building and making things
> for the most practical reasons and in the most practical way they 
> could imagine at the time. That does not qualify it as engineering.
> That was craftsmanship like carpenter, smith etc. 
>
> Engineering results in consistent scalable production,    (06)

If by "consistent, scalable production", you mean there is a set of 
established methods and practices that are known to work in most problem 
spaces (of a given kind), I can agree.    (07)

> which so called "knowledge engineering" does not.    (08)

Well, OK.  At present that is true.  We haven't yet established a set of 
reliable methods and practices.  But we are trying to find them.  And we 
probably don't have enough observations to be used as a basis.  (In 
fact, many of the best observations we have are from data modeling.)    (09)

> And it will not until it applies theories.    (010)

I would point out that some magnificent buildings were built by persons 
with experience and methods without benefit of accepted theories.
We call the builders of the pyramids and of the temple in Jerusalem 
"masons", rather than "civil engineers", I suppose.  But a
number of reputable publications have referred to DaVinci as a "military 
and civil engineer".  And the Romans surely did "military engineering", 
by all accounts.  And shatter-resistant windshields were designed in the 
1950s, but the supporting mathematics for the structural analysis was 
developed in the 1960s.  And the operations research methods of the 
1960s also proved that the logistical planning for the 1948 Berlin 
airlift was 94% of optimal.    (011)

To put it plainly, I don't think the experimental evidence supports 
Len's hypothesis.    (012)

"Consistent scalable production" is not dependent on having theories, it 
is dependent on having established methods and practices, supported by 
observations at least, and theories at best.    (013)

I would not accept the idea that "civil engineering" first began with 
Eiffel and Roebling, just because they were actually applying physical 
theory to the problem of structural design.  But that _was_ the time 
when civil engineering moved from an observation basis to a theory basis.    (014)

> One of theories is "Model Theory" which you so casually attached
> to "model of knowledge". This is another example of pseudo-engineering.
> In fact data modeling is only an engineering discipline withing a
> particular well axiomatized relational model with all available
> mathematical and technical tools.     (015)

And otherwise it is simply a technical trade?  OK, then I'm a tradesman.    (016)

I have an analysis approach, a design approach, correctness principles 
and quality principles, and validation methods, but these are based on 
the collective experience and observation of a community.  Yes, we lack 
a mathematical theory for comprehending what business people mean by 
what they say.  But just as Caesar's engineers knew how to get an army 
across the Rhine, we do know how to get a business's data into a 
manageable, reliable repository that supports its applications.  And 
doing that takes analysis and design and development and verification 
and testing.  That is why we call ourselves "engineers".    (017)

BTW, we don't so much lack theories.  The problem is in figuring out how 
to apply them.  And that might mean there are no useful theories yet.    (018)

> Likewise software engineering is only engineering within well
> developed calculus translated into true programing languages -    (019)

Well, I agree that "software engineering", as currently practiced by 
most software engineers, isn't engineering.  But the above is not 
helpful.  It only encourages the nonsense of "computer science" and 
"automated software design".    (020)

Software engineering is about the design of a machine, a system, and you 
can no more completely characterize the behavior of a software machine 
than you can a complex mechanical device.  You can completely 
characterize the behavior of small parts and you can approximate the 
system behavior with analytical models and simulations and empirical 
measurements, in both cases.  The difference is that mechanical 
engineers do; and "software engineers" could, but don't.    (021)

There is no calculus for programs and there is no calculus for engine 
designs.  There are methods for evaluating engine designs, and there are 
methods for evaluating software designs.    (022)

But "computer science" uses semantics and logic, relational algebra, 
numerical methods, mathematical programming, and simple machine theory, 
which seems to me to be a fairly strong theoretical basis -- it just 
ain't physics.  And it isn't yet clear how it provides more than a basis 
for methods for solving specific kinds of sub-problems.    (023)

And no engineering discipline has a theory, or even a clear and accepted 
discipline for "systems engineering" -- breaking the real problem down 
into solvable parts and rebuilding a functional whole from the part 
solutions.  There is coming to be an established practice for that, but 
it is very recent.  30 years ago, it was a "black art", and the 
expertise was hidden inside the companies that built big systems -- 
ships, aircraft, automobiles -- because it was part of the corporate 
business advantage.  But software engineers have been forced to solve 
similar problems for over 20 years, and most of what was called 
"software engineering" in the literature was about dealing with "systems 
engineering" problems.    (024)

> all other "creativity" in  software industry has not yet reached
> the level of engineering, despite considerable wealth created,
> which is not a proof of soundness (at least to me).    (025)

Engineering is about applying theory, knowledge, observations, 
principles and method.  I agree that the software industry as a whole 
has not yet reached the level of "engineering", but IMO, the problem is 
the failure to abide by established principles and the failure to 
practice method.    (026)

We don't teach "computer scientists" to be engineers; and we the 
employers don't require them to be.  We treat them like artisans and 
they behave like artisans.  But the first step in fixing this is to 
teach them engineering discipline and enforce it in the workplace. 
Unlike Len, I think emphasizing "theory" muddles that message.    (027)

-Ed    (028)

-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (029)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (030)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (031)

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