Vote regarding release of BFO2 OWL

[Alan Ruttenberg]

In today's meeting the following proposal was made.

Proposed: We release the current draft BFO2, updated with some items from the trackers, tbd. One or more variants, specified by those who don't some or all the temporalized relations, will be specified, omitting some relations, and this will be created as part of release process. Release notes will be written that document the current state of our release, including the controversy, and the existence of the variant.

[the text of the proposal was edited slightly by me, for clarity and grammar]

Those present on the call when the vote was taken were: myself, Jie Zheng, Chris Mungall, Bjoern Peters, Stefan Schulz, James Overton, Ludger Jansen and Niels Grewe.

All voted in favor of the proposal.

If you have been participating in the BFO 2 development process, and object to this proposal, please make your views known within 2 weeks (by Tuesday May 7, 2013) ,by responding to one of mailing lists this email is addressed to, or by commenting on http://code.google.com/p/bfo/wiki/Vote_for_BFO2_Release. You can also add your affirmative vote to that page, which will include a copy of this email.

To track those tracker items which people would like to have resolved before the release - understanding that these should be feasible to accomplish in the next month or two - please add a comment, which will reveal the labels associated with the issue, and add the label Milestone-BFO2-Release. If you wish, or think it necessary, have the body of the comment include a proposal for resolution and justification of why you think it needs to be resolved before release.

Regards,
Alan Ruttenberg, 

for the BFO OWL Development Group

[He, Yongqun]

Sorry that I left the meeting before the voting occurred. I think that I participated in most of the related discussion in the meeting. As I view it, the proposal is reasonable. This is a feasible way towards an eventual and timely release of BFO 2 with a consensus. Therefore, I vote in favor of the proposal.

 

Best wishes,

 

Oliver He

University of Michigan

--
You received this message because you are subscribed to the Google Groups "bfo-owl-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-owl-deve...@googlegroups.com.
To post to this group, send email to bfo-ow...@googlegroups.com.
Visit this group at http://groups.google.com/group/bfo-owl-devel?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

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

[Melanie Courtot]

Hi all,

Sorry I couldn't make it to the call. Few things are unclear to me in the below:
- I thought the only issue to using the "whole" BFO2 were the temporalized relations, and that we would therefore release BFO2 as-is, and people that don't want to use those relations just don't use them. Given this, why do we still need variants? What are the proposed variants?
- I am not very keen on releasing variants, as this will create version issues again. My main objection to BFO1.2 was having people relying on different versions which would be confusing when importing several resources that rely on different versions. How does the multiple release of variants address this concern?
- Who will maintain those variants, and what is the time commitment? I am worried they will be maintained ad-hoc with no real update (or non synchronized with other variants), and/or people will make local updates that don't match other variants.

Those may have been discussed during the call but it is probably worth clarifying here and on the wiki page.

Cheers,
Melanie

> --
> You received this message because you are subscribed to the Google Groups "bfo-owl-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bfo-owl-deve...@googlegroups.com.
> To post to this group, send email to bfo-ow...@googlegroups.com.
> Visit this group at http://groups.google.com/group/bfo-owl-devel?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

[Alan Ruttenberg]

On Wed, Apr 24, 2013 at 1:06 PM, Melanie Courtot <mcou...@gmail.com> wrote:

Hi all,

Sorry I couldn't make it to the call. Few things are unclear to me in the below:
- I thought the only issue to using the "whole" BFO2 were the temporalized relations, and that we would therefore release BFO2 as-is, and people that don't want to use those relations just don't use them.  Given this, why do we still need variants?

It seems that those who plan not to used them are worried about the confusion arising from their presence.

 

What are the proposed variants?

We're working on them. At one end, I'm hoping only a minimal set can be removed, as suggested by my work with James (e.g keep those relations like inheres_in_at_all_times that are not (I hope) controversial). At the other extreme is removing all of them (suggested as a possibility by Chris)

 

- I am not very keen on releasing variants, as this will create version issues again. My main objection to BFO1.2 was having people relying on different versions which would be confusing when importing several resources that rely on different versions. How does the multiple release of variants address this concern?

Variants are strict subsets of the official version (slims). They conform to what we documented as part of our id policy, having the same ontologyIRI and different versionIRI. I don't believe there is cause for concern as the consequence of importing both would not be any change in meaning, or clash, it would simply be the presence of the additional relations.

There is a minor issue that might need to be checked having to do with the order in which imports are added, and whether the first import of some version might cause a subsequent one not to load. I think this is probably manageable. It wouldn't happen in loading triple stores, only when using DL reasoning tools, if at all.

 

