Adrian, (01)
you wrote: (02)
> While it's tempting to break the task into
> - Step1: Axiomatize
> - Step2: Make use thereof
>
> it looks -- from this and other discussions -- as though success is much
> more likely if we tightly and interatively interleave Step1 and Step2. (03)
I think that in practice this is what gets done. The attempts to build
a general ontology for a space end up having no users per se, although
bits are used by other ontology developers. The ontologies that
actually get used are purpose-built and modified as needed to support
the intended application. (04)
When the next related application arises, the knowledge engineer starts
with the earlier ontology, and revises as needed to get what is needed
for the new application. In most cases, the two ontologies are no
longer consistent, but with some effort, it is possible to generate a
common one. (05)
This is what I have observed, both first-hand and second- or third-hand,
to be the active practice that corresponds to Christopher Spottiswoode's
view:
> And there are usually many subdomains in any domain, thus
> sub-ontologies in any larger one, each one focussing on the essence of
> the subdomain it targets. Nothing really difficult at all, as long as
> modularity - that age-old strategy of "divide and conquer" - is fully
> embraced (architecture permitting...) (06)
But it seems to me that this should sound familiar, since it was the
common experience in the design of database schemas in the (roughly)
1975-1985 time period. Typically, after 5-10 years of experience, an
organization had 5+ incompatible database schemas, and two new
applications to build. But what they also had was a pretty clear idea
of the scope of their application set, and the scope of the whole domain
that was of interest to them. And that made it possible for them to
adopt the "3-schema architecture", in which the first step was to
develop an 'integrated conceptual schema', that dealt consistently with
all the information they were dealing with. (07)
So, following Christopher's "divide et impere", after you have created a
set of satrapies, you have to restructure your domain to function as an
empire. (08)
IMHO, the currently useful ontologies are still in the purpose-built
category, and we will probably need another 5+ years of experience
before we are able to move on to building more general domain models.
And in reality, that is a win/win situation -- the customer gets
immediate value; the experts learn something more about long-term value.
And that seems to be what Adrian is suggesting. (09)
In the 3-schema architecture, the next step is to build a set of "view
schemas" that are formally derived from the conceptual schema but look
like the schemas used by the individual applications. And there are
limits on what one can do in that regard. The long-standing bugaboo was
"updating through a view" -- changing an information set that isn't
really the one you see. The ontology equivalent is that there are
axioms that hold in a subdomain, but don't hold generally, while the
subjects of the axioms may well participate in multiple subdomains.
This is the "deeper" "conflicting microtheory" problem, and it is not
just a consequence of ignorance of the larger domain. (010)
In order to make a single consistent ontology, one has to have the
necessary concept architecture to express the real antecedents in the
subdomain-specific axioms. The idea that I can just make a class
"special-widget" that has the domain-specific properties is fine, if and
only if I can also *prove* special-widget(x) for the x's of interest.
The "object-oriented" style of solution is to simply assert
special-widget(Z) for each Z used by the sub-domain application. And
that oversimplification will inevitably result in some
mis-classifications that produce inconsistencies for some other
application, when other uses of some Z proves it not to have one of the
special-widget properties. (In my domain, the problem is often that the
legal classification, or the customs classification, or the accounting
classification, of some product or material is different, and it
falsifies an assumption that would not actually have been used in the
subdomain in this case.) It is "updating through a view" all over again. (011)
But I don't think we should be too worried about this cloud on the
horizon just now. We need a lot more experience with effective
ontologies for real sub-domains. (012)
With respect to the learn-by-doing approach, Adrian suggests:
> One way to do this is in a Wiki for executable content. Items [1,2] below
> represent one such approach. (013)
A quick look suggests that this is a proposal to use a Wiki as a
mechanism for piecewise construction of the integrating ontology whilst
"simultaneously" developing multiple problem-specific ontologies.
The subject matter is a bit different, but this is the analogy I see.
Is that the intent? (014)
-Ed (015)
--
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 (016)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (017)
_________________________________________________________________
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 (018)
|