BFO version with integrated OBO Relation Ontology?

[Stephen Larson]

Hi,

   I've read a lot on the BFO site about the proper use of relations.  Additionally, I've looked at the OBO relation ontology available here:

http://obo.sourceforge.net/relationship/

   It appears that this contains most of the preferred relations to be used with the BFO.

   However, what I can't seem to find is an OWL version of the BFO that combines the two.  Having such an OWL file would have several benefits:

1) It would clarify the proper usage of the OBO relations by codifying them and reduce improper usage.
2) It would encourage the use of the OBO relations with the BFO for those who are still learning about BFO.
3) It would save time for individuals who want to use both and therefore have to reproduce a merged ontology themselves.

   Does such a version of the BFO exist, and if not, can it be constructed and made available?

Thanks,
   Stephen

p.s. Happy New Year!

[Cristian Cocos]

Holger  has such a file (see here: http://www.ifomis.uni-saarland.de/people/holger/index.php), or, at least, he could supply links that you can import in Protégé as metadata.

 

_________________________________

 

"I don't want to achieve immortality through my work. I want to achieve it through not dying." -- Woody Allen

[William Bug]

Hi Stephen,

Is there a specific reason why you wouldn't want to use owl:import to make use of the OBO RO in concert with BFO?

There are many reasons why owl:imports doesn't work well for many distinct activities associated with ontology merging, bridging, integration, etc..  However, in the case of re-using upper level ontological artifacts - especially those expressly kept compact such as BFO & RO, owl:imports seems to work reasonably well.  I must say my experience doing this is relatively limited, so I'd like to know why it might not be advisable to go this route.

Though I'm just a user here, my sense for why BFO & RO have not been integrated are:

1) BFO - the Basic Formal Ontology - is not in any way tied to a specific domain such as biomedicine, though, admittedly, this has been a domain of use which has greatly informed the overall design of BFO.  OBO RO, on the other hand, is an out-growth of the OBO community, and as such, contains relations - and will contain many more - specifically designed for use in the Biomedical domain.  Well - "specifically designed" is probably not the best way to express it.  These relations are designed to be structured in such a way that should and could support use outside of formal, semantic biomedical entity representation.

2) BFO and OBO-RO are the products of two different community efforts.  Though it most definitely preferred they be used in concert with one another, as I indicate above, OBO RO is likely evolve to contain many relations very much specific to the biomedical domain.  As you can see at the OBO site Chris Mungall is the contact for OBO-RO.  Chris works with the Berkeley Drosophila Genome Project and with their Gene Ontology contingent, as well as being directly affiliated with the National Center for Biomedical Ontology.

There has been some discussion on other ontology development lists regarding the need to create a single merged ontological artifact, to facilitate more rapid adoption of the resource and provide some guidance to new developers, but I personally don't feel that need out weighs the reasons for keeping them fundamentally separate.