- Who will maintain those variants, and what is the time commitment? I am worried they will be maintained ad-hoc with no real update (or non synchronized with other variants), and/or people will make local updates that don't match other variants.

I plan to incorporate their building into the BFO build script, as I don't believe it to be technically difficult. So they would be a byproduct of the standard build. 

Those may have been discussed during the call but it is probably worth clarifying here and on the wiki page.

We discussed all these on the call, and hopefully they are recorded in the minutes. I do think we should start documenting this, but would prefer to have more the details be worked out and to have it be on a separate page, linked to from the vote page, so as not to make the vote page too intimidating.

Please let me know if you think these answers adequately address the concerns you have.

Best,

Alan

[Chris Mungall]

On Apr 24, 2013, at 10:26 AM, Alan Ruttenberg wrote:

On Wed, Apr 24, 2013 at 1:06 PM, Melanie Courtot <mcou...@gmail.com> wrote:

Hi all,

Sorry I couldn't make it to the call. Few things are unclear to me in the below:
- I thought the only issue to using the "whole" BFO2 were the temporalized relations, and that we would therefore release BFO2 as-is, and people that don't want to use those relations just don't use them.  Given this, why do we still need variants?

It seems that those who plan not to used them are worried about the confusion arising from their presence.

 

What are the proposed variants?

We're working on them. At one end, I'm hoping only a minimal set can be removed, as suggested by my work with James (e.g keep those relations like inheres_in_at_all_times that are not (I hope) controversial). At the other extreme is removing all of them (suggested as a possibility by Chris)

I'm afraid that all temporalized relations must by default be regarded as controversial and difficult until proved otherwise.

I'm attaching v1.2 of my critique. I did not address *all* temporalized relations, but one of the take-home messages is that the problems run deep and we must be careful about relying on intuititions. Many people were surprised that the at-all-times forms of part_of and has_part were not inverses. This was counterintuitive, but was entailed by the FOL.

inheres-in-at-all-times is difficult too. inheres-in-at-all-times has no inverse declared in bfo2. It probably should be declared the inverse of bearer-of-at-some-times.

http://code.google.com/p/bfo/issues/detail?id=165

Most of us would want to use the BFO2 subset that excludes bearer-of-at-some-times and swap in atemporal bearer-of instead:

In fact, I would take particular care to scrutinize Dependent Continuant-based relations very carefully, because it's not clear to me how to model determinates in BFO2 OWL. There may be further surprises lurking in the gaps.

In addition, any at-all-times relation is problematic, as it entails a commitment regarding rigid classes. See my critique for why this is a major problem.

With TRs, it's in for a penny, in for a pound.

- I am not very keen on releasing variants, as this will create version issues again. My main objection to BFO1.2 was having people relying on different versions which would be confusing when importing several resources that rely on different versions. How does the multiple release of variants address this concern?

Variants are strict subsets of the official version (slims). They conform to what we documented as part of our id policy, having the same ontologyIRI and different versionIRI. I don't believe there is cause for concern as the consequence of importing both would not be any change in meaning, or clash, it would simply be the presence of the additional relations.

There is a minor issue that might need to be checked having to do with the order in which imports are added, and whether the first import of some version might cause a subsequent one not to load. I think this is probably manageable. It wouldn't happen in loading triple stores, only when using DL reasoning tools, if at all.

There is another issue we did not address.

O1 may wish to import BFO2-minimal, and take additional relations from RO

However, O1 may import another ontology (say IAO) that itself imports the complete BFO2.

The subset strategy becomes pointless here.

It's not insurmountable. It would be possible to make an alternate version of the intermediate ontology that imports the minimal ontology.

It's not clear the extent to which this will be a problem for different ontologies.

 

- Who will maintain those variants, and what is the time commitment? I am worried they will be maintained ad-hoc with no real update (or non synchronized with other variants), and/or people will make local updates that don't match other variants.

I plan to incorporate their building into the BFO build script, as I don't believe it to be technically difficult. So they would be a byproduct of the standard build. 

Those may have been discussed during the call but it is probably worth clarifying here and on the wiki page.

We discussed all these on the call, and hopefully they are recorded in the minutes. I do think we should start documenting this, but would prefer to have more the details be worked out and to have it be on a separate page, linked to from the vote page, so as not to make the vote page too intimidating.

Please let me know if you think these answers adequately address the concerns you have.

Best,

Alan

