Ed, (01)
You sure are heavy with experience! But with all due respect
for it (and I do mean that, as I much enjoy reading you on it,
and must also thank you for your Latin), let me assure you that
your past experience is a poor guide to my post you quoted from
below. There is, out there or in the past, absolutely no
"active practice that corresponds to Christopher Spottiswoode's
view". (02)
For my part, this particular experience tells me that I should
probably just clam-up and get on with that "5th instalment", to
bring out what I _really_ had in mind in that brief post you
responded to. (03)
But first let me just try to identify some of those flies
bothering you which my proposed architecture will shoo away
entirely. Then I shall return determinedly to delineating that
picture of it which I have been promising for so long. (04)
You see, I certainly wasn't recommending an approach such as
those that have produced all those silos. For example, I was
talking of subdomains _within_ workflows and other suchlike
activities. That's at a much finer granularity than that of
those pesky silos. And yes, I shall be showing how
sub-ontologies work at that fine level, if done right, and how
to help ensure they are done right. (05)
Then in your paragraph about the "special-widget" class, your
example is even an excellent basis for my own major criticisms
of presently conventional OO, as it is precisely one of those
"island-classes" that the Classical Object Model tends to
produce. (And that's without getting onto one of my other
favourite criticisms of OO in its present manifestation, where I
show how method overriding is banished in MACK.) So MACK-style
OO too is completely different from what you're used to. (06)
Ah, and another one: you'll see what a pleasure it is to have
MACK resolve the issues that have traditionally landed database
developers in view-updating problems. That scene is totally
turned around. (07)
Ok, now I cut my petulance, clam up and shall concentrate on
writing what I have promised... (08)
Christopher. (09)
----- Original Message -----
From: "Ed Barkmeyer" <edbark@xxxxxxxx>
To: "Adrian Walker" <adriandwalker@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Friday, 15 August, 2008 18:39
Subject: Re: [ontolog-forum] Semantic Web shortcomings [was
Re:ANN: GoodRelations - The Web Ontology for E-Commerce] (010)
> Adrian,
>
> you wrote:
>
>> 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.
>
> 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.
>
> 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.
>
> 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...)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> -Ed
>
> --
> 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
>
> "The opinions expressed above do not reflect consensus of
> NIST, and have not been reviewed by any Government authority."
> (011)
_________________________________________________________________
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 (012)
|