[Top] [All Lists]

Re: [ontolog-forum] Ontology-building vs Data Modelling (was Two ontolog

To: Peter F Brown <peter@xxxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Tue, 19 Jun 2007 13:44:27 -0400
Message-id: <467815FB.6050501@xxxxxxxx>
Peter F Brown wrote:    (01)

> Sometimes I want a formalised, structured way of describing my
> "information territory" and prescribing my definitions of it (yes, it's
> a viewpoint, I agree), irrespective of any application implementation
> but with the objective that it can and will be used, unlike the Red
> Queen.    (02)

In what we used to call "analysis" (as distinct from "design"), this is the 
model of the problem space.  The viewpoint establishes the scope and the level 
of detail that is interesting.  And the model has a purpose -- to understand 
the problem for which you, or someone, is being asked to develop one or more 
"solutions".    (03)

> The problem with application driven approaches is that they are
> often too constrained for use ONLY by that application.    (04)

Well, when used to talk about developing the "enterprise conceptual schema" 
for databases, we were expected to take into account the views and 
requirements of a dozen existing and putative applications.  A viewpoint 
doesn't necessarily have to be narrow.    (05)

By comparison, the model drawn by the developers of one application is likely 
to be useless for other applications, just because that application has no 
interest in other aspects of the same entities.  And this "tunnel vision" 
leads to "simplifications" of the model that are just plain wrong in a larger 
domain.    (06)

But the general problem is that no viewpoint is large enough to be right for 
all applications ever, and models that span a wide spectrum of levels of 
abstraction tend to be useful only at the bottom.  (Manufacturers who fell for 
the misguided "instant management access to manufacturing floor information" 
idea found that managers didn't really care what serial number was in what 
stage in what machine.  What they really wanted to know was:  What is in work 
for which customers and whether the critical resources were all up and being 
utilized.  At higher levels of abstraction, e.g. management, some of the real 
information is *summarized* from the details, as distinct from ignored.)    (07)

> When I did some
> ontology modelling in the European Parliament a few years ago, we got
> much further with a flip chart and brainstorming about our "territory"
> than we did with some very expensive software that distorted our
> expressions. Five years on, our ontology still exist but the modelling
> software is in the trash....    (08)

That's a different problem.  I think of that as "the language getting in the 
way".  "Information modeling" tools that think their sole use is to design 
relational databases tend to be clumsy at modeling the problem space, because 
they want you to make a relational model of the problem space.  In a similar 
way, UML tools can be used for problem space modeling only if you ignore some 
of the language limitations and best practice guidelines that are designed for 
generating Java programs.  This is the trap in the OMG "platform-independent 
model" (PIM) idea.  A PIM is a model of a solution for a particular class of 
platform -- a relational model, an object model, etc.  Object modeling 
apostles, and relational modeling apostles before them, did the software 
engineering community a disservice by insisting that their particular solution 
forms were "natural models", with the consequence a "problem space model" was 
a "solution model".  What they really meant was "you only model the solution" 
and the tools and languages prevented you from making a proper model of the 
problem space.  I preferred to use NIAM for many years, even though it had 
expressiveness limitations and there were *no* good tools, because it was the 
only language that didn't make me say something I didn't mean.    (09)

Ontology languages like OWL have some of the same problems.  They have 
deliberate limitations in expressiveness in order to achieve computational 
tractability.  So you can't always say what you mean in OWL/DL.  You can do so 
in OWL/Full, but that's basically OWL + arbitrary RDF sentences.    (010)

> By the logic of app=driven approaches:
> - you need to know what you're going to build in order to model the
> ontology;
> - an ontology is an output of that process;
> - another application will drive the development of another ontology;
> - so you end up with n apps and n ontologies
> That's just wrong to me...    (011)

Agree.  But it is just another form of the "islands of development" or 
"stovepipe" problem.  It can only be avoided if you put the designers in a 
room and force them to deliver a common ontology for the common concepts.    (012)

One (or more) of the DARPA directors thought the solution was to force all 
ontologies to be derived from a common upper ontology, so that people had to 
fit their work into an existing framework.  The Cyc experience demonstrated 
the folly of that approach.  First, the common upper ontology required 
maintenance for many years, because every major new "microtheory" demonstrated 
some inconsistency in the high-level model.  Second, teams developing 
independent microtheory extensions did not find them to be 100% disjoint, and 
microtheories that were consistent with repaired upper ontology still 
conflicted with one another.    (013)

> The whole point of ontology modelling is that it gives, yes, a platform
> independent viewpoint of your world and, yew, I do want that - even if
> I'm not developing any application at all. I really do not see why
> technology has to come into the picture!    (014)

The whole point of ontology modeling is to capture a formalized and simplified 
understanding of a space -- your understanding.  But "modeling technology" 
comes in that door as the costumer for "formalization".  And if the costumer 
has in his head that your model has to be bulletproof, the materials he gives 
you will be short on silk and long on kevlar.  And that !@#$% kevlar 
implementation technology has been smuggled into your model and limits your 
freedom of movement, whether you like it or not.    (015)

Ultimately the problem you face is that you can't get everything you want. 
You have to decide what is most important for you to be able to capture in 
your model, and what price you are willing to pay (in lost opportunities and 
makework) to get the capability to capture that.  The highest price, and the 
one most often paid in languages like KIF, is that your model will fail to 
communicate your understanding to your target audience, because no one can 
easily "grok" the model as formalized.    (016)

-Ed    (017)

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    (018)

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

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    (020)

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