Having said all this, I would like to make a modification to your original request.  My experience with BFO - and the experience of some of the BFO developers, actually - is there is a need for a thin biomedical context layer built on top of BFO.  Pretty much every biomedical application for BFO needs to create such a generic layer - e.g., biological entity derived as a sub-class of bfo:entity (to contrast with inorganic entities, for instance, many of which will be critical for representation of biomedical experimental details and environmental conditions in general).  Such a generic layer has been created in the context of several BFO-derived projects, though in both cases the resulting ontologies had more specific intended applications than to support ALL use of BFO across the entire biomedical domain (see the articles at Barry Smith's web site discussing the Biodynamic Ontology and the Ontology of Biomedical Reality).

I believe there has been discussion amongst GO & NCBO participants to work on an "Upper Biomedical Ontology (UBO)".  It makes a lot of sense to me UBO would use owl:import to include both BFO.owl and RO.owl.  The reason both should be included via owl:imports as opposed to simply merging BFO & OBO-RO into UBO is BFO & OBO-RO will need to continue evolving and some of that evolution will probably be best done independent from any specific use of these high-level ontologies.  Including them in UBO via owl:imports means any user of UBO will have both BFO & OBO-RO present in their ontology.  Of course the inherent dependencies such a relationship engenders mean those working on UBO would certainly want to be included and informed of any major changes to BFO or OBO-RO, but that's not quite the same as joining them at the hip, so to speak.

I'd really like to hear more from the BFO developers and others regarding their thoughts is on this issue.

Cheers,

Bill

P.S.: As many know, there are other efforts to create an upper ontology for biomedicine - most notably those from U.Manchester (the Simple Upper Bio Ontology - http://www.cs.man.ac.uk/~rector/ontologies/simple-top-bio/) and others derived more directly from DOLCE (e.g., the Bio-Zen ontology produced by Matthias Samwald and his colleagues - http://www.schemaweb.info/schema/SchemaDetails.aspx?id=292).  I hope - as a user - there will be some ongoing attempt to see these efforts don't diverge significantly to the point where large data repositories annotated/described using one of these upper ontologies remain computationally incommensurate with one descriptions derived using the other upper ontologies.  This is not to say their won't be certain aspects of each that will be non-overlapping; otherwise they'd be no reason for the different upper ontologies to exist.  I just hope some effort will be made to provide an bridge for at least those entities and relations intended to be used to describe the same aspects of biological reality.

Bill Bug

Senior Research Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics

www.neuroterrain.org

Department of Neurobiology & Anatomy

Drexel University College of Medicine

2900 Queen Lane

Philadelphia, PA    19129

215 991 8430 (ph)

610 457 0443 (mobile)

215 843 9367 (fax)

Please Note: I now have a new email - Willi...@DrexelMed.edu

[Stephen Larson]

On 1/5/07, William Bug <Willi...@drexelmed.edu > wrote:

Hi Stephen,

Is there a specific reason why you wouldn't want to use owl:import to make use of the OBO RO in concert with BFO?

There are many reasons why owl:imports doesn't work well for many distinct activities associated with ontology merging, bridging, integration, etc..  However, in the case of re-using upper level ontological artifacts - especially those expressly kept compact such as BFO & RO, owl:imports seems to work reasonably well.  I must say my experience doing this is relatively limited, so I'd like to know why it might not be advisable to go this route.

Good point-- I should clarify.  I am also pro-importing.  The specific issue is that the OBO RO only lists the relations themselves.  The merged ontology I'm imagining imports the OBO-RO into the BFO *and* assigns the proper domains and ranges to those relations from the BFO classes.  This last part is not available simply by importing the OBO RO into the BFO--the extra step of assigning domains and ranges is extra information left to the user.

(As an aside, we've had trouble assigning ANY domains and ranges to the OBO RO properties after importing them.  I haven't investigated this further, and it may well be a Protege issue, but it appeared as if the domain and range were "locked" once they were imported into another ontology.  Have others seen this behavior?)
 
Unless I misunderstand something, there exist appropriate domains and ranges for each of the OBO RO relations to be drawn from the BFO.  For example, what can be "part_of" what?  What can be "located_in" what?  Can relations only be defined with domains and ranges at the higher levels of continuant and occurrent, or are there relations that would apply specifically between objects and sites?  This information is already being put out there on the BFO site.

Discussion about the usage of relations is discussed in the BFO manual and several papers on the BFO site such as this one:

http://ontology.buffalo.edu/smith/articles/cornucopia.pdf

What I would like is the connection between the relations and the classes to be summarized from the text and codified.  It saves users the time of having to think about how to use them appropriately and saves the trouble of fixing them after they are misused.

Though I'm just a user here, my sense for why BFO & RO have not been integrated are:

1) BFO - the Basic Formal Ontology - is not in any way tied to a specific domain such as biomedicine, though, admittedly, this has been a domain of use which has greatly informed the overall design of BFO.  OBO RO, on the other hand, is an out-growth of the OBO community, and as such, contains relations - and will contain many more - specifically designed for use in the Biomedical domain.  Well - "specifically designed" is probably not the best way to express it.  These relations are designed to be structured in such a way that should and could support use outside of formal, semantic biomedical entity representation.

 

2) BFO and OBO-RO are the products of two different community efforts.  Though it most definitely preferred they be used in concert with one another, as I indicate above, OBO RO is likely evolve to contain many relations very much specific to the biomedical domain.  As you can see at the OBO site Chris Mungall is the contact for OBO-RO.  Chris works with the Berkeley Drosophila Genome Project and with their Gene Ontology contingent, as well as being directly affiliated with the National Center for Biomedical Ontology.
 

I suppose I am a bit confused then.  Several papers on the BFO site talk about relations right alongside the BFO classes.  From these descriptions it does not appear that the relations being used are any more or less domain-specific than the classes.  While I take your point about the different community efforts, to the extent that papers such as the one I reference above are describing appropriate usages of relations, those appropriate usages ought to be codified in OWL.  If there are a subset of relations that are generic versus some other subset that are domain-specific, then it would still be helpful to separate them out from one another using OWL imports.  But given that some of the relations in the OBO-RO are the same generic relations that are described alongside the BFO in the papers, it seems appropriate to encode those relations in a version of the BFO.

There has been some discussion on other ontology development lists regarding the need to create a single merged ontological artifact, to facilitate more rapid adoption of the resource and provide some guidance to new developers, but I personally don't feel that need out weighs the reasons for keeping them fundamentally separate.

