SUO: Has anyone seen this message already?
Hello,
I received the message below from Matthew West but it never
showed up in neither the CG nor the SUO mail archive in spite
of being supposedly sent there.
So I am wondering if anyone else received it.
WHAT'S UP???
-- Jean-Luc Delatre
===================================================================================
From - Fri Apr 12 15:34:54 2002
Received: from ruebert.ieee.org (ruebert.ieee.org [140.98.193.10])
by relay-3v.club-internet.fr (Postfix) with ESMTP id 5A49E1716
for <jld@club-internet.fr>; Fri, 12 Apr 2002 11:57:30 +0200 (CEST)
Received: ()
by ruebert.ieee.org (Switch-2.1.0/Switch-2.1.0) id g3C9DLo00917
for standard-upper-ontology-resent; Fri, 12 Apr 2002 05:13:21 -0400 (EDT)
Message-ID: <DE057CA9F46ED2118C4900805F85E4270B5B8AED@lonsc0s0038.sipc.shell.co.uk>
From: "West, Matthew R SITI-ITPSIE" <Matthew.R.West@is.shell.com>
To: Jean-Luc Delatre <jld@club-internet.fr>
Cc: cg@cs.uah.edu,
Stand Up Ontology <standard-upper-ontology@ieee.org>
Subject: RE: SUO: RE: Architectures for Intelligent Systems
Date: Fri, 12 Apr 2002 11:12:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ruebert.ieee.org id g3C9DK900911
Sender: owner-standard-upper-ontology@majordomo.ieee.org
Precedence: bulk
Reply-To: "West, Matthew R SITI-ITPSIE" <Matthew.R.West@is.shell.com>
X-Resent-To: Multiple Recipients <standard-upper-ontology@majordomo.ieee.org>
X-Listname: standard-upper-ontology
X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org
X-Moderator-Address: standard-upper-ontology-approval@majordomo.ieee.org
Status:
X-Mmail: \Recent
X-M-Uid: 14039.1018605450
X-Mozilla-Status: 8013
X-Mozilla-Status2: 00000000
X-UIDL: 14039.1018605450
Dear Jean-Luc,
What you describe below seems to me to be at least most of
what it takes to integrate two (or more) ontologies.
See some comments below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.r.west@is.shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Jean-Luc Delatre [mailto:jld@club-internet.fr]
> Sent: 11 April 2002 09:35
> To: West, Matthew R SITI-ITPSIE
> Cc: cg@cs.uah.edu; Stand Up Ontology
> Subject: Re: SUO: RE: Architectures for Intelligent Systems
>
>
> "West, Matthew R SITI-ITPSIE" a écrit :
> >
> > Dear Jean-Luc,
> >
> > My interpretation of what you are proposing is that some set of
> > independently developed ontologies can be integrated through some
> > automated process.
> >
> > If you can explain how that would work I would be very interested,
> > because I don't know how to do that.
> >
> > How do you propose that a broker would match concepts in
> one ontology
> > to concepts in another ontology?
>
> Roughly, there must be a "core" ontology, what SUO calls "upper" but
> it's content has to be rather different of what SUO is looking for
> that's why I choose to use another name.
MW: If you know what SUO is looking for then please enlighten the rest
of us! However, I suspect that you are really referring to SUMO rather
than SUO. If so, please be careful NOT to confuse the two.
>
> The core must contain two kinds of knowledge:
>
> - A *really* terse logical framework whith which you must have the
> capability to describe both the syntax and semantics of *any*
> other formalism: Cyc (willing they to tell us what's in), KIF,
> CGIF, RDF, Mizar, HOL, ad libitum...
> This is the reason why I ask for a "high order" formalism.
> I have some ideas of what it should look like, but it is not
> finalized.
MW: I agree that something like this is desirable. Common Logic may
will give the basis for this. I am not sure that higher order logic
is necessary though.
>
> - A more "classical" ontology of basic concepts, that is, concepts
> for non structured things like 'color', 'temperature', 'right'
> and 'left' etc... Anything that could NOT be explained, say, to
> an alien, because it needs monstration. Yet, provision would be
> made for inclusion of "opaque" new concepts, like when explaining
> the word 'red' to a blind man, he can learn to use it properly
> while still having *no clue* of what it is.
MW: The size of this is potentially huge, it might even be infinite.
>
> This part is even more "delicate" to setup than the logical
> framework
> because I would not trust "hand-crafting" that part,
MW: On the other hand I know of no automated process I would trust
to identify concepts reliably, not least because no one has been able
to describe such a process to me satisfactorily. This is the holy grail
that Jon is after, and it is worth seeking, but it has not yet been
found as far as I know. So I am left with hand crafting, until I can
at least understand the hand crafting process.
> no more than I
> trust the SUO effort.
MW: Again, do you mean SUMO here? Please be careful.
> I envision some kind of analysis over a corpus of somehow "raw" text
> pertaining to a given domain to locate the terminal leafs in the
> concepts structure.
MW: Well this is fine, and what is usually done, but it doesn't have to
be automated.
> This means that this "basic concepts" part is likely to be split
> between many application domains.
MW: ???
>
> It will be "modular" but with a mostly flat structure not very much
> lattice-like,
MW: I don't think you should be trying to determine the structure of an
ontology, but discover it.
> and, BTW, I find it *absolutely* ludicrous to
> aim this
> effort of ontology construction toward anything close to the full
> scope of natural languages.
MW: Natural language is not my target either, but more structured
information as found in databases, data sheets, and other structured
data.
> Specialised domain ontologies would be
> much less worrysome and MUCH MORE USEFULL FOR REAL APPLICATIONS!
MW: I'm not convinced about this. I find it interesting to note that
a core set of concepts (e.g. classification, specialisation, composition,
connection) are involved in almost any domain, and generally dominate
the description of that domain.
>
> Natural language ontology is just a *toy* for the academics...
MW: I would not go that far. I think the problem with natural language
is that the focus is on saying as little as possible, and making as much
as possible implicit (this is after all more efficient). However, the
problem with the processing of natural language, is not what was said,
but what you have to have as the implicit knowledge before you can
reliably understand what is said.
MW: This makes NL a tough nut to crack, that is all, and I would rather
start with something easier that may provide a foundation that allows
NL to be better dealt with later.
>
> From such a basis, ontology developpers would be free to use the
> formalism that suits them most among the ones mentionned above
> and even to invent any new one provided they give a formal
> description of it's syntax and semantics.
MW: Therein lies a can of worms.
>
> Then from the "basic" concepts of one or more domains they will
> build structured concepts of their own that could be matched by
> the broker to any other ontology developped along the same rules.
> There will be some rules about the way to qualify the "constructed"
> concepts such as to satisfy the FCA like requirements for the broker.
MW: Would you care to state what the rules are?
>
> Existing ontologies already built "outside" of these rules
> will possibly
> have to be reshaped (still within their own formalism) and
> may be even
> *supplemented* to satisfy the rules. This should be a
> mechanised process
> which will depends mostly on the base formalism and in some
> cases, perhaps,
> on the particular domain or the specific ontology within the domain.
MW: I.e. they have to be integrated. Again I do not see somthing
well defined enough here that it can be "mechanised".
>
> About consistency, I already said in a working document which has
> only been forwarded to Jay Halcomb (sigh...) and a few others:
>
> > I don't expect the basic "negociation" capabilities to ever fall
> > into this [Russel's paradox].
> > The *content* of what is negociated might, but that's not
> > the *core ontology*'s business.
> >
> > It's up to you (the "receiving" ontology) to assess the
> trustworthyness
> > of your remote correspondant ontology to avoid it
> screwing the consistency
> > of your knowledge.
> > Domain dependency again, plus "out of ontology"
> criterion of safety,
> > there will be *ontology viruses*, isn't that great!
MW: Again, where is the well defined process that can be automated.
>
> Of course, there will have to be disambiguation of homonyms from
> different domains and even different contexts within the same domain
> etc, etc... but this a developpement effort *not* an
> architectural one.
> Because as I already required, there should *not* be direct mapping
> from lexemes to concepts (nodes in the FCA lattice).
MW: And how are you going to automate that?
>
> > Take a really simple example. Suppose you have one ontology that
> > does mereology based on a spatio-temporal ontology. How do you know
> > (=find out) that you can't mix that with another ontology that uses
> > continuants as its underlying paradigm of persistence?
>
> I don't know about "mereology based on a spatio-temporal
> ontology", so
> I cannot fully elaborate on this, you would be kind to give me a more
> "mundane" example exhibiting the same problem.
MW: The example is quite mundane. Mereology is the study of whole/part.
A spatio-temporal ontology is one that sees individuals as spatio-temporal
extents (4d worms if you like) rather than as continuants, that are wholly
present at each point in time and persistent through time. Classical
mereology is sufficient for a spatio-temporal ontology, but it is not for
a continuant based one (at least as soon as time is taken into account).
If you want to understand how different these are I suggest reading Peter
Simons' "Parts".
MW: As I mentioned above, composition (whole/part) is one of those basic
innescapable subjects, so we need to have some answers here.
>
> Yet, I can sketch the process of ontology matching.
>
> A general consideration about "mixing" ontologies from the same or
> overlapping domains which use "incompatible" primitives:
>
> If the primitives are properly described it should always be
> *theoretically* possible for the broker to figure out the "mapping"
> between the two sets of primitives, but that may put a real
> strain on
> the inference engine and may not be "practically" feasible, too bad!
MW: Again I see no process I can automate.
>
> The following is merely a restatement (hopefully more intelligible)
> of what has already been explained in:
>
> http://suo.ieee.org/email/msg08132.html
> whith reference to:
> http://www.math.washington.edu/~hillman/PUB/newconcept.ps
> http://suo.ieee.org/email/msg08252.html
>
> and a few working documents only disclosed to a handfull of people.
>
> The main point about the "interoperable" ontology structure is that
> concepts have to be defined *only* by their attributes/properties
> such as to allow the computation of "proper" concepts by FCA closure
> upon the extension and comprehension.
>
> Of course this has to end somewhere, this why "basic" concepts are
> to be provided and agreed upon in the domain specific ontologies.
> These basic concepts are rather attributes/properties than concepts,
> that is, they are *elements* of the comprehension set of the FCA, not
> subsets (for uniformity they also can be viewed as singletons).
MW: This approach imposes a whole philosophy I do not necessarily
subscribe to.
>
> Non basic attributes/properties have the form of binary relation
> where one argument (say the first) is an instance of the concept
> being defined and the other argument is an existentially quantified
> occurrence of another concept.
>
> A car has a 'power source' which is an 'engine'.
>
> Thus, the relation itself must be "conceptualised" with respect to
> it's "function", "role" or "place" within the defined concept.
> It is not enough to say "a car 'has' an engine".
>
> This is a REQUIREMENT for the broker logic to be able to work.
>
> ******************************************************************
> * However, that does NOT mean that the source ontology has to *
> * be formatted this way. Only that it's content plus the formal *
> * description of it's structure should allow the source broker *
> * to present the data in such a format to the querying broker. *
> ******************************************************************
>
> Assume some query/response interaction is going on between us and a
> remote party which has his own ontology (compatible thru the broker
> but different from ours) and that the syntax of the exchange has
> already been agreed upon.
>
> I may happen that among a query or response a word appears for which
> the "meaning" is not yet known. Then we have to ask for
> "explanations",
> that is we have to engage in a "sub-dialog" in order to figure out
> what can be the "translated" meaning in our local ontology.
>
> We have to ask for the "attributes" that define this new word.
MW: By now you are being quite prescriptive about how ontologies should
look. Which at one level is fine, but at another level, I doubt if many
current ontologies conform, so they would all have to be rewritten,
in which case they might as well be incorporated into a single integrated
ontology, which your rules are pushing towards anyway.
>
> Suppose first, that being answered with the list of attributes that
> define this new word we happen to "know" all of them, that is, we
> already have a translated meaning in our local ontology for each one.
> Then we check if this set of translated attributes in our ontology
> constitute a proper concept closed under |><|.
MW: How would this happen (that we - the system - "know" them all)?
Again it seems to me that you are stating the conditions that mean we
must have integrated the ontologies before they can interoperate. After
they are integrated, of course they can interoperate.
>
> (see Hillman's paper p3-4 or msg08132 or msg08062 for notations,
> fragments of the current message are copied from some others)
>
> Suppose it does (easy cases first...) then either we have a name
> for this concept in our local ontology, it is a simple one to one
> correspondance between a named concept from the other side and a
> named concept of ours, we store the correspondance into our
> dictionary and we are done.
> If we have a proper concept but no name for it in the C relation,
> we have to "invent" a neologism to be put into N and add the
> corresponding (n, s) pair to C before we can update the dictionary.
>
> Now, more awkward case, we still know the meaning of all the
> attributes, but when we check for concept closure it fails.
>
> What does this mean?
>
> It means that the other participant knows a "thing",
> "object", "concept"
> whatever, material or immaterial that we never actually met yet.
>
> We have to trust him and create an instance of such a "thing" in
> the X set in order to allow for a concept closure to occur which
> will have this "example" or "template" thing as only member of
> it's extension and which comprehension will be exactly the set of
> attributes specified by the other participant.
>
> An we are back to the previous steps, having to create a
> neologism etc...
>
> But, adding a new "thing" instance may actually change drastically the
> structure of the local concepts lattice and may require that we make
> choices about possible renamings and redefinitions of
> existing concepts.
MW: Yes, but this is the integration process, and I do not see how you
automate it. You can only automate interoperation after the integration
process has been undertaken.
>
> This is the 'penguin' case that I first mentioned in msg08062.
> I will try to specify more formally what happens in such a case.
>
> Suppose we (the receiving ontology A) know about birds but
> not penguins.
> When we first "hear" about birds from the source ontology B
> and ask for
> the definition (assuming we agree with the definition of all
> attributes
> involved, if not this is a case for recursion) we notice that B.birds
> curiously match our A.bird concept except that they don't seem to fly!
>
> How is it that we are still able to figure out that B.birds are likely
> the same that our A.birds?
> Because when we take the |><| closure of the B.bird thru our FCA
> lattice it maps back to our A.bird!
>
> So we know that something is strange about B.birds even before they
> tell us about penguins, but yet these must be birds.
> Then we create an instance of an hypothetical B.bird in the X set
> of our FCA lattice in order to make the B.bird concept properly
> closed and bind the B.bird name to this new concept.
> If we need a local name for it, just call it a "bird of B".
>
> If B then tell us about 'penguins' we will not be "surprised" and
> will not need to change anything.
>
> But, suppose B now talks about how birds fly (assuming that flight
> is an agreed upon concept), then this means that B is using his
> word 'bird' ambiguously to mean either any bird or only "flying birds"
> and that B *does* have a concept exactly matching our A.bird concept
> but that he did not care to name it.
>
> This is a case for *contextual disambiguation*, NOT a
> conflict of concepts!!!
MW: Yes, but how do you automate this process, except when both "bird"
concepts are defined in terms of the same higher level concepts.
>
> Please notice that all this does NOT rely on the spelling of the
> word 'bird' on either side, so we indeed succeeded in *translating*
> the word 'bird' between the two knowledge domains!
>
> The matching of attributes is going to be more tricky, because it
> implies recognising the *equivalence* of two relations which is
> formally undecidable in a general setting.
>
> But, as usual, practical REAL cases will be solved and a hint about
> how this can happen an even be real fast (not grinding thru the
> theorem prover for hours) is given in msg08252.
>
> The trick is that, with each assertion there must be a proof of the
> consistency of the assertion stated of course within the formalism
> of the originating ontology.
> The proof itself is subject to "translation" under the formalism of
> the receiving ontology, but once this is done, THIS IS A READY MADE
> PROOF of the consistency of the assertion within the receiving
> ontology which has only to be checked with no search involved.
>
> There CERTAINLY are some difficulties remaining to recognise
> equivalence of relations used to define attributes/properties and
> written by different people under different assumptions, because
> this involve having a confluent rewriting system which will give
> the same "canonical" representation to equivalent relations, and
> this is undecidable in a general setting.
>
> But AGAIN (and AGAIN!) how many of
> the REAL cases will be hindered by this?
>
> I hope this gives you a "feeling" about a method for integrating
> independently developed ontologies through some automated process.
MW: I do not believe you have described the automatic integration of
independently devloped ontologies, but only the interoperation of
ontologies that are already implicitly integrated through the use of
common classes (your attributes and properties).
>
> Solving all the details will probably require *hundreds* of pages
> of specifications, but the road is THERE!
MW: I think you need to investigate what it takes to develop the set
of classes (attributes and properties) that you need to do this. I
have been working on this area for some 15 years, and as yet I have
seen no limit to the number of classes you need. Never mind that
the classes and what they mean a different depending on the paradigm
you use.
MW: I should perhaps contribute something positive. I have defined
what I think it takes to achieve integration in an ISO Technical
Specification, ISO TS 18876 - Integration of Industrial Data for
Exchange Access and Sharing (IIDEAS). You can find the Committee
Drafts for Parts 1&2 at http://www.iso18876.org/.
>
> Cheers.
>
> -- Jean-Luc Delatre
> --------------------------------------------------------------
> ----------
> "Curiosity may have killed the cat. But lack of it, is
> killing mankind."
> --------------------------------------------------------------
> ----------
> http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29
>