Proposal for an Official BFO 1.2 Release

[James A. Overton]

Dear Stefan and BFO-OWL developers,

On the last BFO OWL developers' call (2012-11-26), several developers raised concerns about the fragmentation of BFO versions (i.e. 1.1, ruttenberg-bfo2, Graz) currently used by OBO projects, which is causing problems with interoperability. It was suggested that a transitional release of BFO could consolidate improvements already in place and facilitate the transition to BFO 2. We have prepared a proposal for an official BFO 1.2 release that addresses these points (see [1] below).

The proposed BFO 1.2 contains all BFO 1.1 classes. It follows the example of BFO 2 by including high-level relations: all of the relations published in the 2005 Relation Ontology paper and the OBO Relations Ontology (OBO_REL), and a few other widely used high-level relations. Whenever possible, term identifiers from ruttenberg-bfo2 and the BFO 2 Graz release have been used, but we have been careful not to reuse identifiers when there may be a change of meaning. In short, the proposed BFO 1.2 consolidates high-level classes and relations, and updates their identifiers, without making significant changes to the meanings of these terms. This reflects current OBO best-practices and improvements already in place in GO, CL, RO, Uberon, OBI, and other ontologies. Transition to BFO 1.2 would help us to debug technical problems in our ontologies and applications before making the deeper ontological changes in BFO 2.

The proposal has so far been vetted by Chris Mungall, Bjoern Peters, Jie Zheng, Philippe Rocca-Serra, Alejandra Gonzalez-Beltran, Allen Xiang, and Oliver He. Alan has also seen it and has raised some concerns that we believe we have addressed (see [2] below).

We request that BFO 1.2 be made an official release. We are happy to address questions and objections on the mailing list, and will work to address any concerns. We have endeavoured to make this proposal as uncontroversial as possible, so that it can be implemented quickly and move us closer to the many benefits that BFO 2 will bring.

Best regards,

James


James A. Overton, PhD
http://james.overton.ca


[1]: The proposal can be found at: https://docs.google.com/document/d/1QQsfTtzclBrW7PxMdyRGsaQ7pQZIYVkShgVRP5f4VNo/edit

FAQ: https://docs.google.com/document/d/1BDFMmOxVRGtUkdT0l_ps1Hf4SR7uDi3md8zfNXyS_GM/edit

Mappings and experimental OWL files are available. IMPORTANT: Many of the term identifiers are temporary, and should ONLY be used for evaluating the proposal.

https://docs.google.com/spreadsheet/ccc?key=0AnbOUYWIQYUEdF9yb0hlUjhBUGRnVWNTVFJQX0xOUlE

https://github.com/ontodev/bfo

[2] Alan Ruttenberg has seen the proposal, and encouraged us to present it to the wider BFO community, but he has several reservations. Two of his concerns are that:

1. two transitions (from 1.1 to 1.2 and then 1.2 to 2.0) will be more difficult than a single 1.1 to 2.0 transition
2. this will slow the transition to BFO 2

We disagree. We have designed our proposal to make the transition from BFO 1.1 and ruttenberg-bfo2 to BFO 1.2 very easy (details below). By making this transition first, OBO projects will be able to debug any problems with identifiers and imports, confident that the meanings of terms have not significantly changed. With identifiers and imports updated, debugged, and synchronized across OBO projects, it will be easier to test and implement BFO 2, which involves new terms with new meanings. We have designed the proposed BFO 1.2 to smooth the transition to BFO 2, and we sincerely hope that it will ultimately speed the transition of current OBO projects to BFO 2.

Transition to an official BFO 1.2 would be straightforward. The proposed BFO 1.2 has been designed to be very close to ruttenberg-bfo2, and in our tests it was simple to update ontologies that currently use ruttenberg-bfo2. Chris Mungall expects it to be simple to update the tools for processing OBO format ontologies. Allen Xiang has developed a tool for automatic conversion of OWL files from BFO 1.1 to BFO 1.2 (http://bfoconvert.hegroup.org/). The proposed BFO 1.2 reflects changes already in place in many OBO projects, and we believe it will be straightforward to update any OBO project to BFO 1.2.

[Bill Hogan]

I am in favor. For those for whom a single transition to BFO 2.0 is
less effort than sequential 1.1 -> 1.2 then 1.2 -> 2.0 transitions,
they can just skip 1.2 and go directly to 2.0. So no harm done.
There is no requirement to make two transitions.

On the flip side, it enables folks to start using the new identifiers
sooner and without having to do all the work of going to 2.0. And it
affords the convenience of having the classes and relations in one
ontology.

One downside is that you will be creating identifiers that very soon
will be obsoleted. Nothing immediately comes to mind as to serious
downstream consequences of that.

Bill

On Tue, Jan 8, 2013 at 8:23 AM, James A. Overton <ja...@overton.ca> wrote:
> https://docs.google.com/document/d/1QQsfTtzclBrW7PxMdyRGsaQ7pQZIYVkShgVRP5f4VNo/edit

[Melanie Courtot]

I am mainly concerned about having so many versions of BFO co-existing. My main issue as a user at the moment is that different resources are at different stages of adoption. Some are still under BFO 1.1, some adopted bfo-ruttenberg, some switched to BFO2. The direct consequence (which many of us experienced) is that importing multiple resource which are themselves importing different BFO versions is a huge mess.
Throwing in another version will make things worse.

Cheers,
Melanie

> --
> You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
> To post to this group, send email to bfo-d...@googlegroups.com.
> To unsubscribe from this group, send email to bfo-discuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bfo-discuss?hl=en.
>

---
Mélanie Courtot
MSFHR/PCIRN Ph.D. Candidate,
BCCRC - Terry Fox Laboratory - 12th floor
675 West 10th Avenue
Vancouver, BC
V5Z 1L3, Canada

[Bjoern Peters]

Hi Melanie, 

That is a relevant concern, but actually, the new release was developed specifically to address it. Based on our testing so far, it should be straightforward to transition from any of the versions you had mentioned to BFO 1.2 (often fully automatically using the mapping tool). While it seems schizophrenic to address the proliferation of versions by adding a new one, there is really no other alternative (except for BFO2 being ready now and transition to be effortless :) ). 

