SUO: Re: CG: Architectures for Intelligent Systems
Philippe,
Quoting you from: http://mars.virtual-earth.de/pipermail/cg/2002q2/004299.html
> > Then these "basic" concepts (and attributes/properties of the same simplicity)
> > will have to be part of a common "core" ontology, possibly split between ...
>
> > The speed come from the fact that there will be an immediate feedback from
> > any remote ontology when queried about a new "proposed" concept.
>
> Indeed, if you manage to have these last two points, I can now see where the
> centralization lies and hence some similarity between our approaches. However,
> this begs two questions (sorry if you have already answered them):
> 1) how is this common core ontology built? (by whom? with lexical items
> interpretable differently by various persons?)
Anyone!
I am not joking, any user or group of users interested in a given field
could (given they have access to an appropriate tool, see below) decide
that for the purpose of describing concepts in their field they are willing
to provide a "base ontology" of simple and lexically matchable concepts and
attributes and make it publicly available.
The only restrictions that should apply is that each such base ontology is
properly identified with respect to it's source (authors authentification)
and revision level, plus conformity to the "simplicity" of the named concepts.
For this "simplicity" criterion to be met some guidelines will be given
and a set of utilities provided to facilitate the parsing of various
corpus of data in order to build a tree of concepts (ontology like but
not an "operable" ontology in itself) from which to extract the "leaf"
concepts and attributes.
I expect that thru sharing and merging the "best" base ontologies will
take over and, given that those are only for "simple" concept and
attributes *names* with NO controversial meanings attached the consensus
will be reached quite quickly.
This will be another instance of "cooperative" design!
Whenever some ontology need to use one or more such "base" set of names
it will have to advertise in some preliminary protocol handshake the
source IDs and revision numbers of these base ontologies.
Presence of homonyms is NOT a problem given that NO meaning is attached
to a name in such a base ontology, only the fact that this name should
be considered a "leaf" concept for matching purposes and any meaning
is encoded in the specific ontology.
To explain this, assume for instance that two ontologies use the same
"base" set of names and a given name, say 'car' is to be used (not that
simple, but just for the sake of the exemple and this even makes this
more to the point).
When the 'car' word is issued to one of them for the first time, it is
NOT to be assumed that the meaning of 'car' is the same on the other
side in spite of the fact that this is a "leaf" name coming from the
*same* base set of names.
The receiving side A will then ask for the 'car' concept definition from
the sending side B, then, the only difference in processing from a
non-leaf name with respect to what is specified in:
http://suo.ieee.org/email/msg08307.html
will be that the identity of the concepts 'car of A' and 'car of B'
is to be enforced on the A side only (for the moment, until B wants
to know about cars from A) by forcing the merge of the attributes
from both sides into a single "merged" concept.
THIS IS WHERE THE DESIGNERS OF POTENTIALLY INCOMPATIBLE DEFINITIONS
FOR THE SAME WORD SHOULD *AVOID* DECLARING THOSE WORDS AS "LEAF".
This to settle down points like the "meaning" of 'individuals' in
4D based versus 3D based ontologies. In such cases, within each
such ontology the formal definition of the 'individual' concept
will have to be elaborated such as to give the inference engine
the opportunity (if not the *actual* capability, for lack of
power or heuristics) to make an automatic mapping between the
two identicaly named but semantically different concepts.
In case one side has no meaning attached to a "leaf" concept
it will just amount to the equivalent situation in human speech:
"Oh, I heard that once but I have no idea, you just tell me!"
Yes this has to be checked!!! but I am sure that,
even if adjustments are needed, this line of design can make it!
[nit-pickers preemptive strike: if you bothered to read, you may have
noticed that the way I define some words is somehow drifting a bit
from definitions I gave in previous messages, THIS IS A NORMAL
RESULT OF THE DESIGN PROCESS!!!]
> 2) how is the "immediate feedback from any remote ontology" done? In my
> approach, I suggested that competing KB servers are likely to
> try to piggy-back (mirror) from each other, first manually, then automatically.
> What's your idea?
That will always be automatical, except may be for selecting
the "base" ontologies from various sources and revision levels.
With incrementality the *amount* of piggy-backing will depends on
the kind of activity going on between two points.
If the exchanged infos cover only a small part of the ontology from
each side the amount of "mirrored" concepts will be small and cost
litte space.
If there is heavy interaction over the whole range of the ontologies
domains the mirroring will almost equals a duplication in size except
where concepts are actually identical or very close, in which cases
the space used will only be for distinct dictionaries entries
"concept of A", "concept of B" actually pointing to the same or
highly shared sub-trees of the concepts representation.
Could be neat!
Cheers.
-- Jean-Luc Delatre
--------------------------------------------------------------
""We are upping our standards,...so up yours."
- Pat Paulsen for President, 1988.
--------------------------------------------------------------
http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29