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