So while I understand your concern, I really hope you will support our effort to address the existing version incompatibility issues with this new release. 

Best, 

Bjoern

---

Bjoern Peters
Assistant Professor
La Jolla Institute for Allergy and Immunology
9420 Athena Circle
La Jolla, CA 92037, USA
Tel: 858/752-6914
Fax: 858/752-6987
http://www.liai.org/pages/faculty-peters

[Alan Ruttenberg]

For the record, find below the response I gave when I was approached about this a couple of weeks ago. In summary I see little, if any benefit to our user community, with substantial disadvantage to to the additional churn introduced by releasing a version with important parts known to be obsolete on publication, when we are rather close to a release of BFO2. I see that Chris is seeming to say that there is already a BFO 1.2 he has made for the OBO translation. Once again I register objection to unsanctioned "releases" due to the confusion that they engender. Finally, among other objections, I also do not support any release that doesn't bother to include definitions or elucidations for all terms, given our emphasis on this in the Foundry.

Regards,

Alan 

Hi James,

I guess my feeling is similar to what it has been for other proposals of this sort (though none as thoroughly documented as yours - good job!). It seems to me that doing this will be introducing many terms that will become obsolete, and without adequate benefit for users pain in changing URIs. This particularly because BFO2 is in reasonably good shape. By that, I mean that I think the delta from BFO2 now to BFO2 final will be much smaller than the delta between BFO 1.2 and BFO 2. But the shift from BFO 1.1 to BFO 1.2 will be as almost as painful as a shift from BFO 1.1. to BFO 2. I know you advertise that 1.2 will have many obsolete terms, and that's better than not advertising it. But I think it will hurt a lot nonetheless and make it less likely that people will use BFO and BFO2 in the long run. 

Please understand this as my opinion, and of course not binding. A decision to do something along these lines would be made by the bfo developers group. 

I believe that there is a single major objection to BFO2 OWL and this has to do with the status of rigid versus non-rigid classes. I understand that there are complications with the temporalized relations and in particular the temporalized (and continuant/occurrent distinguished) part of relation. However I haven't heard complaints that they are wrong, nor have I heard defense of the currently uninterpretable relations that really are time dependent. 

That said, my choice would be to move to BFO2 graz with possibly minor revisions, noting the outstanding issues. To my mind this would bring substantial benefit for the pain of change, whereas I don't think the pain involved in a change to 1.2 would be considered justified. OBI is in a good position to make this move. 

Perhaps if a better case for the benefits of this change were made I might think otherwise, so if you want to feel free to make the case.

However if you don't agree with me you should immediately bring this up as an issue to the bfo-devel and bfo-owl-devel lists as that will engage a more representative set of people who would be involved in making the decision.

Best,

Alan

[Chris Mungall]

Yes, many ontologies (GO, CL, ENVO, RO, various anatomy ontologies) are effectively using BFO1.2 already. There is no transition required. 

[Chris Mungall]

Hi Alan,

I don't understand this sentence:

"I see that Chris is seeming to say that there is already a BFO 1.2 he has made for the OBO translation"

[Albert Goldfain]

As was stated earlier in the thread there will be some pain in either the 1.1 -> 1.2 or 1.1 -> 2.0 migration. This will range from minor nuisance (new URIs) to careful thought (temporalized relations) to deep scrutiny (proper use of process profiles). To Alan's point, going all the way to 2.0 might be best since it gets all the pain out of the way in a single band-aid pull (so to speak).

In my opinion, what matters most is how subsequent releases after 2.0 will be released.  I'm a  big fan of time-based releases (one of the gems of the Ubuntu Linux community http://wiki.ubuntu.com/TimeBasedReleases ). For example, we say whatever is in the repository on Nov 1 MUST BE the BFO 2.1 release (so everyone is incentivized to button it up)...but perhaps this is too much like a fiscal cliff :-)

AG

[Melanie Courtot]

Hi Bjoern,

Thanks for the reply. I guess I fail to see how having that additional BFO version will address the issue. The problem I had in my own project (and which was similar to what Jie and others described at the time) is that I import several resources. Each of these resources in turn import BFO - unfortunately not always the same version. Unless all those resources switch to BFO1.2, I am still going to be faced with the same problem. And I will have the same issue when BFO2 is being officially released, as I will have to deal with a transition BFO1.2 towards BFO2.
As I believe that BFO2 is not that far away, I am in favour of giving it a little bit of time and do the switch once, in an (hopefully somewhat) coordinated fashion, rather than depend on two successive transitions. Actually I am in favour of people who spent the time developing BFO1.2 (and are very knowledgeable about BFO) to help push out BFO2 :)

Regards,
Melanie

