Dear Patrick, (01)
Any so-called "ontology" (I prefer "schema" or "semantics," depending on
whether you are referring to either the syntax or the rules of transformation)
must have an associated epistemic model. So I am moved to ask, what is the
epistemic model that you, John and Doug use? (02)
The problem of deconstruction of informal high order concepts is that you have
no idea at all if they are sound and what you will quickly find is that the
majority of conceptions are ambiguous and unresolvable - and impossible to
compare or resolve without human intervention and thought. (03)
Unless, of course, you are dealing with mathematics, and even there we have
base level epistemic issues (e.g., classical v. intuitionist). (04)
I have my own system, that I develop and use for my own purposes for concept
reconciliation and analysis (that I now call "The Glass Bead Game" after Hesse,
previously "memeio"). In that system all concepts are enumerated and abstracted
from terms that may be "thrown at each other" to either produce new ideas or
collapse to identified base conceptions (the game). It is not entirely
automatic, nor can it be. (05)
My experience with this technology (that I've researched and developed over the
past 10 years) tells me that the majority of concepts in the informal systems
we consider (even if we limit those to the English language) are so ambiguous
that reduction to base concepts only serves to highlight the ambiguity problem
(which is, indeed, my application for the technology) - offering no solution at
all except to reconstruct the language used. (06)
The application of formal logic to such conceptions before reconciliation to
base conceptions is necessarily erroneous, amplifying the ambiguity problem,
and negating the attempts to do so by the so-called "semantic web" technologies
(another popular abuse of terms well-defined elsewhere). These attempts are
doomed to failure because of this. (07)
It's difficult to see how the problem can be ultimately resolved without
mathematics, a clearly stated epistemology that is reducible to practice and
implementations that make a difference, and the intervention and thought of
human experts. IOW, it requires a discipline and long term commitment generally
considered too much effort by most corporations or institutions, sadly. (08)
Best,
Steven (09)
--
Steven Ericsson-Zenith
Institute for Advanced Science & Engineering
http://iase.info (010)
On Feb 17, 2013, at 7:17 AM, "Patrick Cassidy" <pat@xxxxxxxxx> wrote: (011)
> 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". 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.
>
> 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
> (012)
_________________________________________________________________
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 (013)
|