Dear Patrick, (01)
> 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:
>
> >> 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.
>
> Or, as John puts it, the top level should be "underspecified". (02)
MW: If a top level ontology is underspecified, then it means that different
interpretations can be made. That does nothing to help consistency. What you
really want in an integrating ontology is the kind of rigour that means that
different people would naturally say the same thing in the same way, so the
results are consistent, and that rigour comes from the upper ontology making
key commitments that determines the way that lower level ontology and ground
facts are expressed. (03)
> 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. (04)
MW: No. The integrating ontology is the one you translate the sources into,
not something that can just put loads of other stuff together in. It
therefore needs to be rigorous to minimize the chances of people translating
into it inconsistently. (05)
Regards (06)
Matthew West
Information Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/ (07)
This email originates from Information Junction Ltd. Registered in England
and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
Hertfordshire, SG6 3JE. (08)
> 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.
>
> Pat
>
> Patrick Cassidy
> MICRA Inc.
> cassidy@xxxxxxxxx
> 908-561-3416
>
> -----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
>
> Dear Matthew, David, Kingsley, and Steven,
>
> MW
> > ... both you and Doug completely missed the point that we were talking
> > about methodologies for INTEGRATING (or conceptual) ontologies, not
> > reasoning ontologies.
>
> First of all, you cannot separate concepts from reasoning.
> But that is not the source of the disagreement.
>
> 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.
>
> 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.
>
> 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.
>
> I believe that we should use the term 'normative' for any ontology that is
> designed to establish a standard for some domain.
>
> 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.
>
> MW
> > CYC is not an integrating ontology - granted it is very large, but it
> > has an entirely different purpose.
>
> 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.
>
> 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.
>
> JFS
> >> Avoid making detailed commitments in the top levels. Push any
> >> complex details or distinctions into the middle and lower levels.
>
> MW
> > Rubbish. You should make commitments at the appropriate level.
>
> I can't disagree with the sentence following the word 'rubbish'.
>
> 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.
>
> 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.
>
> Communications between the systems are possible if the messages do not
require
> any of the details that cause conflicts.
>
> JFS
> >> Design the ontology in a way that is easy to modify or adapt as
> >> needed -- preferably by automated or semi-automated methods.
>
> 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.
>
> I agree.
>
> MW
> > I would appreciate it if you could try to react to what is being
> > discussed, rather than keep mounting old hobby horses.
>
> I believe that our disagreements would vanish if we adopt the terms
> 'normative' and 'descriptive'.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> DE
> > I think I remember in the VivoMind examples...
>
> Yes. I sometimes shorten the presentation by omitting some examples.
>
> KI
> > Yes, you want to enable folks to take advantage of contemporary and
> > future technology advances while minimizing disruption (if any) to
> > legacy systems.
>
> That requires a careful balance between descriptive and normative
definitions
> and constraints. I believe it can be done.
>
> 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...
>
> 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.
>
> SEZ
> > I am against diversity, heterogeneity, and interoperability if it
> > means
> > - as excuse - that things get to stay as they are.
>
> 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.
>
> But we can still make sure our own systems conform to the manual.
>
> John
>
> _________________________________________________________________
> 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
>
>
>
> _________________________________________________________________
> 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
> (09)
_________________________________________________________________
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 (010)
|