On 2013-01-08, at 11:00 AM, Bjoern Peters wrote:

> Hi Melanie,
>
> That is a relevant concern, but actually, the new release was developed specifically to address it. Based on our testing so far, it should be straightforward to transition from any of the versions you had mentioned to BFO 1.2 (often fully automatically using the mapping tool). While it seems schizophrenic to address the proliferation of versions by adding a new one, there is really no other alternative (except for BFO2 being ready now and transition to be effortless :) ).
>
> So while I understand your concern, I really hope you will support our effort to address the existing version incompatibility issues with this new release.
>
> Best,
>
> Bjoern
>
>
>

[He, Yongqun]

I can see pros and cons from both strategies. It appears BFO 1.2 is already there. So we have many BFO versions already, at least including: 1.0. 1.1, 1.2, and 2.0.

Maybe a voting process (or some other process) is good to go for making a final decision:-) Once we decide, it would be better for all of us to follow, so everyone can be on the same page.

No matter which strategy to use, one bottleneck is how we can transfer BFO from one version to another in a specific ontology. To facilitate this transferring, with many helps from Jie and James and me, Allen in my group has developed a tool called BFOConvert to support the conversion between different BFO versions:
http://bfoconvert.hegroup.org/

We have tried to be inclusive:

-- Convert an ontology using BFO 1.0 or BFO 1.1 to a new one using the proposed BFO 1.2:
http://bfoconvert.hegroup.org/index.php

-- Convert an ontology using BFO 1.1 as top ontology to a new one using BFO 2.0:
http://bfoconvert.hegroup.org/bfo2.0/index.php

If we can decide one way or the other, we can use this tool to make the transfer go more smoothly.

Any suggestions and comments on the tool development are welcome and appreciated!

Oliver

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

[Bill Hogan]

i.r.t. = in response to (as opposed to @, which I take to mean I am
talking only to that person).

i.r.t. Melanie: The problem you describe would be exacerbated, but
not caused by a BFO 1.2. Multiple versions now and going forward will
always be an issue. However, the primary issue I have encountered
with the multiple BFO imports is the change in URIs. That problem
would not exist if two imported ontologies imported BFO 1.2 and BFO
2.0. Because it will be less pain to go from 1.1 -> 1.2 than 1.1 ->
2.0, more ontologies might use the new URIs, potentially easing at
least this one major problem with multiple imports.

i.r.t. Alan and Chris: the "pseudo-BFO 1.2" mentioned by you and
others is this one, right? http://purl.obolibrary.org/obo/bfo.owl.
This one is essentially 1.1.1 with new URIs.

i.r.t. Alan: you state much more clearly the broad implications of
what I said about releasing something already known to be obsolete.
This is a good point, and a downside to a 1.2. However, few if any
ontologies I've seen extend or otherwise use many of the obsoleted
terms.

i.r.t. Albert: a time-based release is an interesting idea of enough
merit to consider further at least.

i.r.t. Oliver: software tools to help ease any transition are always
welcome. We may try these out if we have time.

Bill

[James A. Overton]

Hi Melanie,

We hope that all OBO projects will update to 1.2, unless they're already using BFO 2.0 Graz. We're willing to help them do it.

The problem you describe is exactly what we've been facing with OBI. We switched to ruttenberg-bfo2 a year ago, with the expectation that BFO 2.0 would soon be ready and that this change would help us prepare. Some of the ontologies we depend upon also made this change, while others didn't. We were left in a difficult position and it's slowing the development of OBI.

Compatibility between ontologies using BFO 1.2 and BFO 2.0 is designed to be good -- much better than the current state of affairs. With BFO 1.2 we can more easily test development versions of BFO 2.0, and then implement it when it's released.

At the beginning of December I wanted to figure out which ontologies are using which versions of BFO. Using Ontobee I discovered that a significant number of ontologies are already using the new IDs -- results are below. We want to consolidate on the new identifiers, and to do it sooner rather than later.

I see this as an opportunity to develop and debug OBO best-practices for upgrading our upper-level ontology. We haven't done anything like this before, but we'll have to do it again at some point in the future. There are clear benefits to doing it well and keeping our upper-level ontology in sync across the OBO library. I think we're better off starting small with a transition to BFO 1.2 before making the leap to BFO 2.0.

Best regards,

James


Ontobee now provides a "Ontologies that use the Class" section at the bottom of pages for terms, which will be more up-to-date than these results.

http://www.ifomis.org/bfo/1.1#Entity
1. Information Artifact Ontology
2. Ontology for General Medical Science
3. Ontology of Medically Related Social Entities
4. Influenza Ontology
5. eagle-i resource ontology
6. Interaction Network Ontology
7. Brucellosis Ontology
8. Chemical Information Ontology
9. NIF Gross Anatomy
10. Infectious disease
11. Ontology for Parasite LifeCycle
12. NIF Cell
13. ARG clinical encounter module
14. Oral Health and Disease Ontology
15. Reagent Ontology

http://purl.obolibrary.org/obo/BFO_0000001
1. Basic Formal Ontology
2. Adverse Event Reporting Ontology
3. Vaccine ontology
4. Ontology of Adverse Events
5. Relation ontology (dev)
6. OBI web service, development version
7. Oral Health and Disease Ontology
8. Ontology for biomedical investigations

The other 84 ontologies in Ontobee don't seem to use BFO.

Then I checked for the new and old "has_part" relations:

