Pat,
Interesting in that your FO process, below,
is essentially the process I am recommending for better integration of
modeling languages in the architecture ecosystem (http://www.omgwiki.org/architecture-ecosystem/).
In that domain (which includes ontology language as modeling languages) we
have hundreds of redundant concepts represented in different syntaxes. While
each of these languages in interesting in its chosen domain we have failed to
leverage the fact that many of these languages model the same thing (same
enterprise, domain, technology, systems or community). Sine there is
demonstrable business benefit to being able to understand the wider scope of enterprises
or “systems of systems” this could provide an additional value
proposition for FO.
In that the goal is knowledge integration
(where the knowledge, in this case, is architectures) the choice of “primitives”
is not important, as long as it serves to integrate the knowledge. In
fact in many cases it may be more suitable to have some common non-primitives
in the vocabulary to make the mappings more tractable. I have generally called
these “shared concepts”.
So I would suggest that your choice of “input ontologies” include
modeling languages as well as upper ontology. Of course many will complain that
these are not well grounded, which is also what we would like to address. One
of the daemons of such integration efforts in the past has been the tendency to
over-specify and over-couple “primitive” concepts. We have
also not had the appropriate tools to form the primitive concepts into those
that are typically used in user-focused languages. For FO to be useful in
this domain this ability to form these user-focused languages from the
foundational set is crucial.
-Cory Casanave
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Patrick Cassidy
Sent: Thursday, February 04, 2010
1:31 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum]
Foundation Ontology Primitives
A reply to questions
from Ali Hashemi:
[AH] >
The steps in creating an FO consist roughly of the following (correct me
if i'm wrong):
1. Identify candidate ontological primitives, identify
candidate
logical primitives
2. Figure out similarities and differences of candidates
3. Develop mappings between candidates
4. Reach consensus on what are the "-true-" //
appropriate// useful
primitives
Steps 1-3 are in effect, figuring out the mappings between the current
existing Upper Ontologies (assuming they provide adequate cover). Step 4 is
where the FO differs. Making the case to do 1-3 is much easier, and less
risky as it provides immediate tangible benefits to the entire community.
(and subsequently)
>> [AH] You've
suggested a number of times that I've misinterpreted your intuition, yet as far
as I can see, each time you write about the FO, it seems to change its flavour.
I'll abstain from commenting further until the idea has solidified.
> What I am very curious about however - I suggested a number of steps /
benchmarks through which such an exercise might be conducted. You responded
that it is only one interpretation. Might you put forth _your_ interpretation
of how one might go about, step-by-step in formulating such an FO? I
think this would help clarify what you mean to communicate and minimize future
misunderstandings.
OK. I have refrained from describing a
detailed process for development of the FO because the process itself will have
to be **decided on** by the participants in the FO project, at the preliminary
planning stage. The important issue is to get together a group that will
make an attempt to develop a foundation ontology that can support translation
among their ontologies, databases, and applications. To provide
some concrete notion of how the FO project *might*
proceed, I have created one hypothetical process, and include it below.
The danger of suggesting such a process is that it may become another focus for
debate, on a matter peripheral to the main point, i.e. that the best method to
get semantic interoperability is to organize a project that includes
representatives of users who will find the common elements and show how they
can be used to support interoperability among practical applications.
This process below is only one possibility; if parts of it seem to have
problems, keep that notion in reserve and let us know your objections when the
project actually begins planning. Remember that the most important part
of the FO project is to *test* it
using multiple independently developed interoperable applications. I have
added this hypothetical process to the ppt:
http://www.micra.com/COSMO/TheFoundationOntologyForInteroperability.ppt
The section of the ppt
that deals with the overall consortium process for developing an FO is on
slides 60 to 72.
•
The
FO development method will be agreed to by the participants in preliminary
discussions. One possibility is given here. – but a different
method may be chosen
–
Start
with all foundation ontologies (“upper ontologies”) used by
the participants, plus the root concepts in the hierarchies of the domain
ontologies (and database schemas) and all of the relations used in the
ontologies and databases of the participants
–
Determine
which of those are identical in intended meaning, and whether those that appear
to be identical can be organized in a common ontology, allowing alternate means
of expressing the same intended meaning, and providing translations among the
alternate expressions.
–
For
elements that are not identical in meaning, determine whether they can be added
to the base common FO without creating logical inconsistencies.
–
If
logical inconsistencies are detected, determine if the creators/users of the
inconsistent ontologies can agree on a consistent representation adequate
for their purposes; if so, add that to the FO; if not, determine how to
describe their differing elements using the common FO, and add those elements
as parts of mutually inconsistent extensions
to the FO.
–
For
those elements (types and relations) that are not identical in intended
meaning, determine if they can be logically specified (described or expressed)
as combinations of the elements already in the FO. If not, they can be
added to the FO as additional primitives, if so they can be added to a
mid-level or domain extension – or retained in the FO if there are no
objections.
•
The
resulting FO will be the first version, to be tested for its ability to support
interoperability.
•
This
version will be refined as experience by the consortium using the FO in
practical applications demonstrates the need for modification.
And later:
[AH[
> Firstly, if the current 5-6 upper ontologies are
interconnected with appropriate mappings, and new ontologies are extensions of
any of those 5-6, then we have de facto interoperability. This is why I have been
saying that steps 1-3 in "my interpretation" make the subsequent FO
superfluous.
I believe that the
method of trying to recognize semantic primitives is the most efficient method
of developing translations. I say “translations” rather than
“mappings” because the traditional notion of mappings often covers
only parts of the mapped ontologies, doesn’t have a means of converting
formats, and doesn’t guarantee a high level of accuracy in the
conversion. But your project may have all those properties – I do
not know the details. Since there is a large overlap in the intended
result, it is likely that, even if both projects proceed simultaneously, many
of the same people may participate in both. But I do not think from what
I know thus far that either could be substituted for the other.
Pat
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx
Secondly, I have not suggested it is impossible. I have suggested it is
unclear whether it is possible, and more importantly that even if it were, it
would yield limited value, as all the work is in generating those mappings.
Thirdly, I have not suggested the project can be achieved via volunteer work.
Steps 1-3 (in "my interpretation"), depending on the level of detail
and implementation seem like a prime candidate for a Master of PhD thesis.
Lastly, logical compatibility does not guarantee interoperability. You simply
need to know where there is agreement and difference, and if you want to
communicate with a system in another paradigm / UO family, then you must make
the appropriate allowances from your own perspective. Though perhaps this is a
case of us using language slightly differently.
Ali