Critique attached below.

[Melanie Courtot]

Hi all,

Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81. IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them? Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Melanie

> <trc-v1.2.pdf>

[Chris Mungall]

On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:

> Hi all,
>
> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81

Oh, I didn't see this. Apologies for the duplicate.

> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?

So there are two issues:

1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.
2. whether there is an official subset of BFO or whether others make on

One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.

> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.

> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Having a subset doesn't stop people trying out the relations.

[Alan Ruttenberg]

On Wed, Apr 24, 2013 at 3:24 PM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Apr 24, 2013, at 10:26 AM, Alan Ruttenberg wrote:

On Wed, Apr 24, 2013 at 1:06 PM, Melanie Courtot <mcou...@gmail.com> wrote:

Hi all,

Sorry I couldn't make it to the call. Few things are unclear to me in the below:
- I thought the only issue to using the "whole" BFO2 were the temporalized relations, and that we would therefore release BFO2 as-is, and people that don't want to use those relations just don't use them.  Given this, why do we still need variants?

It seems that those who plan not to used them are worried about the confusion arising from their presence.

 

What are the proposed variants?

We're working on them. At one end, I'm hoping only a minimal set can be removed, as suggested by my work with James (e.g keep those relations like inheres_in_at_all_times that are not (I hope) controversial). At the other extreme is removing all of them (suggested as a possibility by Chris)

I'm afraid that all temporalized relations must by default be regarded as controversial and difficult until proved otherwise.

I'm attaching v1.2 of my critique. I did not address *all* temporalized relations, but one of the take-home messages is that the problems run deep and we must be careful about relying on intuititions. Many people were surprised that the at-all-times forms of part_of and has_part were not inverses. This was counterintuitive, but was entailed by the FOL.

inheres-in-at-all-times is difficult too. inheres-in-at-all-times has no inverse declared in bfo2. It probably should be declared the inverse of bearer-of-at-some-times.

http://code.google.com/p/bfo/issues/detail?id=165

Most of us would want to use the BFO2 subset that excludes bearer-of-at-some-times and swap in atemporal bearer-of instead:

I sure hope not. That seems to me to be extreme. I can't see any reason to do that. This train of thought seems to be more FUD that substance.

 

In fact, I would take particular care to scrutinize Dependent Continuant-based relations very carefully, because it's not clear to me how to model determinates in BFO2 OWL. There may be further surprises lurking in the gaps.

Determinates are not a type in BFO. Every class that has subclasses can be considered a determinate quality. What is more interesting are axioms that say a type of thing can only have a single instance of a type of quality. Those cases are where determinates become an issue. I would say we would make progress on this if PATO took the time to represent this.

 

In addition, any at-all-times relation is problematic, as it entails a commitment regarding rigid classes. See my critique for why this is a major problem.

No it doesn't. The at-all-times is quantified over the existence of the entity. It doesn't say anything about type.

 

With TRs, it's in for a penny, in for a pound.

No, I think you have a buggy analysis, I'm afraid to say.

 

- I am not very keen on releasing variants, as this will create version issues again. My main objection to BFO1.2 was having people relying on different versions which would be confusing when importing several resources that rely on different versions. How does the multiple release of variants address this concern?

Variants are strict subsets of the official version (slims). They conform to what we documented as part of our id policy, having the same ontologyIRI and different versionIRI. I don't believe there is cause for concern as the consequence of importing both would not be any change in meaning, or clash, it would simply be the presence of the additional relations.

There is a minor issue that might need to be checked having to do with the order in which imports are added, and whether the first import of some version might cause a subsequent one not to load. I think this is probably manageable. It wouldn't happen in loading triple stores, only when using DL reasoning tools, if at all.

There is another issue we did not address.

O1 may wish to import BFO2-minimal, and take additional relations from RO

However, O1 may import another ontology (say IAO) that itself imports the complete BFO2.

The subset strategy becomes pointless here.

No it doesn't. The reason for the subset is so that ontologies that are importing BFO can choose not to directly import the relations. As long as ontologies that work with them make the same choice they get the same view. However you can't prevent people from importing things, and what I states is a simple consequence of how OWL works.

 

It's not insurmountable. It would be possible to make an alternate version of the intermediate ontology that imports the minimal ontology.

But frankly, that's just not necessary. Better to work on tools that allow developers to hide stuff they don't want to pay attention to. The properties (TR, aTR ) do not interact with each other.

 

It's not clear the extent to which this will be a problem for different ontologies.

- Who will maintain those variants, and what is the time commitment? I am worried they will be maintained ad-hoc with no real update (or non synchronized with other variants), and/or people will make local updates that don't match other variants.

I plan to incorporate their building into the BFO build script, as I don't believe it to be technically difficult. So they would be a byproduct of the standard build. 

Those may have been discussed during the call but it is probably worth clarifying here and on the wiki page.

We discussed all these on the call, and hopefully they are recorded in the minutes. I do think we should start documenting this, but would prefer to have more the details be worked out and to have it be on a separate page, linked to from the vote page, so as not to make the vote page too intimidating.

Please let me know if you think these answers adequately address the concerns you have.

Best,

Alan

Critique attached below.

[Melissa Haendel]

Hi all,

I think it would be helpful to consider the less technical obo-format foundry participants here. What do they need to be good citizens? If we don't consider how to bring them into the fold, we will end up with an even bigger divide between those that develop in OBO and those that develop in OWL. In that sense, I favor creation of a slim that is the lightest-weight version (e.g. likely no temporalized relations) that we need people to adhere to, or else we will get no adherence at all.

Regardless of the implementation strategies and BFO2 content in the end, we will absolutely need documentation, training, and outreach describing how to use the new BFO and design considerations. 

I am not entirely in the loop here, so apologies if you all have already discussed. I just wanted to point out how much of the BFO2 work is quite unbeknownst to much of our community.

Cheers,

Melissa

--
-- the bfo-devel group prefers that conversations on matters related to the specification take place on the mailing list so that other team members and users can follow how decisions are made. Please ensure you tell your mail application to respond to all.
---
You received this message because you are subscribed to the Google Groups "bfo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-devel+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Dr. Melissa Haendel

Assistant Professor
Ontology Development Group, OHSU Library

http://www.ohsu.edu/library/

Department of Medical Informatics and Epidemiology
Oregon Health & Science University
hae...@ohsu.edu
skype: melissa.haendel

503-407-5970

[Alan Ruttenberg]

On Wed, Apr 24, 2013 at 4:09 PM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:

> Hi all,
>
> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81

Oh, I didn't see this. Apologies for the duplicate.

> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

Every relation, TR or not, should be examined individually. 

 

> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?

So there are two issues:

1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I've requested at least a plausibility argument of how it could be a problem. Is that really too much to ask??

 

2. whether there is an official subset of BFO or whether others make one

One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.

Look, there is isn't a problem making them, and we've agreed to document the controversy. Whether the problems are with the TRs or the people I am uncertain, but we need not, implicitly or not, fix on either interpretation.

Melanie, I really don't think the issue of whether we should have variants is something we should debate. It is routine that we have variants in the form of slims and we've lived with it for a long time without problems.

 

> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.

> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Having a subset doesn't stop people trying out the relations.

I'd rather not have their label be so. It's my contention, remember, that these relations are well defined and sound, if not necessarily covering all use cases or being easy to teach.

-Alan

[Melanie Courtot]

On 2013-04-24, at 1:09 PM, Chris Mungall wrote:

>
> On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:
>
>> Hi all,
>>
>> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81
>
> Oh, I didn't see this. Apologies for the duplicate.
>
>> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)
>
> This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

Ok - I merged the issues.

>
>> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?
>
> So there are two issues:
>
> 1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I agree. I am not sure I understand the difference between BFO_0000056 for "participates in" (atemporal) and "participates in at some time" (as per http://code.google.com/p/bfo/issues/detail?id=163). When doing the mapping I thought those were equivalent. That being said if there is any confusion we should avoid reusing URIs.

> 2. whether there is an official subset of BFO or whether others make on
>
> One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

Did you mean a BFO PURL? Otherwise I didn't understand why an RO PURL.

>
> However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.
>
>> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.
>
> Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.
>
>> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?
>
> Having a subset doesn't stop people trying out the relations.

Trying to summarize:

- PROs
- some people find it less confusing to not have TRs in the file

- CONs
- we need to create and manage subsets (probably implies creating PURLs and versions)
- we don't solve the issue of different resources importing different subsets. For example, if IAO imports BFO2 "whole" resources importing IAO will import BFO2 whole (even if they chose to import a subset for themselves)
- there is a chance subsets are being managed individually and some changes are not propagated uniformly across subsets (we may say this won't happen, but experience with IAO for example has proven different)

Finally, if I choose to import a subset without TRs in my project, chances that I will ever test out TRs are low - it would require me to import those specifically. If they are just there in the file I (1) know they exist (2) can decide to try them on and see what happens without having to update my imports. Seems to me like there ought to be a way to distinguish TRs to alleviate potential confusion without the need to create a subset, maybe via a specific label or other options to hide them. (as a side note it may actually be interesting to explore "hide" options, as people also expressed interest in hiding some BFO classes)

Given those I casted my vote at http://code.google.com/p/bfo/wiki/Vote_for_BFO2_Release against releasing variants. I added a mention that I am not objecting release, rather than I am in favour of releasing the whole BFO2 and no variants.

Melanie

[Alan Ruttenberg]

On Wed, Apr 24, 2013 at 4:31 PM, Melissa Haendel <hae...@ohsu.edu> wrote:

Hi all,

I think it would be helpful to consider the less technical obo-format foundry participants here. What do they need to be good citizens? If we don't consider how to bring them into the fold, we will end up with an even bigger divide between those that develop in OBO and those that develop in OWL. In that sense, I favor creation of a slim that is the lightest-weight version (e.g. likely no temporalized relations) that we need people to adhere to, or else we will get no adherence at all.

If it turns out that the group wants that, that's fine with me. However I would certainly not recommend anyone I work with to use it. My recommendation would be to have a variant with just the relations for which there is a plausible problem, and have an alternative label that removes the temporal qualifications (since it is my assertion that a number of them mean the same thing as the atemporal ones). That's what I'm hoping OBI will do, and to the extent that I am a participant in that group I will advocate it.

Regardless of the implementation strategies and BFO2 content in the end, we will absolutely need documentation, training, and outreach describing how to use the new BFO and design considerations. 

No question. True of each and every new ontology. So nothing BFO2 specific here. And we've started to do that already.

 

I am not entirely in the loop here, so apologies if you all have already discussed. I just wanted to point out how much of the BFO2 work is quite unbeknownst to much of our community.

Its never going to get known if it isn't released.

-Alan

[Alan Ruttenberg]

>
> 1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I agree. I am not sure I understand the difference between BFO_0000056 for "participates in" (atemporal) and "participates in at some time" (as per http://code.google.com/p/bfo/issues/detail?id=163). When doing the mapping I thought those were equivalent.  That being said if there is any confusion we should avoid reusing URIs.

 

No, I disagree. Only if there is some *justifiable* confusion. In this case I challenge someone to make a plausibility argument that they mean something different. If there is one, then I agree they should be split. If not, this is premature and will only serve to make ontologies less interoperable than necessary. 

The argument that there is a difference for part of is compelling. There should be an equally compelling argument for each relation. We have to have *some* standard for this work other than "I'm worried something bad might happen".

-Alan

[Alan Ruttenberg]

- CONs

        - we don't solve the issue of different resources importing different subsets. For example, if IAO imports BFO2 "whole" resources importing IAO will import BFO2 whole (even if they chose to import a subset for themselves)

Until someone makes a cogent argument that there is an actual problem here, I don't think it belongs in any column. And so far there has been no argument, only fear.

-Alan

 

[Melanie Courtot]

On 2013-04-24, at 1:34 PM, Alan Ruttenberg wrote:
[..]

>
> Melanie, I really don't think the issue of whether we should have variants is something we should debate. It is routine that we have variants in the form of slims and we've lived with it for a long time without problems.

I disagree. Variants or slims are not always straightforward: there have been variants of IAO produced for consumption by the OBI group, and changes have been made locally and not ported to the trunk. I think slims work well if you have a specific project that has a targeted audience (for example, it would be great to have slims of OBI including Flow Cytometry elements, or microarray, or IEDB) but I don't think it is a reliable options for those projects that are themselves shared across resources such as IAO or BFO. We are even in the process of moving ontology-metadata out of the IAO project as this is too confusing - and we had it be a separate file with a clearly different scope.

The page at http://code.google.com/p/bfo/wiki/Vote_for_BFO2_Release specifically asks if we should release BFO2 and variants of BFO2, and I don't think this is an adequate way to move forward, specifically in that it doesn't address the issues I currently have with resources using BFO1 and others using BFO2, or BFO1 and BFO1.2 or any other mix.

>
> > Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.
>
> Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.
>
> > It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?
>
> Having a subset doesn't stop people trying out the relations.
>
> I'd rather not have their label be so. It's my contention, remember, that these relations are well defined and sound, if not necessarily covering all use cases or being easy to teach.

Maybe experimental was a poor choice; I am open to other suggestions for label or other ideas to make it easier for those who don't want to see those relations, as this seems to be the only argument in favour of having variants.

Melanie

[Chris Mungall]

On Apr 24, 2013, at 1:34 PM, Alan Ruttenberg wrote:

On Wed, Apr 24, 2013 at 4:09 PM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:

> Hi all,
>
> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81

Oh, I didn't see this. Apologies for the duplicate.

> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

Every relation, TR or not, should be examined individually. 

 

> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?

So there are two issues:

1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I've requested at least a plausibility argument of how it could be a problem. Is that really too much to ask??

Umm, you snipped the part of my email where I provided this:

http://code.google.com/p/bfo/issues/detail?id=165

But was is it even necessary for me to do this? Surely it's obvious that if one group is using BFO_0000053 as in "bearer of" (atemporal) and another group is using BFO_0000053 to mean "bearer of at SOME times" we're going to run into difficulties. Don't you think it's kind of sensible to try and avoid that?

And what's with the "is this really too much to ask?". Really? I wrote an entire critique where many of these issues were laid out. Is it too much to ask you to read this? 

At this stage it doesn't seem safe for us to use identifiers in the BFO ID space for atemporal relations, as we have no guarantee they won't be reused in a different way. I would therefore recommend that those of us using atemporal relations should mint new URIs for these - probably RO URIs. This is very unfortunate and will cause some churn but I don't see what the alternative is.

 

2. whether there is an official subset of BFO or whether others make one

One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.

Look, there is isn't a problem making them, and we've agreed to document the controversy. Whether the problems are with the TRs or the people I am uncertain, but we need not, implicitly or not, fix on either interpretation.

Melanie, I really don't think the issue of whether we should have variants is something we should debate. It is routine that we have variants in the form of slims and we've lived with it for a long time without problems.

 

> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.

> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Having a subset doesn't stop people trying out the relations.

I'd rather not have their label be so. It's my contention, remember, that these relations are well defined and sound, if not necessarily covering all use cases or being easy to teach.

I would suggest, at a minimum, that some kind of indication of what use cases are covered and not covered are provided as part of the TR documentation. Then people can be better informed about whether to use them or some alternative.

For examples of use cases that are not covered, I refer people to my critique.

[Alan Ruttenberg]

On Wednesday, April 24, 2013, Chris Mungall wrote:

On Apr 24, 2013, at 1:34 PM, Alan Ruttenberg wrote:

On Wed, Apr 24, 2013 at 4:09 PM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:

> Hi all,
>
> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81

Oh, I didn't see this. Apologies for the duplicate.

> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

Every relation, TR or not, should be examined individually. 

 

> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?

So there are two issues:

1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I've requested at least a plausibility argument of how it could be a problem. Is that really too much to ask??

Umm, you snipped the part of my email where I provided this:

http://code.google.com/p/bfo/issues/detail?id=165

But was is it even necessary for me to do this? Surely it's obvious that if one group is using BFO_0000053 as in "bearer of" (atemporal) and another group is using BFO_0000053 to mean "bearer of at SOME times" we're going to run into difficulties. Don't you think it's kind of sensible to try and avoid that?

If I knew what bearer-of (atemporal) meant, I could respond. But I really don't and I don't think you do either. 

And what's with the "is this really too much to ask?". Really? I wrote an entire critique where many of these issues were laid out. Is it too much to ask you to read this? 

I read and commented on it. You don't seem to want to understand the responses. The main criticisms were that the generic relation proposed just doesn't work as an instance relation, and that most of the problems that were identified as TR issues were really issues with specific versus generic relations. 

There were also comments about user burden, and the difficulty of using the relations correctly. However I disagree that a valid alternative to trouble using relations is to use relations that have no way of being shown to be true. 

M

At this stage it doesn't seem safe for us to use identifiers in the BFO ID space for atemporal relations, as we have no guarantee they won't be reused in a different way.

I addressed this already. We (foundry) have a policy that we don't change meaning. They wont be used in a different way - new terms would be created. 

It seems far more likely that the atemporal terms will be used differently as we don't even know what correct usage of the now is. 

 

 I would therefore recommend that those of us using atemporal relations should mint new URIs for these - probably RO URIs. This is very unfortunate and will cause some churn but I don't see what the alternative is.

The alternative is the be conservative about pre-worry about some of these concerns and  instead act when you know something specific.  

 

2. whether there is an official subset of BFO or whether others make one

One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.

Look, there is isn't a problem making them, and we've agreed to document the controversy. Whether the problems are with the TRs or the people I am uncertain, but we need not, implicitly or not, fix on either interpretation.

Melanie, I really don't think the issue of whether we should have variants is something we should debate. It is routine that we have variants in the form of slims and we've lived with it for a long time without problems.

 

> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.

> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Having a subset doesn't stop people trying out the relations.

I'd rather not have their label be so. It's my contention, remember, that these relations are well defined and sound, if not necessarily covering all use cases or being easy to teach.

I would suggest, at a minimum, that some kind of indication of what use cases are covered and not covered are provided as part of the TR documentation. 

Sure, assuming you will do the same for the relations you plan to uses. No double standards. But I think you will have a harder time at this because you don't have formal definitions. 

 

Then people can be better informed about whether to use them or some alternative.

Assuming they have comparative information about the alternative. Thus far this does not exist. 

For examples of use cases that are not covered, I refer people to my critique

Do I really have to assemble a comparable collection about the proposed alternative?  

I would like some others to analyze the critique in light of the errors and issues I've noted. 

-Alan

--
-- the bfo-devel group prefers that conversations on matters related to the specification take place on the mailing list so that other team members and users can follow how decisions are made. Please ensure you tell your mail application to respond to all.
---

You received this message because you are subscribed to the Google Groups "bfo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-devel+...@googlegroups.com.

[Chris Mungall]

On Apr 24, 2013, at 6:53 PM, Alan Ruttenberg wrote:

On Wednesday, April 24, 2013, Chris Mungall wrote:

On Apr 24, 2013, at 1:34 PM, Alan Ruttenberg wrote:

On Wed, Apr 24, 2013 at 4:09 PM, Chris Mungall <cjmu...@lbl.gov> wrote:

On Apr 24, 2013, at 12:38 PM, Melanie Courtot wrote:

> Hi all,
>
> Thanks for the answers. Chris, we had noted an issue with inverses at http://code.google.com/p/bfo/issues/detail?id=81

Oh, I didn't see this. Apologies for the duplicate.

> . IIRC at the time Alan explained why those relations were not inverse; I'll admit being very confused about this (which came up several times in the past, e.g., http://code.google.com/p/bfo/issues/detail?id=73)

This one pertains to participation. With TRs, each relation must be examined individually, unless we can abstract some high level patterns

Every relation, TR or not, should be examined individually. 

 

> My main question was, assuming we agree that we want an option to not use temporalized relation, wouldn't it be possible to just release BFO2 including those, and people just don't use them?

So there are two issues:

1. reuse of the same URI for a TR and an AR. I think we should be conservative and avoid this.

I've requested at least a plausibility argument of how it could be a problem. Is that really too much to ask??

Umm, you snipped the part of my email where I provided this:

http://code.google.com/p/bfo/issues/detail?id=165

But was is it even necessary for me to do this? Surely it's obvious that if one group is using BFO_0000053 as in "bearer of" (atemporal) and another group is using BFO_0000053 to mean "bearer of at SOME times" we're going to run into difficulties. Don't you think it's kind of sensible to try and avoid that?

If I knew what bearer-of (atemporal) meant, I could respond. But I really don't and I don't think you do either. 

Sigh. This is getting us nowhere. You're changing the issue at hand.

BIG ISSUE - temporalized relations and their attendant problems -vs- atemporal relations and ongoing efforts to give them an interpretation in the spirit of the 2005 RO paper.

SMALLER ISSUE - what do we do about the handful of relations that have URIs starting with BFO_ that were originally atemporal but have been reclaimed in BFO2 as either -some-times or all-times.

We were discussing the SMALLER ISSUE.

The SMALLER ISSUE is potentially a problem for everyone, it's in *all* our interests to sort it out. It shouldn't be hard. It could get really messy if we don't. But you want us to convince you in each case that they absolutely mean different things. Never mind the  precautionary principle or common sense. Fine, I provide an example. It takes a few attempts to get you to read it. You begrudgingly accept that the disjoints example *might* show a difference. But then, aha! you tie it all in to the BIG ISSUE, you won't be convinced there's a difference between the two relations until we've convinced you of this. But that's a trick, as we get caught in the same morass I attempted to lay to rest in my critique, and we end up not advancing on the SMALLER ISSUE.

Look, the intended meaning of the bearer-of example I gave is clearly in the spirit of the RO 2005 paper, and this is clearly different semantics than the at-some-times form. Just admit it, the disjointness example in issue #165 is good enough.

I don't know if this is worth pursuing for the sake of a handful of URIs. I thought it would be in everyone's interest if we continued using these rather than minting new ones outside the BFO ID space. But I think this is too dangerous. If any of these BFO IDs are fair game for being reclaimed with a different interpretation and we can't control this and need to convince you of the BIG ISSUE, it's not worth it, I think we should take the ID churn hit and mint some new IDs. Other stakeholders in this, please let me know what you think.

And what's with the "is this really too much to ask?". Really? I wrote an entire critique where many of these issues were laid out. Is it too much to ask you to read this? 

I read and commented on it. You don't seem to want to understand the responses. The main criticisms were that the generic relation proposed just doesn't work as an instance relation, and that most of the problems that were identified as TR issues were really issues with specific versus generic relations. 

This was the comments you gave on the BFO call before you had actually got to the main section?

Can you post a more specific response on this list? Your comments above suggest you haven't actually read it - it covers more than specific vs generic parthood.

There were also comments about user burden, and the difficulty of using the relations correctly. However I disagree that a valid alternative to trouble using relations is to use relations that have no way of being shown to be true. 

M

At this stage it doesn't seem safe for us to use identifiers in the BFO ID space for atemporal relations, as we have no guarantee they won't be reused in a different way.

I addressed this already. We (foundry) have a policy that we don't change meaning. They wont be used in a different way - new terms would be created. 

Sorry, but they *are* being used in a different way by BFO2

It seems far more likely that the atemporal terms will be used differently as we don't even know what correct usage of the now is. 

??

 

 I would therefore recommend that those of us using atemporal relations should mint new URIs for these - probably RO URIs. This is very unfortunate and will cause some churn but I don't see what the alternative is.

The alternative is the be conservative about pre-worry about some of these concerns and  instead act when you know something specific.  

I've given a concrete example. It's impossible to be more specific. My example showed an axiom that is correct by our interpretation, gives the desired inferences, but when it is re-interpreted with the at-some-times, it is formally *wrong* and gives the *wong* inferences.

 

2. whether there is an official subset of BFO or whether others make one

One one level #2 is not so important. People who don't want to make their own subset can just use the one available from a RO purl.

However, I think that there is some advantage to the BFO2 group in being the official purveyors of the subset. By providing the subset it's in part an implicit acknowledgment that there are issues with the TRs and some users may wish to start with the non-TR subset, and possibly mix this with ARs.

Look, there is isn't a problem making them, and we've agreed to document the controversy. Whether the problems are with the TRs or the people I am uncertain, but we need not, implicitly or not, fix on either interpretation.

Melanie, I really don't think the issue of whether we should have variants is something we should debate. It is routine that we have variants in the form of slims and we've lived with it for a long time without problems.

 

> Seems like this would solve quite a bit of issues, from having to produce different variants to having to deal with resources importing resources importing different variants? For example, I don't know many projects that use "zero-dimensional temporal region" but it doesn't hurt to have it in the file.

Yes, I agree. Most groups will just want to pick and choose a minimal subset. But I think it helps to divide the axioms in advance for people.

> It would also allow people to try the relations out if they wish - if there is a need to single them out easily in the hierarchy we could label them as "experimental-TR-inheres_in_at_all_times". That would probably help with possible confusion?

Having a subset doesn't stop people trying out the relations.

I'd rather not have their label be so. It's my contention, remember, that these relations are well defined and sound, if not necessarily covering all use cases or being easy to teach.

I would suggest, at a minimum, that some kind of indication of what use cases are covered and not covered are provided as part of the TR documentation. 

Sure, assuming you will do the same for the relations you plan to uses. No double standards. But I think you will have a harder time at this because you don't have formal definitions. 

OK, you're on. For every use case not covered by the atemporal relations you provide, I will include specific documentation

 

Then people can be better informed about whether to use them or some alternative.

Assuming they have comparative information about the alternative. Thus far this does not exist. 

The alternative is what we have all being doing with atemporal relations for several years. If it's so flawed it should be immediately apparent.

For examples of use cases that are not covered, I refer people to my critique

Do I really have to assemble a comparable collection about the proposed alternative?  

The alternative has been in use for years, it shouldn't be too hard for you to find examples of where it's failing, if indeed it is

I would like some others to analyze the critique in light of the errors and issues I've noted. 

I'm very open to that. It might help if you address *specific points* in the critique.

[Alan Ruttenberg]

I have given a detailed refutation of the bearer_of example you provided at http://code.google.com/p/bfo/issues/detail?id=165#c8

I will examine other examples and see if any others survive.

-Alan