http://www.obofoundry.org/ro/ro.owl#has_part
1. Information Artifact Ontology
2. Suggested Ontology for Pharmacogenomics
3. Influenza Ontology
4. eagle-i resource ontology
5. Ontology of Adverse Events
6. Interaction Network Ontology
7. Brucellosis Ontology
8. Chemical Information Ontology
9. NIF Gross Anatomy
10. Infectious disease
11. NIF Cell
12. ARG clinical encounter module
13. microRNA Ontology
14. Software ontology
15. Oral Health and Disease Ontology
16. Reagent Ontology

http://purl.obolibrary.org/obo/BFO_0000050 (ruttenberg-bfo2 and RO)
1. Basic Formal Ontology
2. Fission Yeast Phenotype Ontology
3. Ontology for biomedical investigations
4. Zebrafish anatomy and development
5. Adverse Event Reporting Ontology
6. Vaccine ontology
7. Drosophila gross anatomy
8. Plant Ontology
9. uberon_collected_metazoa
10. Porifera Ontology
11. Uber anatomy ontology
12. OBI web service, development version
13. Oral Health and Disease Ontology
14. Vertebrate Skeletal Anatomy Ontology
15. Teleost Anatomy Ontology
16. Hymenoptera Anatomy Ontology
17. Ontology of Adverse Events
18. Gene Ontology

[James A. Overton]

Hi Melanie,

One more, smaller point: I already see a lot of value in the work done on BFO 1.2. In particular, we've documented a wide range of relations and thought carefully about how they should or should not map into BFO 2.0. Whether we do the transition to BFO 2.0 in two smaller steps or one giant leap, we will need to be clear about these mappings. And we will need to document (in one place) the reasons why so many published terms are now obsolete.

I consider BFO 1.2 an essential step toward BFO 2.0, and I consider the time we've spent on this proposal to be time spent working toward BFO 2.0.

Thanks for your thoughtful comments -- they're much appreciated!

James

On 2013-01-08, at 4:12 PM, Melanie Courtot <mcou...@gmail.com> wrote:

[Colin Batchelor]

Hello,

While in principle I don't like to see the proliferation of different versions, I think a tidied version of BFO 1.1---the BFO 1.2 proposed here---would be very helpful, simply because I don't believe BFO 2 is going to be released any time soon.

Best wishes,
Colin.
A firm believer that the best is the enemy of the good.

[Mathias Brochhausen]

Hi,

1. I see and understand Alan's concerns.

2. However, I mostly agree with Colin that BFO 2 will not be released anytime soon. While BFO 2 provides some things that were asked for by users (process profiles), it does so by providing a complete re-adjustment of BFO and (at least in part) it's underlying theory (philosophy, if you like that better). Therefore, the development of BFO 2, so far, has already spawned tremendous discussion. I see, a danger of releasing BFO 2 soon without reaching at least a basic agreement and loosing users (and I mean more that just 1 or 2). I know that the discussion of BFO has taken quite long already, but I foresee that it will take longer, one reasoning being that most of the effort (like reviewing and discussing) is done on a volunteer basis and in our own time and (even for a philosopher) the issue have become quite complicated. I think that the developers in Buffalo have more chance to discuss BFO among each others and thus, might feel more comfortable with it, but I doubt that there can be a release soon.

So, in sum: I am in favor of 1.2. 

Best,

Mathias

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/bfo-discuss/-/f6VeHAeg_LoJ.

[Alan Ruttenberg]

I'm not sure why there is a feeling that there will not be a release of BFO 2. 

In fact we've *had* a release for comments and have given 6 months for this group as well as the ICBO and Buffalo ontology groups to respond. if there is any feeling that this was not adequate then my fears about a release 1.2 setting us back appear even more well-founded. 

Aside from process profiles, which I do not believe to have wide support, there is little new regarding BFO. The biggest changes have to do with making the OWL representation be more closely in agreement even with BFO 1, which already had temporalized relations in the theory. 

If it were my choice we would release BFO 2 taking into account any feedback we can, by the end of this month. I don't see any reason that is compelling enough to prevent that. We can then work to make real progress, instead of what I see as illusory progress offered in the proposal for BFO 1.2. 

-Alan

[Alan Ruttenberg]

-Alan

On Jan 8, 2013, at 4:59 PM, Bill Hogan <hog...@gmail.com> wrote:

> i.r.t. = in response to (as opposed to @, which I take to mean I am
> talking only to that person).
>
> i.r.t. Melanie: The problem you describe would be exacerbated, but
> not caused by a BFO 1.2. Multiple versions now and going forward will
> always be an issue. However, the primary issue I have encountered
> with the multiple BFO imports is the change in URIs. That problem
> would not exist if two imported ontologies imported BFO 1.2 and BFO
> 2.0. Because it will be less pain to go from 1.1 -> 1.2 than 1.1 ->
> 2.0, more ontologies might use the new URIs, potentially easing at
> least this one major problem with multiple imports.
>
> i.r.t. Alan and Chris: the "pseudo-BFO 1.2" mentioned by you and
> others is this one, right? http://purl.obolibrary.org/obo/bfo.owl.

No. Did you open and look at it? It is the BFO 2 release for comment that we showed at ICBO, and has fairly extensive documentation, including term an property definitions or elucidations, clarity on its status, and reference to release notes.

> This one is essentially 1.1.1 with new URIs.
>
> i.r.t. Alan: you state much more clearly the broad implications of
> what I said about releasing something already known to be obsolete.
> This is a good point, and a downside to a 1.2. However, few if any
> ontologies I've seen extend or otherwise use many of the obsoleted
> terms.

