[Obi-devel] REMINDER: curation_status vote closes next Tuesday, 2/20

[Bill Bug]

Hi All,

Just wanted to pass around this reminder that this curation_status vote closes next week:

http://wiki.cbil.upenn.edu/obiwiki/index.php/ActionItems/Votes#VOTE:_Update_to_curation_status_AnnotationProperty_value

Note too that the 'Yes' option has been clarified a bit.  To vote yes is both to accept the initial proposal AND any suggested amendments:

Y - Yes (accept = I concur both with the above proposal AND with the suggested amendments below)

N - No (reject pending addressing suggested change stated below = I don't like the above, and I would instead suggest...) 

After the vote closes, if the proposal is voted in the affirmative (w/proposals), we will ask for one final read through by all, to make certain there were no proposed amendments some may not agree with.  All votes in so far are "yes", and the only suggested amendment made by Philippe (who voted 'Yes') merely suggests one of the values be brought up-to-date relative to discussions we had at the Vancouver face2face ('curation_complete' changed to 'ready_for_release').  This change has been made to the proposal.

Cheers,

Bill

William Bug, M.S., M.Phil.                                          email: wb...@ncmir.ucsd.edu

Ontological Engineer (Programmer Analyst III) work: (610) 457-0443

Biomedical Informatics Research Network (BIRN)

and

National Center for Microscopy & Imaging Research (NCMIR)

Dept. of Neuroscience, School of Medicine

University of California, San Diego

9500 Gilman Drive

La Jolla, CA 92093

Please note my email has recently changed

[Alan Ruttenberg]

Couple of comments:

> 4 pending_final_vetting
> All definitions, placement in the asserted IS_A hierarchy and
> required minimal metadata are complete. The class is awaiting a
> final review by someone other than the definition editor.

The "final" here may be misleading. More than once we have gone
through and later realized that some other changes are needed.
Perhaps "pending_review" would be more appropriate, and better
matches the text of the definition (but for the "final" bit).

> 5 ready_for_release
> Class has undergone final review, is ready for use, and will be
> included in the next OBI release.

As we recently decided that we will be "releasing" biweekly, or
monthly, perhaps a better name might simply "reviewed", indicating
that step 4 has been done. We also don't have, and haven't discussed
any mechanism for *not* including some term in a release.

I'll leave my vote blank, and accept the majority vote, in the case
that these comments aren't compelling.

-Alan

> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Obi-devel mailing list
> Obi-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obi-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel

[Bill Bug]

Alan's suggestions work for me, though I'd change 'reviewed' to 'review_complete'.  It just makes it more clear that all the basic required criteria have been met.  The 'review_complete' doesn't indicate there will NEVER be changes as 'curation_complete' might to some people.

So - are there any objections to specifying:

4 = 'pending_review'

5 = 'review_complete'

As to rules for release, we will be proposing a set of rules for release, as we specify a test plan and release procedure.  One issue that may have been mentioned in this regard (though I don't recall) - Philippe's suggestion - 'ready_for_release' - implies the 'curation_status' field WILL NOT be present in the merged, public release.  Is this the way others are expecting the 'curation_status' field to be used during release.  In other words - as Alan implies - and as I've mentioned in the past - do others expect our procedure for creating a public merged release will include determining which terms are in fact "ready_for_release" (or have curation_status 'review_complete', if we accept Alan and my suggestion here), and all other terms will be excluded from the release.

If we agree to this, then there will not only be ramifications to how the release will be constructed, it will also impact how we specify 'curation_status' values.  For instance, if a class has 'curation_status' 'review_complete', but one of its IS_A asserted graph ancestors is NOT 'review_complete', we'll not be able release that term, since we won't be able to construct its ancestor graph.  This would also cause problems for classes using ObjectProperty relations.  If one of the classes referred to in a class restriction are not 'review_complete', this would at least keep us from releasing that class with its restrictions.  We'd need to simply leave the restrictions out.  This might lead to a released, merged OBI that's considerably smaller than we all might expect, unless we get very systematic about how we proceed with the class curation process and the setting of the 'curation_status' field.

Any thoughts? - as we need to start getting concrete about these issues related to release policy.

Cheers,

Bill

On Feb 14, 2008, at 1:55 AM, Alan Ruttenberg wrote:

Couple of comments:

4 pending_final_vetting

All definitions, placement in the asserted IS_A hierarchy and required minimal metadata are complete. The class is awaiting a final review by someone other than the definition editor.

The "final" here may be misleading. More than once we have gone through and later realized that some other changes are needed. Perhaps "pending_review" would be more appropriate, and better matches the text of the definition (but for the "final" bit).

5  ready_for_release

Class has undergone final review, is ready for use, and will be included in the next OBI release.

As we recently decided that we will be "releasing" biweekly, or monthly, perhaps a better name might simply "reviewed", indicating that step 4 has been done. We also don't have, and haven't discussed any mechanism for *not* including some term in a release.

I'll leave my vote blank, and accept the majority vote, in the case that these comments aren't compelling.

-Alan

On Feb 14, 2008, at 1:07 AM, Bill Bug wrote:

Hi All,

Just wanted to pass around this reminder that this curation_status vote closes next week:

http://wiki.cbil.upenn.edu/obiwiki/index.php/ActionItems/Votes#VOTE:_Update_to_curation_status_AnnotationProperty_value

Note too that the 'Yes' option has been clarified a bit.  To vote yes is both to accept the initial proposal AND any suggested amendments:

Y - Yes (accept = I concur both with the above proposal AND with the suggested amendments below)

N - No (reject pending addressing suggested change stated below = I don't like the above, and I would instead suggest...)

After the vote closes, if the proposal is voted in the affirmative (w/proposals), we will ask for one final read through by all, to make certain there were no proposed amendments some may not agree with.  All votes in so far are "yes", and the only suggested amendment made by Philippe (who voted 'Yes') merely suggests one of the values be brought up-to-date relative to discussions we had at the Vancouver face2face ('curation_complete' changed to 'ready_for_release').  This change has been made to the proposal.

Cheers,

Bill

William Bug, M.S., M.Phil.                                         email: wb...@ncmir.ucsd.edu

Ontological Engineer (Programmer Analyst III) work: (610) 457-0443

Biomedical Informatics Research Network (BIRN)

and

National Center for Microscopy & Imaging Research (NCMIR)

Dept. of Neuroscience, School of Medicine

University of California, San Diego

9500 Gilman Drive

La Jolla, CA 92093

Please note my email has recently changed

-------------------------------------------------------------------------

This SF.net email is sponsored by: Microsoft

Defy all challenges. Microsoft(R) Visual Studio 2008.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________

Obi-devel mailing list

Obi-...@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/obi-devel

[Allyson Lister]

I agree with Bill's modifications to Alan's suggestions.

I also think, like Alan, that it would be best to include the curation status in the public version, with the caveats mentioned by Alan. However, I too would go with popular opinion.

:)

On Thu, Feb 14, 2008 at 8:16 AM, Alan Ruttenberg <alanrut...@gmail.com> wrote:

"review complete"

I'd rather release with curation status, than remove items from a release. Expectation to be set would be that anything other than those with "review complete" should be considered likely to change place in hierarchy or have definition refined, or be obsoleted in the next release.

If we get some user demand for a release with only "5"s, then I'd reconsider.

But consider this a preference, nothing stronger - I'm curious what others thing.

--
Thanks,
Allyson :)

Allyson Lister
Research Associate
Centre for Integrated Systems Biology for Ageing and Nutrition
Newcastle University
http://www.cisban.ac.uk
School of Computing Science
Newcastle University
Newcastle upon Tyne, NE1 7RU

[Ryan Brinkman]

> "review complete"
>
> I'd rather release with curation status, than remove items from a
> release.

Agreed

-Ryan

[Tina Hernandez-Boussard]

I agree with Alan

Tina Hernandez-Boussard, PhD, MPH
300 Pasteur Drive
Grant Building RmS085A
Stanford, CA 94305-5655
Phone: (650) 725-5507
Fax: (650) 725-0791
Email: bous...@stanford.edu

On Feb 14, 2008, at 12:16 AM, Alan Ruttenberg wrote:

> "review complete"
>
> I'd rather release with curation status, than remove items from a

> release. Expectation to be set would be that anything other than
> those with "review complete" should be considered likely to change
> place in hierarchy or have definition refined, or be obsoleted in
> the next release.
>
> If we get some user demand for a release with only "5"s, then I'd
> reconsider.
>
> But consider this a preference, nothing stronger - I'm curious what
> others thing.
>

> -Alan
>

> On Feb 14, 2008, at 3:03 AM, Bill Bug wrote:
>

>> ---------------------------------------------------------------------

>> ----
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Obi-devel mailing list
>> Obi-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>

> ----------------------------------------------------------------------

[Helen Parkinson]

I also agree with Alan

Helen

--
Helen Parkinson, PhD
ArrayExpress Production Coordinator,
Microarray Informatics Team,
EBI

EBI 01223 494672
Skype: helen.parkinson.ebi

[Bill Bug]

Me, too.

I just wanted to make the point - building on Alan's comment - that our release policy needs to make such decisions, if our use of 'curation_status' is to be much value either to us or to the community of OBI users.

As Alan indicates, we need to document this all for the community.  Once this vote is final, we may want to fill out the specification of what these values mean to users of OBI for inclusion in "release notes" - e.g.:

"...expectation to be set would be that anything other than those with "review complete" should be considered likely to change place in hierarchy or have definition refined, or be obsoleted in the next release"

Cheers,

Bill

[Melanie Courtot]

Hi all,

I agree with your comments. We might decide to revise that decision later
on with the progresses made on OBI, but I believe including everything is
the way to go for now (including a disclaimer as mentioned by Bill).

I added this item to the agenda for the next developer call on wednesday:
https://wiki.cbil.upenn.edu/obiwiki/index.php/ConferenceCallAgenda#February_2008

Thanks,
Melanie

>> --
>> Helen Parkinson, PhD
>> ArrayExpress Production Coordinator,
>> Microarray Informatics Team,
>> EBI
>>
>> EBI 01223 494672
>> Skype: helen.parkinson.ebi
>>
>>

>> ----------------------------------------------------------------------
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Obi-devel mailing list
>> Obi-...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/obi-devel
>>
>
>
>

> William Bug, M.S., M.Phil.
> email: wb...@ncmir.ucsd.edu
> Ontological Engineer (Programmer Analyst III) work: (610) 457-0443
> Biomedical Informatics Research Network (BIRN)
> and
> National Center for Microscopy & Imaging Research (NCMIR)
> Dept. of Neuroscience, School of Medicine
> University of California, San Diego
> 9500 Gilman Drive
> La Jolla, CA 92093
>
> Please note my email has recently changed
>
>

[Bill Bug]

The only "gotcha" embedded in this practice as summarized by Alan below that we should be aware of is either:

A) this would require we systematically ensure that any class specified as "review complete" have ONLY ancestor classes in the IS_A hierarchy that are ALSO "review complete"

OR

B) we warn users that even classes specified as "review complete" may end up changing their place in the hierarchy, if there is any class in their ancestral chain that is NOT "review complete"

I think we are generally doing 'A', though we'd want to make certain we do it systematically, so we can give users more confidence that "review complete" really will engender the class be more "stable".

Cheers,

Bill

[Alan Ruttenberg]

Good point. I suggest we adopt and document B) so as to make the review process less encumbered. 

-Alan

"Apple-style-span" style="white-space: pre; "> work: (610) 457-0443

Biomedical Informatics Research Network (BIRN)

and

National Center for Microscopy & Imaging Research (NCMIR)

Dept. of Neuroscience, School of Medicine

University of California, San Diego

9500 Gilman Drive

La Jolla, CA 92093

Please note my email has recently changed

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.

http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Allyson Lister]

I agree with B as well.

[Trish Whetzel]

I agree with B also.

Trish