Having said all this, I would like to make a modification to your original request.  My experience with BFO - and the experience of some of the BFO developers, actually - is there is a need for a thin biomedical context layer built on top of BFO.  Pretty much every biomedical application for BFO needs to create such a generic layer - e.g., biological entity derived as a sub-class of bfo:entity (to contrast with inorganic entities, for instance, many of which will be critical for representation of biomedical experimental details and environmental conditions in general).  Such a generic layer has been created in the context of several BFO-derived projects, though in both cases the resulting ontologies had more specific intended applications than to support ALL use of BFO across the entire biomedical domain (see the articles at Barry Smith's web site discussing the Biodynamic Ontology and the Ontology of Biomedical Reality).

I believe there has been discussion amongst GO & NCBO participants to work on an "Upper Biomedical Ontology (UBO)".  It makes a lot of sense to me UBO would use owl:import to include both BFO.owl and RO.owl.  The reason both should be included via owl:imports as opposed to simply merging BFO & OBO-RO into UBO is BFO & OBO-RO will need to continue evolving and some of that evolution will probably be best done independent from any specific use of these high-level ontologies.  Including them in UBO via owl:imports means any user of UBO will have both BFO & OBO-RO present in their ontology.  Of course the inherent dependencies such a relationship engenders mean those working on UBO would certainly want to be included and informed of any major changes to BFO or OBO-RO, but that's not quite the same as joining them at the hip, so to speak.

This is a good suggestion, but I think you probably see now how my request is different from this.  My understanding is that the OBO-RO relations are generic across the BFO classes and do not need to include any domain-specific knowledge in order to use them.  It seems that domain-specific relations ought to be constructed as sub-relations of the OBO-RO relations.  And since domain specific-classes ought to be constructed as subclasses of BFO classes, these two would go hand-in-hand nicely.  But this does not preclude the need to define the appropriate domains and ranges for the OBO-RO relations in terms of BFO classes.
 

I'd really like to hear more from the BFO developers and others regarding their thoughts is on this issue.

Cheers,

Bill

P.S.: As many know, there are other efforts to create an upper ontology for biomedicine - most notably those from U.Manchester (the Simple Upper Bio Ontology - http://www.cs.man.ac.uk/~rector/ontologies/simple-top-bio/ ) and others derived more directly from DOLCE (e.g., the Bio-Zen ontology produced by Matthias Samwald and his colleagues -  http://www.schemaweb.info/schema/SchemaDetails.aspx?id=292).  I hope - as a user - there will be some ongoing attempt to see these efforts don't diverge significantly to the point where large data repositories annotated/described using one of these upper ontologies remain computationally incommensurate with one descriptions derived using the other upper ontologies.  This is not to say their won't be certain aspects of each that will be non-overlapping; otherwise they'd be no reason for the different upper ontologies to exist.  I just hope some effort will be made to provide an bridge for at least those entities and relations intended to be used to describe the same aspects of biological reality.

[Nigam Shah]

(As an aside, we've had trouble assigning ANY domains and ranges to the OBO RO properties after importing them.  I haven't investigated this further, and it may well be a Protege issue, but it appeared as if the domain and range were "locked" once they were imported into another ontology.  Have others seen this behavior?)
  

You can edit the domain and range once you make the OBO RO as the "active" ontology.

 
Unless I misunderstand something, there exist appropriate domains and ranges for each of the OBO RO relations to be drawn from the BFO.  For example, what can be "part_of" what?  What can be "located_in" what?  Can relations only be defined with domains and ranges at the higher levels of continuant and occurrent, or are there relations that would apply specifically between objects and sites?  This information is already being put out there on the BFO site. 
 

AFAIK, the OBO RO is a list of relations, to get to the restrictions, you have to read BFO manually and then read the RO paper manually and then type stuff in yourself.

 

Discussion about the usage of relations is discussed in the BFO manual and several papers on the BFO site such as this one:

http://ontology.buffalo.edu/smith/articles/cornucopia.pdf

What I would like is the connection between the relations and the classes to be summarized from the text and codified.  It saves users the time of having to think about how to use them appropriately and saves the trouble of fixing them after they are misused.  

 

I dont think it has been codified yet. You might be able to get the BFO in OWL from Holger Stenzhorn's site, and the RO in OWL (incomplete, because all that is in Barry Smith's paper is NOT there in the OWL file) but actual operationalization of the BFO + RO that would do:

 

1) It would clarify the proper usage of the OBO relations by codifying them and reduce improper usage.
2) It would encourage the use of the OBO relations with the BFO for those who are still learning about BFO.
3) It would save time for individuals who want to use both and therefore have to reproduce a merged ontology themselves.

 

is yet to happen.

 

Regards,

Nigam. 

[William Bug]

Hi All,

I'm not certain to whom Nigam was responding here, but his replies essentially describe the state-of-the-art as I understand it.

I would also add I completely agree with the concerns being voiced in the entreaties Nigam responds to, but I think the implementation - where these broadly shared, community resources is concerned - needs to be oriented more toward re-usability and modularity - when practical.

The OBO RO article provides great formal depth into the intended use of RO.  However:

1) As the original poster suggests, there is a very urgent need to get that codified not only because it will save time for all users, but also because the likelihood of different formal semantic informatics efforts creating essentially incommensurable definitions for the relations is great

2) OBO RO is a work in progress not only in the sense there is much from that original paper (now 2 years old) yet to be formally encoded in the RO.owl file, but also because there are many relations yet to be added.  Remember the 'B' in OBO stands for 'Bio'.  The several ongoing community biomedical ontology efforts are each likely to define additional relations MANY of which are likely to be generalizable outside the specific domain of anatomy, phenotype, experimental provenance, etc. - but still specific to the biomedical domain.

3) The Upper Biomedical Ontology (UBO) would be very thin, just like BFO, and focus almost exclusively on subsumptive relations and various specific set constraints (class axioms).  As with BFO, it will not be making use of ObjectProperties.  At least, that was BFO as I last saw it.  Maybe the BFO design approach is changing.  This should be done in upper level ontology specifically designed to introduce that level of complexity - an Ontology of Biological Reality (OBR), if you will - to steal liberally from an article by Cornelius Rosse, et al. available at Barry's web site - though what I'm suggesting here is not identical to what they developed for that study.  This sort of modular design is described in articles by Alan Rector, Robert Stevens, et al. and is certainly used in their Simple Upper Bio Ontology.  

4) There is no reason to think given OBO RO's need to supply bioinformaticians with the relations they require that all domain & range specifications will come DIRECTLY from BFO.  I would again say there is a need for an UBO and many relations in OBO RO will ultimately map their domain and range to that level.  There are many reasons why this is the preferred approach to take, I believe, when defining OWL ObjectProperty definitions for OBO RO relations.  This is not to say OBO RO ObjectProperties won't ever link directly to BFO classes.  It most likely will for many - if not the majority - of relations.  However, this will not always be the case.  There will also be mixed situations where a specific property might point to a BFO class to define its range, but point to an UBO class to define its domain - and visa version.  In fact, given this likely requirement, it will be necessary for either BFO, OBO RO, and UBO to be merged into a single ontology OR for each to be developed separately with a fourth ontology layer bringing the 3 together using owl:imports.  I much prefer the latter, and really believe we'll eventually end up in that situation one way or another, because UBO needs to derive from BFO and OBO RO will need to link to both when defining domain and range.  I realize this sounds hideously complex, but I'm fairly convinced it will be necessary to maintain these foundational ontologies as distinct artifacts if they are going to be able to evolve to support the broad and fine-grained semantic representational requirements of a broad range of biomedical informaticians.

