[Top] [All Lists]

Re: [ontolog-forum] Foundation Ontology Primitives

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
Cc: architecture-ecosystem@xxxxxxx
From: "Cory Casanave" <cory-c@xxxxxxxxxxxxxxx>
Date: Mon, 8 Feb 2010 12:12:32 -0500
Message-id: <4F65F8D37DEBFC459F5A7228E5052044A035F3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


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
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:

   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.




Patrick Cassidy



cell: 908-565-4053



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.


Patrick Cassidy
cell: 908-565-4053


Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>