The 1.2 proposal *introduces* terms that will become obsolete when 2.0 is released, namely all the properties that are time-dependent, such as part_of, which is given a new URI - legitimizing it despite it being uninterpretable for continuants.

[Mathias Brochhausen]

I am not aware that I claimed there will be no release of BFO2 at all.

[Alan Ruttenberg]

You said that it won't be released any time soon, which is what I was responding to. 

Alan

[Mathias Brochhausen]

Yes, I believe that. (Well, actually I know you can release it any day, but you read my concerns).

I just want it noted that I did not say there will not be a release of BFO2 (which it seems to insinuate in your e-mail). Sorry, if I misread that.

Sent from my iPhone

--

[Chris Mungall]

On Jan 9, 2013, at 6:54 AM, Alan Ruttenberg wrote:

I'm not sure why there is a feeling that there will not be a release of BFO 2. 

In fact we've *had* a release for comments and have given 6 months for this group as well as the ICBO and Buffalo ontology groups to respond. if there is any feeling that this was not adequate then my fears about a release 1.2 setting us back appear even more well-founded. 

Aside from process profiles, which I do not believe to have wide support, there is little new regarding BFO. The biggest changes have to do with making the OWL representation be more closely in agreement even with BFO 1, which already had temporalized relations in the theory. 

I think it makes sense to be separate BFO from BFO.owl. Yes, it's true that other than process profiles there is not much difference between 1 and 2. But there is a big jump between the corresponding owl artefacts, with BFO2 choosing to be more faithful to the underlying theory by way of temporalized relations. This is a big change, and the temporalized relations introduce questions that have (AFAIK) yet to be resolved regarding non-rigid classes. I'm still unsure if these are even allowed with a BFO2 aligned ontology,.

[Alan Ruttenberg]

On Wed, Jan 9, 2013 at 11:56 AM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Jan 9, 2013, at 6:54 AM, Alan Ruttenberg wrote:

I'm not sure why there is a feeling that there will not be a release of BFO 2. 

In fact we've *had* a release for comments and have given 6 months for this group as well as the ICBO and Buffalo ontology groups to respond. if there is any feeling that this was not adequate then my fears about a release 1.2 setting us back appear even more well-founded. 

Aside from process profiles, which I do not believe to have wide support, there is little new regarding BFO. The biggest changes have to do with making the OWL representation be more closely in agreement even with BFO 1, which already had temporalized relations in the theory. 

I think it makes sense to be separate BFO from BFO.owl. Yes, it's true that other than process profiles there is not much difference between 1 and 2. But there is a big jump between the corresponding owl artefacts, with BFO2 choosing to be more faithful to the underlying theory by way of temporalized relations. This is a big change, and the temporalized relations introduce questions that have (AFAIK) yet to be resolved regarding non-rigid classes. I'm still unsure if these are even allowed with a BFO2 aligned ontology,.

I agree there are issues. But these issues are less so than the ones that currently exist. Therefore I proposed that we release 2.0 documenting the issue and try to resolve it over time. I don't think this uncertainty justifies the pain of an additional planned-to-be-obsolete version.

-Alan

[Bjoern Peters]

I simply fail to see what the significant " pain of an additional planned-to-be-obsolete version" is. It is a stepping stone, that will make the 2.0 transition easier, because the transition to 1.2 can be fully automated, and then it will make obvious which terms will be obsolete in 2.0 (and therefore need more careful thought in transitioning) vs. those that can be left the same. Call it a 'transitional release' for an 'optional upgrade path' if that makes you happy. I will also call it an 'insurance policy if 2.0 OWL is not released by the end of the month. 

More important point: Does the BFO team have a process to decide on whether the 1.2 release should be made or not? If there is no clear process: Alan mentioned pain for the BFO user community several times as a main reason for not wanting to push that out. Can that user community be polled as a way to decide? 

Best, 

Bjoern

---

[Alan Ruttenberg]

On Wed, Jan 9, 2013 at 1:08 PM, Bjoern Peters <bpe...@liai.org> wrote:

I simply fail to see what the significant " pain of an additional planned-to-be-obsolete version" is. It is a stepping stone, that will make the 2.0 transition easier, because the transition to 1.2 can be fully automated, and then it will make obvious which terms will be obsolete in 2.0 (and therefore need more careful thought in transitioning) vs. those that can be left the same. Call it a 'transitional release' for an 'optional upgrade path' if that makes you happy. I will also call it an 'insurance policy if 2.0 OWL is not released by the end of the month. 