5) Though there will be many additional relations added to OBO RO, the individual "domain" ontologies will also be creating ObjectRelations that ARE really limited to their respective domains.  These need to derive from OBO RO relations when appropriate, though often times they will truly be novel and not specializations of an existing OBO RO.

6) This view implies there will be a need for various tools and techniques to effectively inter-link distinct ontological artifacts.  This is a problematic issue, and one that can lead to all sorts of practical problems.  Still, there is a rather extensive literature on the various topics related to ontology merging, bridging, integration, etc.., and I'm certain amongst those many dozen techniques and tools, we'll be able build the required infrastructure.  (See below for some references on this topic).

A picture is worth 1000 words (and I probably have let loose with > 1000 in these last two emails):

[Chris Mungall]

Here is what I propose; I think this is essentially what Bill is
suggesting. I'm going to try and keep technology specific
considerations such as owl import mechanisms out of this, since I
believe we can solve this separately.

Clearly there are certain relations such as part_of that are
applicable across domains. It would make sense to share these at the
BFO level. OBO-RO has tried and tested definitions, so it would make
sense for BFO to use these. However, a domain neutral
representational artefact should not be dependent on a domain
representation artefact, so I would suggest that BFO simply cuts-and-
pastes the definition from OBO-RO (providing provenance to the OBO-RO
paper of course). OBO-RO can then indicate using the appropriate
formalism that obo_ro:part_of is equivalent to or a biologically
specific sub-relation of bfo_ro:partOf. How OBO-RO does this is not a
concern for BFO so let's ignore this for now (I know you're keen to
have this solved Bill but my brain is only capable of tackling one
problem at a time!).

BFO is also free to lift non-definitional documentation from OBO-RO.
These are important for the human users of the ontology. Most of the
comments in OBO-RO are geared towards biologists, but it shouldn't be
too hard to figure out some other example.

Now there are some relations in OBO-RO (for example transformation_of
and derives_from) which are not really domain specific (one can
imagine applications in astophysics for example) yet the current
definitions refer to "biological matter". The definitions here could
potentially be generalised. I think these will have to be dealt with
on a case-by-case basis. OBO-RO is about to undergo some revision in
the area of developmental relations so my recommendation would be to
hold off of on these for now, unless there is a current need for
generalised forms of these relations in other domains.

In future versions of OBO-RO we will have relations involving such
things as evolutionary descent which should probably remain at the
domain specific level.

So I suggest that the Holger and the BFO maintainers take all OBO-RO
relations excluding the problematic ones related to development and
simply replicate these in BFO (I imagine they will want to do this by
putting the relations in a namespace distinct from snap or span, yet
distributed in the same bfo.owl file to get round any circular owl
import dependency issues). If they give me a 2-week heads up before
they release this, I can make sure there is a version of OBO-RO in
owl that references bfo.owl.

Very soon we'll have some more relations in OBO-RO (eg inheres_in)
that can simultaneously be incorporated into BFO. Others (eg
has_function) may be tailored for biology and should presumably be
discussed on this list before incorporation into BFO.

For indicating provenance, BFO could include a dc:source link to
either the pubmed URI for the OBO-RO paper, or even a dc:source link
to the URI of the relation in OBO-RO

A brief word on technological implementation: I think we should be
neutral in this respect, but the enormous elephant in the room here
is the fact that OWL's binary relations are incompatible with an
'endurantist' ontology such as BFO. Would there be interest in having
the primary representation of BFO be in KIF/CommonLogic, and deriving
the OWL from this representation?

Cheers
Chris

