Ali,
Thanks for the reference to your thesis. I
will try to look through it to see if I can glean more than you have already
presented in the Ontology forum. For the next few weeks I will be
occupied with other tasks, I’ll resume the dialog when I think I have a
complete grasp of your points.
Just to correct one misimpression:
[AH]: > . The
FO doesn't cover anything automatically. If it is somehow broad enough to cover
all possible intended meanings, then it simply means that a mapping might be generated.
You still have to generate the mapping. You are simply mapping into an FO
instead of other modules in the repository. It changes nothing.
Well, yes, it does, if the domain application ontology elements
are logically specified (during construction phase) using only the elements in
the FO. The meanings of all the constituent elements are known, and
the relationships of each element in one ontology using the FO can therefore be
generated automatically, with no need for post-mapping. Of course, if some
domain ontology is originally built without reference to the FO, then it would
have to be subsequently mapped to the FO before the FO can be used for interoperability.
If (1) a practical ontology *could* be built
using only modules in some module repository, and (2) the modules used were
logically consistent, and the terms in the modules were unambiguous across
modules or had clear translations, then a similar functionality to that
provided by the FO would exist, and there would be little difference between
such a modular repository and the FO I imagine. (**IF**)
*BUT* (1) the process for developing the FO
requires that it be agreed to and tested by a large varied group of potential
users showing that it is useful in practical applications. I can’t
see how that process could be avoided for a group of pluggable modules either,
if you want that module repository to be actually used in practical applications.
And
(2) you indicate that the modules may be inconsistent with each
other. That can create big problems in trying to use such a set of
modules. A mapping or integration algorithm may be able to detect
inconsistency, and perhaps there will be some consistent combination of modules
that will actually satisfy the needs of some realistic application.
Unless a serious effort is made to make modules consistent (the kind of effort
that would be made for the FO), I expect that finding a set of modules that satisfies
a need and is consistent would become exponentially harder as the number of
inconsistent groups of modules increase. And ultimately, I would expect
that finding a suitable set of consistent modules will be much less likely than
finding a finite number of semantic primitives. And
(3) For a lot of applications (for example natural language
understanding) I seriously doubt that the modular approach could work, there
are too many interconnections among the basic concepts to modularize them completely.
But why speculate? All we need is some example of how such
a repository actually has been used to compose a practical application, and we
will learn a lot from that.
One example we now have of a practical ontology application is
SIRI. You will note that that application uses a single ontology to unify
the modules. ( though we don’t know the details)
Thanks for the second reference:
[AH] > Sure, check out the FOIS 2010 paper (www.reseed.ca/ali 2nd
paper), a mapping is derived between a very common mereotopology (used to
specify Part-Whole and Connection relations), and Stone Lattices, a result from
mathematics.
This sort of work is very good basic research that can be
used to assist interoperability to some extent. But examples such as the
one in that paper are very, very restricted in scope. The FO tactic can
use mapping algorithms such as the ones you reference, but without a fairly
large common inventory of logically consistent basic elements I seriously doubt
that anything but the tiniest fraction of applications will be relatable by
that tactic alone. Practical applications are very much more complex than
the test cases I have seen thus far in your work.
Pat
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx