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