> <BFO-UBO-RO-OBR.jpeg>
>
> Here's an even bigger one I put out earlier that gives a sense of
> the overall picture (though, of course, as Nigam mentions, these
> are all still a work in progress). In the figure below, the red
> lines imply subsumptive relations, while the black lines imply the
> sort of dependencies arising from ObjectProperty domain & range
> assignments. Though not explicitly depicted in the diagram below,
> a formalism such as SKOS would be used to link specific lexical
> elements from the lexical repository into the ontologies. Though
> reminiscent of the LUI/CUI structure in UMLS, unlike UMLS CUI
> relations, the ontological graphs are being defined according to a
> very different set of design principles.
>
> <biomed-onto-eco-002.jpg>
>
>
>
> P.S.: Here is a discussion I had recently regarding this issue of
> ontology integration:
>
> Semantically-integrating (bridging/merging/mapping/aligning/
> linking) related ontologies:
> This is a big problem the entire community needs help with. As
> you say, it will likely involve use of Rule-based logic, as well as
> the sort of DLs underlying formalisms such as OWL. Here's my quick
> survey of some of the options. Each have their own application
> space to which they are particularly suited. As I mentioned, the
> emerging OBO Foundry "best practices" being endorsed by NCBO
> members really REQUIRE effective means in which to link modular
> ontology components (both TBox [ontology class & relation axioms]
> and ABox [individual/instance assertions]). Most all of these
> tools are semi-automatic with the degree of automation varying
> according to the difficulty of the merging/integration/mapping task
> and the tool tech specs. My sense is more than one of the
> following will be needed to cover variety of Use Cases
> 1) owl: imports
> 2) class axioms (http://www.w3.org/TR/2004/REC-owl-ref-20040210/
> #ClassAxioms) such as owl:unionOf, owl:complimentOf (http://
> www.w3.org/TR/2004/REC-owl-ref-20040210/#Boolean),
> owl:equivalentClass and instance assertion owl:sameAs and
> owl:differentFrom (http://www.w3.org/TR/2004/REC-owl-ref-20040210/
> #IndividualIdentity). These can be very difficult to use
> effectively and still remain compliant with the OWL-DL constraints
> 3) ObjectProperties - to define complex inter-relatedness,
> hopefully drawing on the relations contained in the evolving OBO
> Relations ontology (http://obo.sourceforge.net/relationship/)
> 4) Contextual OWL (C-OWL) - http://www.cs.vu.nl/~frankh/
> publications.html#KRMed04
> 5) E-Connections - http://www.mindswap.org/2004/multipleOnt/
> 6) Various other projects: PROMPT and Anchor-PROMPT, Chimaera,
> ONtology CompositION System (ONION), Semi-automatic ontology
> Merging and Alignment Tool (SMART), Ontology Alignment Service
> (OAS), Ontology Integration System (OIS), Quick Ontology Mapping
> (QOM), OntoFusion, KAON Reverse (specifically for mapping RDBMS DDL
> models to ontologies), Package-based DLs (P-DL), Distributed DLs
> (DDL), S-Match, HCONE-Merge, MoA, Learning Source Description
> (LSD), Ontology Mapping Framework (MAFRA), GLUE, Lexicon-based
> Ontology Mapping (LOM), Ontology-based Knowledge Management System
> (OKMS), Ontology Mapping Enhancer (OMEN), CROSI Mapping System
> (CMS), OntoMorph (part of PowerLoom), FCA-Merge+TITANIC, HICAL,
> OntoMapO (specific to merging Upper Levels), Information Flow
> Framework (IFF), IF-Map, CAIMAN, ConcepTool, Jannick et al (1998)
> Rule-based algebra for describing ontology encapsulation and
> composition used for semantic query mediation, TOVE Ontology
> Project's Process Interchange Format (PIF), etc. - see also:
>
> 1. Choi N, Song I-Y, Han H: A survey on ontology mapping. SIGMOD
> Record 2006, 35(3):34-41.
> 2. Ding Y, Foo S: Ontology research and development. Part 2 - A
> review of ontology mapping and evolving. Journal of Information
> Science 2002, 28(5):375-388.
> 3. Ding Y, Foo S: Ontology research and development. Part I - A
> review of ontology generation. Journal of Information Science 2002,
> 28(2):123-136.
> 4. Kalfoglou Y, Schorlemmer M: Ontology mapping: The state of the
> art. Knowledge Engineering Review 2003, 18(1):1-31.
> 5. Noy NF: Semantic integration: A survey of ontology-based
> approaches. SIGMOD Record 2004, 33(4):65-70.

[Smith, Barry]

At 10:37 AM 1/6/2007, you wrote:

>to the URI of the relation in OBO-RO
>
>A brief word on technological implementation: I think we should be
>neutral in this respect, but the enormous elephant in the room here
>is the fact that OWL's binary relations are incompatible with an
>'endurantist' ontology such as BFO. Would there be interest in having
>the primary representation of BFO be in KIF/CommonLogic, and deriving
>the OWL from this representation?
>
>Cheers
>Chris

Responding to Chris's elephant.
I would be interested in having a primary representation of BFO be in
KIF/CommonLogic; I am not sure that it should be THE primary
representation, since I am not sure what it means to be THE primary
representation for any ontology, any more.
BS

[Holger Stenzhorn]

Chris (and others),

I subscribe to your idea of integrating the non-problematic relations
directly into BFO.Hence you and me should get in touch quickly - perhaps
best off of this list - and discuss on how to proceed with such an
effort. The two-week period suggested for thinking about this is
naturally fine with me too. So let's stick our heads together!

Actually, I thought already on improving BFO by adding its own proper
relations separate from OBO-RO that directly reflect the BFO classes in
its domain and range definitions (so basically codifying the Cornucopia
paper). Cristian has been working (and I will be tomorrow too) on
implementing some of the the Cornucopia relations for a project here at
IFOMIS but so far not on the direct level of BFO. So this could be added
to a concerted effort to integrate relations directly into BFO. Also,
what has already been mentioned in this discussion before I am
interested in the feasibility of specifying domain and ranges to the RO
relations in the context of the existing BFO classes.

As Cristian pointed out in an earlier mail, I have created already our
own OWL-file containing the OBO-RO relations which is basically a
rewrite/clean-up of your OWL-file. It is different only in that our one
follows proper W3C standard naming conventions (I know, Chris, you do
not like them :-)) and having a IFOMIS namespace (to mark its difference
to your implementation). So no substantial change at all. (BTW: Why do
have "http://www.geneontology.org/owl" as xml:base in your OWL-file
albeit it can not be found at this base? That is a bug, right?)

To declare its provenance I will surely include a dc:source in the BFO
OWL-file after incorporating the relations there: Kudos to the people
who really deserve them! ;-) ...and take a look at
http://www.ifomis.org/obo/ro/1.0 - it's already there since I created
that file.

The implementation idea (KIF/CommonLogic) you are after is
understandable from your point of you (binary relations clash with
"endurantist" ontology, indeed). But can you explain me the application
scenario where you would (and technically could) deploy such a KIF
implementation? As a note: We deploy the OWL-version of BFO and RO in
the context of the development of an application that in turn uses
DL-reasoners and tools.

Bye,
Holger

[Smith, Barry]

