[Top] [All Lists]

Re: [ontolog-forum] Semantic Web shortcomings [was Re:ANN: GoodRelations

To: Adrian Walker <adriandwalker@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Fri, 15 Aug 2008 12:39:37 -0400
Message-id: <48A5B149.7010909@xxxxxxxx>
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 
> 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)

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