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.
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.
- 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.
This part is even more "delicate" to setup than the logical framework
because I would not trust "hand-crafting" that part, no more than I
trust the SUO effort.
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.
This means that this "basic concepts" part is likely to be split
between many application domains.
It will be "modular" but with a mostly flat structure not very much
lattice-like, and, BTW, I find it *absolutely* ludicrous to aim this
effort of ontology construction toward anything close to the full
scope of natural languages. Specialised domain ontologies would be
much less worrysome and MUCH MORE USEFULL FOR REAL APPLICATIONS!
Natural language ontology is just a *toy* for the academics...
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.
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.
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.
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!
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).
> 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.
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!
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).
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.
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 |><|.
(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.
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!!!
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.
Solving all the details will probably require *hundreds* of pages
of specifications, but the road is THERE!
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