At 10:14 AM 1/7/2007, Holger Stenzhorn wrote:
>The implementation idea (KIF/CommonLogic) you are after is
>understandable from your point of you (binary relations clash with
>"endurantist" ontology, indeed). But can you explain me the
>application scenario where you would (and technically could) deploy
>such a KIF implementation? As a note: We deploy the OWL-version of
>BFO and RO in the context of the development of an application that
>in turn uses DL-reasoners and tools.
>
>Bye,
>Holger

There are many successful applications which use first-order
logic-based representations of ontologies for automatic reasoning
purposes (using various kinds of work arounds to cope with
undecidability when it raises its head). However, the important
reason for considering implementations of ontologies in FOL is that
it helps human beings state the ideas clearly at the early stages; if
we enforce strange workarounds from the very start in order to
express our ideas e.g. in OWL DL (and we different groups enforce
different workarounds) then the kind of semantic interoperability
ontologies are designed to support will be beyond our grasp.

The motto is: use a clear and expressive language when building an
ontology, and use the result as a basis for simplifications one needs
for specific application purposes.
BS

[Holger Stenzhorn]

Barry and Chris,

I totally agree with the purpose for employing an expressive modeling
language such as KIF or CL in order to avoid hacks or workarounds that
might be necesarry in OWL. I just only know to little about both KIF and
CL to make sensible comments or judgments. Besides the official
documentation/manuals I was not able to find links to (or at least names
of) the succesful applications you refer to in your reply - so for
learning purposes, could you provide me with some of them? Also does
there exist any open-source editor and/or tool for creating and
processing KIF/CL such as (among others) Protégé or Pellet for OWL?

Thank you very much for your help and advice,
Holger
Smith, Barry schrieb:

[Robert Hoehndorf]

>>>>> "HS" == Holger Stenzhorn <holger.s...@ifomis.uni-saarland.de> writes:

Hi,

HS> purposes, could you provide me with some of them? Also does
HS> there exist any open-source editor and/or tool for creating
HS> and processing KIF/CL such as (among others) Protégé or Pellet
HS> for OWL?