The pain in announcing a new version to the world (which hasn't been done yet) is that it takes a significant effort ontologies to be reworked and there is a long path to universal uptake. By releasing 1.2 we say we start that process. That's not something that you start again a month or two later. 

Adjusting URIs is pain. OBI is one thing. I would hazard a guess that most users, holding off for a real release to put in the effort, will be pissed off if two months later (or even 6) we tell then the new URIs we just told them to use should be replaced again. Is it possible that your desire for what you want for OBI is blinding you to the situation as it would be perceived by the larger outside world?

 

More important point: Does the BFO team have a process to decide on whether the 1.2 release should be made or not? If there is no clear process: Alan mentioned pain for the BFO user community several times as a main reason for not wanting to push that out. Can that user community be polled as a way to decide? 

I've worked *very* hard for there to be a modicum of process around BFO2. There are open mailing lists issue trackers, and more documentation then there has ever been. What we have here is a proposal by a group who has not been part of that BFO development process (and not for lack of invitation), pushing forward something that hasn't even been on the table for the people who have been working on this. So let's be a little gentler about making points about process. Start with RTFM and by submitting an issue, as is our documented process.

The answer is that we have a working group, a chair, and meetings in which we make decisions. All this has been recorded and can be found in mailing list archives, in the repository, and in linked google docs. Go to our home page. http://code.google.com/p/bfo. You will, for instance, see a link on the left "featured" section: How_we_record_issues_and_resolutions. 

We have a meeting coming up. I'm sure this proposal will be a matter for discussion. 

Regards,

Alan

[Alan Ruttenberg]

On Wed, Jan 9, 2013 at 6:17 PM, Alan Ruttenberg <alanrut...@gmail.com> wrote:

Does the BFO team have a process to decide on whether the 1.2 release should be made or not?

Please also see http://code.google.com/p/bfo/wiki/Proposal_for_how_we_manage_OWL_Reference_coordination

Including what are temporally qualified properties in BFO Reference, and having the OWL versions of these properties not have a mapping to the BFO Reference would be contrary to the first principle. So on a pure matter of process this is a simple decision, one that is supported by documentation explicitly approved by the working group.

-Alan 

[James A. Overton]

Bill: I believe that Chris and Alan were referring to ruttenberg-bfo2:

http://purl.obolibrary.org/obo/bfo/2010-05-25/ruttenberg-bfo2.owl

In reply Alan's point about BFO 1.2 "introducing" terms: we have not created any terms that were not previously published, and we have used existing IDs whenever possible. But we do want to "legitimize" these terms, for strong pragmatic reasons.

"part_of" is a good example. I agree with Alan that the term is broken, but it's very widely used. It was assigned an OBO standard ID in ruttenberg-bfo2 and RO:

http://purl.obolibrary.org/obo/BFO_0000050

A SPARQL query on Ontobee shows that this IRI is used more than 125,000 times in 19 ontologies [1]. This is far more uses than any of the term's older IRIs. But this "illegitimate" IRI resolves to a "404 Term Not Found" error page on Ontobee.

For the benefit of current and future users of OBO annotated data, this IRI (and others like it) should resolve to a page that documents the term, along with its problems, and suggests replacements.

Since there's a need to legitimize these IRIs, it makes sense to do it in the context of an official BFO 1.2 release that combines all the BFO 1 era upper-level classes and relations.

James


[1] This query (http://www.ontobee.org/sparql/index.php) is somewhat naive, but it captures the RDF representations of OWL restrictions such as "has_part some foo":

prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix owl: <http://www.w3.org/2002/07/owl#>
SELECT ?graph_uri count(?s)
WHERE { GRAPH ?graph_uri
{ ?s ?p <http://purl.obolibrary.org/obo/BFO_0000050> }

[James A. Overton]

Alan's point about transition pain is important, and we've tried hard to address it by developing tools and running tests.

Our tests show that updating an OBO project's identifiers and imports to BFO 1.2 (with the help of automated tools) should only require a few hours of work from one technical person. The immediate benefit is easier imports from other BFO 1.2 ontologies and a direct path to testing BFO 2.0 development releases.

Upgrading an OBO project to BFO 2.0 (even with the help of semi-automatic tools, and setting aside process profiles) can be expected to require many hours of careful thought and discussion by domain experts, and then testing of the consequences of new modelling. This is a major investment, but I'm confident that it will pay off.

We think that a transition to the proposed BFO 1.2 can be accomplished quickly, and we're willing to provide technical support to make it happen. It would make the transition to 2.0 easier from a technical standpoint. It would make it easier for projects to test development versions of BFO 2.0, and perhaps upgrade to 2.0 incrementally. But more importantly, I think that a simple and successful 1.2 transition would build confidence and momentum for the BFO 2.0 transition.

James

[Bill Hogan]

On Wednesday, January 9, 2013, Alan Ruttenberg wrote:

On Wed, Jan 9, 2013 at 1:08 PM, Bjoern Peters <bpe...@liai.org> wrote:

I simply fail to see what the significant " pain of an additional planned-to-be-obsolete version" is. It is a stepping stone, that will make the 2.0 transition easier, because the transition to 1.2 can be fully automated, and then it will make obvious which terms will be obsolete in 2.0 (and therefore need more careful thought in transitioning) vs. those that can be left the same. Call it a 'transitional release' for an 'optional upgrade path' if that makes you happy. I will also call it an 'insurance policy if 2.0 OWL is not released by the end of the month. 

The pain in announcing a new version to the world (which hasn't been done yet) is that it takes a significant effort ontologies to be reworked and there is a long path to universal uptake. By releasing 1.2 we say we start that process. That's not something that you start again a month or two later. 

I agree with this point.  

 

Adjusting URIs is pain. OBI is one thing. I would hazard a guess that most users, holding off for a real release to put in the effort, will be pissed off if two months later (or even 6) we tell then the new URIs we just told them to use should be replaced again. Is it possible that your desire for what you want for OBI is blinding you to the situation as it would be perceived by the larger outside world?

In my prior responses I was assuming stable URIs from BFO 1.2 to BFO 2.0 (that is, that specifically dependent continuant will have the same URI in 1.2 and 2.0).  If that's not the case then absolutely 1.2 is a mistake and Melanie's concern about imports of multiple ontologies using different versions of BFO is all the more serious.

One interesting question is , assuming URIs are stable, what happens to obsoleted classes if you import one ontology that imports BFO 1.2 and another that imports BFO 2.0?  In 2.0 the class will be marked obsolete but not so in 1.2.  I would guess it would still show up as obsolete.

 

 

More important point: Does the BFO team have a process to decide on whether the 1.2 release should be made or not? If there is no clear process: Alan mentioned pain for the BFO user community several times as a main reason for not wanting to push that out. Can that user community be polled as a way to decide? 

I've worked *very* hard for there to be a modicum of process around BFO2. There are open mailing lists issue trackers, and more documentation then there has ever been. What we have here is a proposal by a group who has not been part of that BFO development process (and not for lack of invitation), pushing forward something that hasn't even been on the table for the people who have been working on this. So let's be a little gentler about making points about process. Start with RTFM and by submitting an issue, as is our documented process.

The answer is that we have a working group, a chair, and meetings in which we make decisions. All this has been recorded and can be found in mailing list archives, in the repository, and in linked google docs. Go to our home page. http://code.google.com/p/bfo. You will, for instance, see a link on the left "featured" section: How_we_record_issues_and_resolutions. 

We have a meeting coming up. I'm sure this proposal will be a matter for discussion. 

Regards,

Alan

[James A. Overton]

Hi Bill,

We've designed BFO 1.2 to be forward compatible with BFO 2.0.

IRIs are as stable as possible between 1.2 and 2.0. For instance, "specifically dependent continuant"  means the same thing in BFO 1.2 and 2.0, so it has the same ID. The full list of mappings is here, with extensive notes on sources and changes:

https://docs.google.com/spreadsheet/ccc?key=0AnbOUYWIQYUEdF9yb0hlUjhBUGRnVWNTVFJQX0xOUlE

This is what I expect to happen if you import both the BFO 1.2 OWL file and an updated BFO 2.0 OWL file (that incorporates obsolete terms from BFO 1.2, as described in the proposal):

1. terms that have different meanings in BFO 1.2 and 2.0 have different IDs, so there are no collisions

2. terms that have unchanged meanings have the same IDs, and at worst you get redundant annotations and axioms that should have no effect

3. obsolete terms keep their IDs but are stripped of logical axioms, and their annotations are supplemented with notes on obsoletion. So BFO_0000050 "has part" imported from two sources would have: the logical axioms from 1.2; all the annotations from both 1.2 and 2.0, including annotations saying that it is obsolete. Since the BFO 2.0 ontology should not be using obsolete terms, there will be no collisions, but the BFO 1.2 terms should continue to work as expected.

This is important, so please correct me if I'm wrong. (I've thought about this a lot, but I wrote this reply rather quickly.)

James

[Alan Ruttenberg]

On Thu, Jan 10, 2013 at 9:36 AM, James A. Overton <ja...@overton.ca> wrote:
> Bill: I believe that Chris and Alan were referring to ruttenberg-bfo2:
>
> http://purl.obolibrary.org/obo/bfo/2010-05-25/ruttenberg-bfo2.owl
>
> In reply Alan's point about BFO 1.2 "introducing" terms: we have not created any terms that were not previously published, and we have used existing IDs whenever possible. But we do want to "legitimize" these terms, for strong pragmatic reasons.
>
> "part_of" is a good example. I agree with Alan that the term is broken, but it's very widely used. It was assigned an OBO standard ID in ruttenberg-bfo2 and RO:

That was part of development work. It was not a released project.

>
> http://purl.obolibrary.org/obo/BFO_0000050
>
> A SPARQL query on Ontobee shows that this IRI is used more than 125,000 times in 19 ontologies [1]. This is far more uses than any of the term's older IRIs. But this "illegitimate" IRI resolves to a "404 Term Not Found" error page on Ontobee.

Most if not all of those uses are from Chris. He and I have already
had the discussion about using unreleased stuff in released projects.
Suffice to say it's a bad idea.

>
> For the benefit of current and future users of OBO annotated data, this IRI (and others like it) should resolve to a page that documents the term, along with its problems, and suggests replacements.

No, most of it should just be got rid of, which mostly can be done by
Chris. Documenting problems and creating replacements is what the BFO2
effort has been doing.

> Since there's a need to legitimize these IRIs, it makes sense to do it in the context of an official BFO 1.2 release that combines all the BFO 1 era upper-level classes and relations.

There is no need to legitimize them. Either they are legitimate
already (your assessment) or they are illegitimate and should be
replaced.

Chris has a lot of leverage in that he manages the process that
translates the OBO ontologies. But that doesn't mean it is good
process to have his work circumvent the standards we have for
releases. Imagine if someone took some experimental extension to OBI
and used it widely, even after OBI had found some fundamental flaw in
it and decided not to pursue it. Suppose they came to OBI and asked to
make a new release of OBI with that stuff in and some more
experimental stuff they had that wasn't well documented.

Bjoern asks about process, and I think he and you respect good process
generally. You position re:BFO2 undermines that value.

[Alan Ruttenberg]

On Thu, Jan 10, 2013 at 11:26 AM, James A. Overton <ja...@overton.ca> wrote:
> Hi Bill,
>
> We've designed BFO 1.2 to be forward compatible with BFO 2.0.
>
> IRIs are as stable as possible between 1.2 and 2.0. For instance,
> "specifically dependent continuant" means the same thing in BFO 1.2 and
> 2.0, so it has the same ID. The full list of mappings is here, with
> extensive notes on sources and changes:
>
> https://docs.google.com/spreadsheet/ccc?key=0AnbOUYWIQYUEdF9yb0hlUjhBUGRnVWNTVFJQX0xOUlE
>
> This is what I expect to happen if you import both the BFO 1.2 OWL file and
> an updated BFO 2.0 OWL file (that incorporates obsolete terms from BFO 1.2,
> as described in the proposal):
>
> 1. terms that have different meanings in BFO 1.2 and 2.0 have different IDs,
> so there are no collisions
>
> 2. terms that have unchanged meanings have the same IDs, and at worst you
> get redundant annotations and axioms that should have no effect
>
> 3. obsolete terms keep their IDs but are stripped of logical axioms, and
> their annotations are supplemented with notes on obsoletion. So BFO_0000050
> "has part" imported from two sources would have: the logical axioms from
> 1.2; all the annotations from both 1.2 and 2.0, including annotations saying
> that it is obsolete. Since the BFO 2.0 ontology should not be using obsolete
> terms, there will be no collisions, but the BFO 1.2 terms should continue to
> work as expected.

4. Terms that make no sense are to be offered for widespread use, even
though terms that do make sense are about to be published by the
working group responsible for the next version of BFO.

[Bjoern Peters]

Alan, 

I am sorry that I offended you. When I asked about process for deciding on making this release, I wasn't being fesiciuos - I know you spend a lot of work improving the process, and I appreciate that, so I thought  rather than just voicing my opinion, I should ask what the process is. I will RTFM. 

When I wrote to maybe treat the BFO 1.2 as a 'transitional release', I should have explained more what I meant. I was envisioning addressing your concerns by not advertised it as an 'official BFO release', but rather publishing the proposed 1.2 as a 'transitional release; with a strict warning that it should only be used by developers that want to go through the same process again once 2.0 is out. The 'to the world' announcement could be limited to those folks that are presently using 'unofficial terms'. The urls of things that will be obsoleted could also get a different form, with e.g. with 'to-be-obsoleted-in-bfo-2.0' in the uri. The release could not get a version number but be called 'bfo-transition-release' or whatever.  hope you get my intention. The release is meant as a practical solution to a real problem. Yes, this problem wouldn't exist if everyone had followed better procedures, but saying that won't make it go away. 

- Bjoern

---

[James A. Overton]

Hi Alan,

In reply to the hypothetical OBI case you raised below:

OBI is an open source project. Large open source projects undergoing major transitions often see some fragmentation, as some people modify the older (admittedly flawed) version to meet their current needs, and others push ahead with the new (improved) version. This is usually handled by maintaining two lines of active development: old and new. Since that divides valuable resources, the goal is always to merge those efforts back together as quickly and pragmatically as possible.

The BFO 1.2 proposal has been designed to do exactly this: move the old version ahead to facilitate a merge with the new version. The important question is not what we should have done differently in the past, but what we can do now to move things forward as best we can.

After careful consideration, I think the proposed BFO 1.2 is the best way forward right now, so that we can close the door on BFO 1 and move ahead to BFO 2 as quickly as possible.

James

[Bill Hogan]

Just closing the loop on a minor issue:

On Wed, Jan 9, 2013 at 9:05 AM, Alan Ruttenberg
<alanrut...@gmail.com> wrote:
>
>
> -Alan
>
> On Jan 8, 2013, at 4:59 PM, Bill Hogan <hog...@gmail.com> wrote:
>
>> i.r.t. = in response to (as opposed to @, which I take to mean I am
>> talking only to that person).
>>
>> i.r.t. Melanie: The problem you describe would be exacerbated, but
>> not caused by a BFO 1.2. Multiple versions now and going forward will
>> always be an issue. However, the primary issue I have encountered
>> with the multiple BFO imports is the change in URIs. That problem
>> would not exist if two imported ontologies imported BFO 1.2 and BFO
>> 2.0. Because it will be less pain to go from 1.1 -> 1.2 than 1.1 ->
>> 2.0, more ontologies might use the new URIs, potentially easing at
>> least this one major problem with multiple imports.
>>
>> i.r.t. Alan and Chris: the "pseudo-BFO 1.2" mentioned by you and
>> others is this one, right? http://purl.obolibrary.org/obo/bfo.owl.
>
> No. Did you open and look at it? It is the BFO 2 release for comment that we showed at ICBO, and has fairly extensive documentation, including term an property definitions or elucidations, clarity on its status, and reference to release notes.

My apologies. I had time finally to go back and find the email that I
was referencing and indeed, the PURL Chris gave me was the one above,
and he did indeed say it points the "Ruttenberg" BFO 2.0 draft.

Mea culpa.

I look forward to reviewing all the information there.

[Jenny Zheng]

Big issue of transition to BFO2.0 is how to use temporal relations. It
will need lots of thoughts. Due to loss of transitive property by
using at some time relations, it will loss inference power in many
ontologies. Chris has showed examples before. As far as I know,
ontologies like GO, won't shift to BFO2.0 until this transitive issue
solved.

BFO1.2 is a quick solution to resolve different BFO versions (BFO1.1,
BFO 2.0 pre-graz and graz version) used in OBO community. Convert to
BFO1.2 mainly for ID replacement and integration of relations to BFO
which need to be done when shift to BFO2.0. Switching to BFO1.2 is a
part of process for moving to BFO2.0 and it gives us time to test the
BFO 2.0.

Best,

Jie