ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Architectural considerations in Ontology Development

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Patrick Cassidy" <pat@xxxxxxxxx>
Date: Sun, 17 Feb 2013 10:17:15 -0500
Message-id: <0d0e01ce0d21$de5ef510$9b1cdf30$@com>
It appears to me that John S and Doug F have a lot in common in their views
of what a proper upper level would be for ontology integration, and I agree
with both.  As Doug said:    (01)

>> I would challenge the statement that a top ontology would have to make
these kinds of philosophical commitments.  I think that John Sowa also
challenged this, but i'd like to explain in more depth.    (02)

Or, as John puts it, the top level should be "underspecified".  But there is
that comment from Doug Lenat about any upper ontology being adequate - -  I
interpret that as meaning, if you are a single company and will base all
your domain ontologies on that upper level, you can get away with making
some high-level commitments that others may not make.  **But**, if you are
designing a top-level ontology that can integrate other **independently
developed** top-level ontologies, it is not true that any top ontology will
do. One needs to be sufficiently underspecified to be able to **translate**
the assertions of each ontology into any of the others, meaning that you may
have to break down some of the aggregated concepts of some ontologies into
more basic elements to relate them to other ontologies.
   This is where I still believe that identifying the most primitive
concepts and representing those would provide us (at the least cost) with a
top-level ontology that can be used for integration at that most general
level.
   The problem that I have noticed is that, to prove that any given
primitives-based ontology will actually perform as intended, one needs to
build multiple independently developed non-trivial ontology-based
applications and show that the top ontology will indeed serve to support
accurate communication among them.  I haven't yet run into anyone with
enough money and interest to fund such an experiment.  I fear that until
such a person shows up, this conversation, which has gone on for twenty
years, will continue indefinitely.    (03)

   Pat    (04)

Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416    (05)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
Sent: Saturday, February 16, 2013 4:54 PM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Architectural considerations in Ontology
Development    (06)

Dear Matthew, David, Kingsley, and Steven,    (07)

MW
> ... both you and Doug completely missed the point that we were
> talking about methodologies for INTEGRATING (or conceptual)
> ontologies, not reasoning ontologies.    (08)

First of all, you cannot separate concepts from reasoning.
But that is not the source of the disagreement.    (09)

I believe that our disagreement arises over the distinction between
a descriptive definition and a proscriptive or normative definition.
In your work at Shell, you were defining standards for integrating
the engineering designs at a single company.  For that purpose,
you needed to specify normative standards.    (010)

I recognize the importance of specifying engineering standards,
especially since I have participated in ISO standards groups.
But we also need to design our systems to interoperate in a
world of people and systems over which we have no control.    (011)

MW
> The whole purpose of an integrating ontology is to be able to leave
> the legacy systems alone, but bring together their data in a uniform
> environment so that data can be analysed across multiple applications.    (012)

I believe that we should use the term 'normative' for any ontology
that is designed to establish a standard for some domain.    (013)

Since legacy systems run the world economy and they're not going away,
we must also relate the normative concepts to the descriptive concepts
about a wide range of systems whose design is outside our control.    (014)

MW
> CYC is not an integrating ontology - granted it is very large, but
> it has an entirely different purpose.    (015)

I agree that Cyc was primarily designed to be a descriptive ontology,
but it can also support microtheories of normative concepts for
any purpose anyone might need to specify.    (016)

For example, Cyc can give underspecified definitions for time and
space that avoid any commitment to a 4D or a 3+1 D ontology.  Then
different microtheories could add axioms that complete the spec
in one way or the other.    (017)

JFS
>> Avoid making detailed commitments in the top levels.  Push any
>> complex details or distinctions into the middle and lower levels.    (018)

MW
> Rubbish. You should make commitments at the appropriate level.    (019)

I can't disagree with the sentence following the word 'rubbish'.    (020)

But I had descriptive ontologies in mind.  I believe that it is
possible to communicate between systems that use different and
even inconsistent ontologies or no explicit ontology of any kind.    (021)

An underspecified descriptive ontology could be used for general
communication.  You could define your ontology as a stand-alone
normative ontology.  But for broader communication, a copy of it
could be inserted as a microtheory underneath a descriptive ontology.    (022)

Communications between the systems are possible if the messages
do not require any of the details that cause conflicts.    (023)

JFS
>> Design the ontology in a way that is easy to modify or adapt
>> as needed -- preferably by automated or semi-automated methods.    (024)

MW
> Well I'm pleased to find something I can agree with at last. However,
> I think this is as much a design approach issue as it is a tools issue.    (025)

I agree.    (026)

MW
> I would appreciate it if you could try to react to what is being
> discussed, rather than keep mounting old hobby horses.    (027)

I believe that our disagreements would vanish if we adopt the terms
'normative' and 'descriptive'.    (028)

I agree that an ontology used *only* for normative purposes can put
design decisions (such as a 4D vs 3+1 D ontology) at the highest
levels.  But to support communication with outside systems (and
interoperability depends critically on communication), it is
necessary to use a very underspecified upper level.    (029)

In summary, your normative ontology could be used with a descriptive
ontology such as Cyc by defining it as a Cyc microtheory in which
the underspecified terms in the upper level would become fully
specified in the way that your ontology requires.    (030)

DE
> I would argue that to a large extent what "formal requirements" exist
> are only the code since it's what runs in production tonight.  The formal,
> written documentation that may have existed initially has been allowed to
lapse.    (031)

Yes.  That is what happened in the legacy engineering project I
mentioned.  Fortunately, the VivoMind software was able to detect
the changes that occurred over time.    (032)

DE
> I think I remember in the VivoMind examples...    (033)

Yes. I sometimes shorten the presentation by omitting some examples.    (034)

KI
> Yes, you want to enable folks to take advantage of contemporary and
> future technology advances while minimizing disruption (if any) to
> legacy systems.    (035)

That requires a careful balance between descriptive and normative
definitions and constraints.  I believe it can be done.    (036)

SEZ
> ... the assurance that in writing an application the program and any data
> representation will be translated correctly to the machine; not only in
the
> first instance but on any machine for which it may be translated in the
future...    (037)

That is a normative constraint.  I agree that it is necessary to 
guarantee that a particular implementation does exactly what the
the manual says it does.    (038)

SEZ
> I am against diversity, heterogeneity, and interoperability if it means
> - as excuse - that things get to stay as they are.    (039)

Unless the world is taken over by an omniscient dictator who asserts
all the specifications and micromanages every implementation, we will
always have diversity and heterogeneity.  I recommend that we design
our systems to support interoperability with systems we can't control.    (040)

But we can still make sure our own systems conform to the manual.    (041)

John    (042)

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (043)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (044)

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