Yes. Theorem provers should process KIF, maybe CL as well. For example
SPASS (http://spass.mpi-sb.mpg.de/) or OTTER
(http://www-unix.mcs.anl.gov/AR/otter/). I use Emacs for editing, but
you could use something like Sigma-KEE
(http://sigmakee.sourceforge.net/).

Rob.

[Fabian Neuhaus]

Holger,
Ontologyworks uses a CL variant as language (although the semantics of
the negation is non-standard).
I heard from people who have used loom and powerloom, but never
actually used it much myself. So I don't know how much it scales. I
would be really interested to hear what you think of it:
http://www.isi.edu/isd/LOOM/PowerLoom/

Cheers
Fabian

[William Bug]

Hi All,

I pretty much agree with everything you say, here, Chris - and the follow-ups from others on the list.  Having BFO and OBO-RO work together to unify this effort is a big plus for all us users!

From my point of view, it's much less critical we decide exactly which technical implementation we choose, than it is we commit to all work together - and just as importantly - do some marketing to promote the result, so as to help address all of the issues Stephen brought up at the outset - all of which are really critical for creating a commensurate ecosystem that can be practically applied to the broadest range of digital, biomedical information - which really must be the long term goal.  

That's not to say all ontological frameworks need or will be commensurate down to the most granular levels - that would be a pointless constraint.  The key as I see it is we strive to shared artifacts and/or be commensurate when representing those upper level entities & relations most - if not all - biomedical investigators would agree upon - e.g., mitochondria are found inside viable eukaryotic cells, voluntary movement in humans requires functional innervation of skeletal muscles, etc..  Many application level ontologies will certainly be full of axioms/assertions applicable only to that application domain, which may or may not be commensurate, but if we have a commensurate foundation, there is at least the possibility for integration, when integration is appropriate and required.

The breakdown of relations between OBO RO & BFO and/or OBO-UBO and/or BioTop and/or Simple Upper Bio Ontology and/or Bio-zen and/or OBR (though I take it the latter is either still born or a newly re-born work-in-progress) sounds sensible.  Certainly, many of the core universal, mereotopological relations belong at the top-most level, and I would leave it to the BFO developers to decide whether they can afford to absorb the task of implementing and maintaining them.  It makes a lot of sense they should be tightly integrated with BFO given the relations (as formally defined in the OBO RO article) depend on the entities as defined in BFO.

The only issue I'd want to add to this discussion is the need to recognize the constraints the user community places on the further evolution of this collection of upper level ontological artifacts.  No group has invested more in creating a policy to mediate a community knowledge resource development process than the Gene Ontology Consortium, I believe, so Chris and his colleagues can provide considerable insight on this task.  As we gradually move out of the early development phase, this user base will need to exert an increasing amount of influence regarding the nature of proposed changes and the means by which they are gradually implemented.

We're certainly all at a very early stage here.  BFO.owl has only been available since late August, 2006, and as Chris and others have mentioned, OBO RO itself - at least what is published at the OBO Sourceforge site, is really only a template - an outline of the formal descriptions given in the RO paper.  As has also been stated here and elsewhere, both the BFO and RO projects have considerable investment of time to plough through the required implementation details, but RO especially doesn't currently show the fruits of those labors.  I assume this has largely been due to the added complexity of addressing relations beyond the pure subsumptive graph and the question of exactly how to implement such relations.  As Chris points out, the fact OWL 1.0 ObjectProperties are limited to encoding binary relations poses a significant impediment in and of itself.

In regards to supporting N-ary relations beyond binary:

1) Will the difficulties that arise when the ecosystem tries to support > 1 fundamental formalism (OWL/RDF and KIF) be worse than having to resort to OWL-Full and RDF alone to create such relations (e.g., - so called "curried" relations implemented either in OWL or RDF - see:

http://foldoc.org/?curried+function

http://esw.w3.org/topic/CurriedFunction

I certainly don't know the answer to this question which clearly needs to weigh the impact of loss of support for certain (possibly most) common DIG reasoners and issues related to scalability and performance.  Maybe others have some experience that can shed light on this issue.

2) Would providing a version of BFO/OBO-RO/BioTop/OBO-UBO in KIF help to better integrate BFO/OBO-RO/BioTop/OBO-UBO with other upper ontologies for biology like the Simple Upper Bio Ontology and aspects of Bio-Zen which derived from DOLCE?

One final question regarding the strategies and mechanisms for bridging, merging, and/or integrating distinct ontological artifacts - have either Mark Musen or Natasha Noy of NCBO/SMI been engaged to assist in exploring the options appropriate for the various forms of inter-ontology linking required?  They have both published a considerable amount on this topic.

Cheers,

Bill

[Nigam Shah]

As far as I know, Mark and Natasha are not on this email list. Also, at this point it is important to disambiguate the different notions of bridging, merging, and/or integrating distinct ontological artifacts.

 

NOTE: A commonly abused word is "aligning" ontologies, which can have any meaning ranging from identifying synonymous terms from 2 different ontologies to defining a term from one ontology in using terms + relationships from other ontologies (i.e. composing or decomposing them depending on your view)

 

"bridging" is usually used to imply the composing/decomposing of a term from one ontology using terms and relations from other ontologies.

 

"bridging" is also used to imply the referencing of relations in an ontology (such as BFO) by other ontologies (such as RO)

 

"merging" is a mix bag implying a little bit of composing, a little referencing, a little synonymy identification and I suggesst it be avoided.

 

"integrating" is equally vague. It could mean referencing, allowing "imports", alignging, decomposing etc.

 

Here is what I suggest:

 

Mapping = the identification of some relationship/s b/w terms from different ontologies.

 

Aligning = the identification of synonymy relationship/s b/w terms from different ontologies.

 

Bridging = the identification of composing relationship/s b/w terms from different ontologies.

 

Referencing = the mentioning/citing of terms from another ontology in an ontology.

 

Merging = the Aligning, Bridging and Referencing terms and relationships from 2 or more ontologies to create one representational artifact.

 

Integrating = the Aligning, Bridging and Referencing terms and relationships from 2 or more ontologies to create a formal language for describing a phenomenon.

 

Inter-ontology linking is one of the above and should be clarified.

 

If people feel it is useful, I can also point to the efforts I am aware of in each of the categories above.

 

regards,

Nigam.

[William Bug]

This is great, Nigam.  Thank you for dipping into these troubled waters to offer some clarity on this issue.

I specifically avoided it, since of the work I've read - and especially in the reviews - there seems to be a lack of agreement of what is what.  All appear to approximately agree on the taxonomic breakdown you provide.  They also clearly state these tasks are NOT equivalent and as you describe entail distinctly different sub-tasks.  However, they don't appear to agree on work usage.

I think its a good idea for those on this group to certainly be clear and come to agreement on which specific linking task is being addressed.  However, we certainly want to make certain we are commensurate with what others across the various C.S. fields who've been working on these issues.  Is it your sense the descriptions can be used to categorize the various mechanisms I cited previously in this thread and are in agreement with the consensus across the several reviews I cited?

Here they are again, just as a reminder:

Cheers,

Bill

On Jan 5, 2007, at 8:10 PM, William Bug wrote:

Semantically-integrating (bridging/merging/mapping/aligning/linking) related ontologies:

This is a big problem the entire community needs help with.  As you say, it will likely involve use of Rule-based logic, as well as the sort of DLs underlying formalisms such as OWL.  Here's my quick survey of some of the options.  Each have their own application space to which they are particularly suited.  As I mentioned, the emerging OBO Foundry "best practices" being endorsed by NCBO members really REQUIRE effective means in which to link modular ontology components (both TBox [ontology class & relation axioms] and ABox [individual/instance assertions]).  Most all of these tools are semi-automatic with the degree of automation varying according to the difficulty of the merging/integration/mapping task and the tool tech specs.  My sense is more than one of the following will be needed to cover variety of Use Cases

1) owl: imports

2) class axioms (http://www.w3.org/TR/2004/REC-owl-ref-20040210/#ClassAxioms) such as owl:unionOf, owl:complimentOf (http://www.w3.org/TR/2004/REC-owl-ref-20040210/#Boolean), owl:equivalentClass and instance assertion owl:sameAs and owl:differentFrom (http://www.w3.org/TR/2004/REC-owl-ref-20040210/#IndividualIdentity).  These can be very difficult to use effectively and still remain compliant with the OWL-DL constraints

3) ObjectProperties - to define complex inter-relatedness, hopefully drawing on the relations contained in the evolving OBO Relations ontology (http://obo.sourceforge.net/relationship/)

4) Contextual OWL (C-OWL) - http://www.cs.vu.nl/~frankh/publications.html#KRMed04

5) E-Connections - http://www.mindswap.org/2004/multipleOnt/

6) Various other projects: PROMPT and Anchor-PROMPT, Chimaera, ONtology CompositION System (ONION), Semi-automatic ontology Merging and Alignment Tool (SMART), Ontology Alignment Service (OAS), Ontology Integration System (OIS), Quick Ontology Mapping (QOM), OntoFusion, KAON Reverse (specifically for mapping RDBMS DDL models to ontologies), Package-based DLs (P-DL), Distributed DLs (DDL), S-Match, HCONE-Merge, MoA, Learning Source Description (LSD), Ontology Mapping Framework (MAFRA), GLUE, Lexicon-based Ontology Mapping (LOM), Ontology-based Knowledge Management System (OKMS), Ontology Mapping Enhancer (OMEN), CROSI Mapping System (CMS), OntoMorph (part of PowerLoom), FCA-Merge+TITANIC, HICAL, OntoMapO (specific to merging Upper Levels), Information Flow Framework (IFF), IF-Map, CAIMAN, ConcepTool, Jannick et al (1998) Rule-based algebra for describing ontology encapsulation and composition used for semantic query mediation, TOVE Ontology Project's Process Interchange Format (PIF), etc. - see also:

1. Choi N, Song I-Y, Han H: A survey on ontology mapping. SIGMOD Record 2006, 35(3):34-41.

2. Ding Y, Foo S: Ontology research and development. Part 2 - A review of ontology mapping and evolving. Journal of Information Science 2002, 28(5):375-388.

3. Ding Y, Foo S: Ontology research and development. Part I - A review of ontology generation. Journal of Information Science 2002, 28(2):123-136.

4. Kalfoglou Y, Schorlemmer M: Ontology mapping: The state of the art. Knowledge Engineering Review 2003, 18(1):1-31.

5. Noy NF: Semantic integration: A survey of ontology-based approaches. SIGMOD Record 2004, 33(4):65-70.

Begin forwarded message:

Semantically-integrating (bridging/merging/mapping/aligning/ linking) related ontologies:

This is a big problem the entire community needs help with.  As  you say, it will likely involve use of Rule-based logic, as well as  the sort of DLs underlying formalisms such as OWL.  Here's my quick  survey of some of the options.  Each have their own application  space to which they are particularly suited.  As I mentioned, the  emerging OBO Foundry "best practices" being endorsed by NCBO  members really REQUIRE effective means in which to link modular  ontology components (both TBox [ontology class & relation axioms]  and ABox [individual/instance assertions]).  Most all of these  tools are semi-automatic with the degree of automation varying  according to the difficulty of the merging/integration/mapping task  and the tool tech specs.  My sense is more than one of the  following will be needed to cover variety of Use Cases

1) owl: imports

2) class axioms (http://www.w3.org/TR/2004/REC-owl-ref-20040210/ #ClassAxioms) such as owl:unionOf, owl:complimentOf (http:// www.w3.org/TR/2004/REC-owl-ref-20040210/#Boolean),  owl:equivalentClass and instance assertion owl:sameAs and  owl:differentFrom (http://www.w3.org/TR/2004/REC-owl-ref-20040210/ #IndividualIdentity).  These can be very difficult to use  effectively and still remain compliant with the OWL-DL constraints

3) ObjectProperties - to define complex inter-relatedness,  hopefully drawing on the relations contained in the evolving OBO  Relations ontology (http://obo.sourceforge.net/relationship/)

4) Contextual OWL (C-OWL) - http://www.cs.vu.nl/~frankh/ publications.html#KRMed04

5) E-Connections - http://www.mindswap.org/2004/multipleOnt/

6) Various other projects: PROMPT and Anchor-PROMPT, Chimaera,  ONtology CompositION System (ONION), Semi-automatic ontology  Merging and Alignment Tool (SMART), Ontology Alignment Service  (OAS), Ontology Integration System (OIS), Quick Ontology Mapping  (QOM), OntoFusion, KAON Reverse (specifically for mapping RDBMS DDL  models to ontologies), Package-based DLs (P-DL), Distributed DLs  (DDL), S-Match, HCONE-Merge, MoA, Learning Source Description  (LSD), Ontology Mapping Framework (MAFRA), GLUE, Lexicon-based  Ontology Mapping (LOM), Ontology-based Knowledge Management System  (OKMS), Ontology Mapping Enhancer (OMEN), CROSI Mapping System  (CMS), OntoMorph (part of PowerLoom), FCA-Merge+TITANIC, HICAL,  OntoMapO (specific to merging Upper Levels), Information Flow  Framework (IFF), IF-Map, CAIMAN, ConcepTool, Jannick et al (1998)  Rule-based algebra for describing ontology encapsulation and  composition used for semantic query mediation, TOVE Ontology  Project's Process Interchange Format (PIF), etc. - see also:

1. Choi N, Song I-Y, Han H: A survey on ontology mapping. SIGMOD  Record 2006, 35(3):34-41.

2. Ding Y, Foo S: Ontology research and development. Part 2 - A  review of ontology mapping and evolving. Journal of Information  Science 2002, 28(5):375-388.

3. Ding Y, Foo S: Ontology research and development. Part I - A  review of ontology generation. Journal of Information Science 2002,  28(2):123-136.

4. Kalfoglou Y, Schorlemmer M: Ontology mapping: The state of the  art. Knowledge Engineering Review 2003, 18(1):1-31.

5. Noy NF: Semantic integration: A survey of ontology-based  approaches. SIGMOD Record 2004, 33(4):65-70.

[Nigam Shah]

Hi Bill,

 

Cant say right off the bat. Will get back to you after I see those reviews. I am not familiar with all of them.

 

Regards,

Nigam.

---

From: bfo-d...@googlegroups.com [mailto:bfo-d...@googlegroups.com] On Behalf Of William Bug
Sent: Monday, January 08, 2007 12:00 PM
To: bfo-d...@googlegroups.com
Subject: [bfo-discuss] Re: BFO version with integrated OBO Relation Ontology?