Workshop OBI Vancouver 2008 Jan 31 notes

Getting to a Release, policies and processes
AI: 
 * Summary editor note in OWL file, can point to external URL if needed
 * Summary should be in text use SVN change log note to say what has been changed as well.
 * Use Editor Note if becomes too complex in the OWL file these can be stripped out, next release will have 2 files, one with E. note one without
 * Doesn't need to be done retrospectively
 * This relies on a
 * usable and used deprecation policy
 * A tracker will be used instead of email for tracking issues, this will be SF until a decision is made
 * We will look at new tracker options due to SF issues, will be added to a future developers call, options trac, w3c, sf. A wiki vote page will be set up by JM
 * If something comes to dev-list, it can be referred to a branch instead
 * When proposing an item in tracker we will discuss on dev call, assign a date for closure, it will be assigned to a person, and that person will take responsibility for resolving discussion and closing on the due date decided.
 * If you have tracker things from this meeting (look for your initials) use the tracker

AI:Two proposals for release notes, OWL file annotation property and SVN checkin logs

AI:

AI:AR will look into what are committing to in becoming a W3C group


 * we need to have three W3C supporters
 * get telecon
 * get webspace
 * use of tracker
 * need an editor
 * benefit for community

'''AI:Have a vote to remove people from coordinators list if they are not participating in OBI. Will contact everyone to ask for a replacement/withdraw. CS'''

'''AI:Identify what the responsibilities are for a coordinator and a community representative - Coord Call. CS'''

AI:Things get voted on in wiki by proposing a vote on a dev call

AI:if consensus cannot be reached by developers, coordinating will decide by some as yet undefined mechanism

'''AI:Deprecation policy will be discussed on next coordinators call to allow others to comments. AR Proposal for discussion is that we use OBO foundry process, add an obsolete class. Issues with logical definitions and previous use of editor note for this CS'''

AI:Paper proposal on engineering methodology to provide an incentive

AI:custom google custom search box for OBI wiki will be requested from CS group CS

Someone needs to put all the notes into the WIKI and make sure that they are all findable JM

AI:DENRI, Relations, Quality, Role need links to their term list files and or notes on the Branch Conf Calls

When call minutes done, sent to list for branch or dev, coord, and name minutes from that date and that branch - All branch editor and or person hosting dev or coord call

AI:Multi branch issues will go tracker and hence a dev call

AI:General feeling that there is no design whereby computing over h'archy depth is designed into OBI and it's not a good way to work with OBI at present MC will speak to EM about this

AI:An underscore will be added to each branches helper classes, each branch will deal with this themselves

AI:MC will add stimulus to the tracker

'''AI:Bioportal should point at the most recent version OBI-OWL merged file release so that progress is visible. We could release every 2 weeks, point at what changes in change log. Could be pull or push. CS'''

'''Bi-weekly releases of the OBI merged file will be made in SVN, it will be versioned. This will require unit tests from Bill (another AI from this workshop), will be in OWL-DL, likely this will mean use of pellet. Will be released on 1 and 15 of each Month. First release will be on March 1. For release it must classify in pellet at a minimum. This will be a per 1.0 release. JG will provide his an xls version as well BB, MC, CK, JG'''

Coordinators/Core Dev will review March 1 release and add to track for resolution

BB/MC will report of the resolution of the curation complete issues discussed elsewhere - DONE

AI:Coordinators/Core Dev will review March 1 release and add to track for resolution, will be added by Mar 15

'''AI:we need the criteria that define what is the prioritization for issues and if nec. we take it to a vote for e.g. Mar 1 release, depends on CS mail to coordinators. SS will mail CS so that we can make the time line work. ''' +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Discussion on managing input to OBI

 * How to keep track
 * How to summarize emails
 * How to communicate previous decisions
 * What is the social enforcement
 * Suggestions
 * use the tracker
 * use a new tracker like the OWL tracker
 * use annotation properties in OWL
 * branch editors summarize
 * proposer summarizes
 * how do we document the conclusion

AI:
 * Summary editor note in OWL file, can point to external URL if needed
 * Summary should be in text use SVN change log note to say what has been changed as well.
 * Use Editor Note if becomes too complex in the OWL file these can be stripped out, next release will have 2 files, one with E. note one without
 * Doesn't need to be done retrospectively
 * This relies on a

usable and used deprecation policy 
 * A tracker will be used instead of email for tracking issues, this will be SF until a decision is made
 * We will look at new tracker options due to SF issues, will be added to a future developers call, options trac, w3c, sf. A wiki vote page will be set up by JM
 * If something comes to dev-list, it can be referred to a branch instead
 * When proposing an item in tracker we will discuss on dev call, assign a date for closure, it will be assigned to a person, and that person will take responsibility for resolving discussion and closing on the due date decided.
 * If you have tracker things from this meeting (look for your initials) use the tracker

E.g. if change analyte, commit -analyte changed. Editor note, summary of why. Point to wiki, or thread. Typo fixes do not need to be logged.

MC:People should be allowed an opinion, but need to know what the decision was. E.g a tracker.

RB:OBI file is the arbitrator - curation complete= a decision

BB:and we have annotation properties for discussion, and we can add there

SS:issue that this on the call.

PRS:branch leader to add an editor note in the file

HP:tracker works well for a small no of editors, but release notes would be better and can generate these from the file

BB:related thing, no-one can bring up a topic unless they provide a solution and they document it's closure.

AR:I have been adding release notes on checkin, and there's a mailing list on checkin, and there's a log. This not at the level of definitions

MC:In OWL file is great, some things did not make it to the OWL file

BP:we didn't have the OWL file in the early days, now we can force people to use it

AI:Two proposals for release notes, OWL file annotation property and SVN checkin logs

AR:we could get tracker from W3C - XG Incubator

BP:2 things, we won't have the resolution in the OWL file, and that's fine. We need the resolution, discussion conclusion as an annotation property

RB:could you enumerate the trackers Alan?

AR:using a tracker consistently would be better

BB:most big projects have the tracker linked to the SVN

AR:we should look at the OWL tracker, and see if use XG instead

RB:Look at OWL tracker now http://www.w3.org/2007/OWL/tracker/ integrates into your emails

HP:this is a social problem not a technology problem

BP:do we need a new tracker/svn link?

AR:now that we have the google groups, people can use google groups for everything, is mirrored

AI:

* we need to have three W3C supporters * get telecon * get webspace * use of tracker * need an editor * benefit for community
 * Should we be a W3C group?

AI:AR will look into what are committing to in becoming a W3C group


 * Process needed for decision making

AI:Proposal: We will now have 2 week deadlines on anything that is put to the vote - JM will make a wiki to vote
 * Time lag is one month on votes - long


 * Who is responsible for a thread closure?

BB:suggest that someone on the branch takes responsibility. I will not do that again, no resolution

MC:I started analyte. I am happy to resolve, what if people disagree

RB:Work through an example: If we started today, add to sf, proposed a solution, then I assign to. During dev call go through unassigned issues, deadline set and someone owns.


 * Coordinators - active/inactive

AR:in W3C there is a policy where you need to attend 2/3 calls, can't vote if don't do that

RB:time zone issues with that

'''AI:Have a vote to remove people from coordinators list if they are not participating in OBI. Will contact everyone to ask for a replacement/withdraw. CS'''

CS:community matters not the person.

AR:representative does not =coordinator


 * Does a representative= a coordinator

AR:I raise the point that people can be representatives and not coordinators

SS:Good example with OBI, EMnvO is a sep project now.

RB:New group - representatives

HP:please no new email list

SS:suggest that the coord now are active in branches and community reps

JM:We have core dev, community reps, and coordinators

RB:we need to reach out to those who are community reps

'''AI:Identify what the responsibilities are for a coordinator and a community representative - Coord Call. CS'''


 * How a vote gets on the wiki call

MC:In latest call coord call we discussed using a voting system to resolve issues and people voted against that

HP:decision on a call or a meeting to put something to the vote.

Things get voted on in wiki by proposing a vote on a dev call

AR:e.g. analyte, someone documents the issue tracker, pro and con, post, and that summary is voted on.

MC:analyte went through that process, people wanted to reach a consensus and that wasn't possible.

AR:there are formal objections, chairs can close an issue, these are documented e.g. on dev call goes to coordinators call. Would like to run through the process

AI:if consensus cannot be reached by developers, coordinating will decide by some as yet undefined mechanism

RB:resolution of issues outstanding, can we assign these. Looking at tracker

'''AI:in SF tracker will be added to agenda for next dev call. CS'''


 * Deprecation

AR:propose what OBO foundry does, class called obsolote class, never delete anything. Only thing can remove. Logical defs need to be removed.

'''AI:Deprecation policy will be discussed on next coordinators call to allow others to comments. AR Proposal for discussion is that we use OBO foundry process, add an obsolete class. Issues with logical definitions and previous use of editor note for this CS'''

Engineering Methodology
AI:Improve wiki, FAQ, methodology pages, tools and applications page e.g. add meta data tags need work, need also to explain why multiple inheritance is bad - JM, JW, MC, FG, DS, BB -

AI:Paper proposal on engineering methodology to provide an incentive

AI:custom google custom search box for OBI wiki will be requested from CS group CS

We are part of OBO foundry and need to refer to that in docs

AR:all call notes should be in the same place.

MC:we can also use the tracker for that as well

Someone needs to put all the notes into the WIKI and make sure that they are all findable JM

JW:there are management systems that are better for that

AI:DENRI, Relations, Quality, Role need links to their term list files and or notes on the Branch Conf Calls

BP:Least effort - send out all notes to the maling list. Then we can search with google.

SS:Susanna wiki is OK as long as we don't create new pages

RB:minutes for obi dev call - which branch, all or none

When call minutes done, sent to list for branch or dev, coord, and name minutes from that date and that branch - All branch editorsr person hosting dev or coord call, o

Multiple Branch issues
AI:Multi branch issues will go tracker and hence a dev call

BB:fitting obi together will be the rate limiting step

Multiple inheritance bad, and why are we trying to avoid that
HP:This is about engineering methodology and should be documented there.

=Using Roles to flatten h'archy==

EM:wants to use h'archy to show similarity - depth measured, consequences for that in OBI

AI:General feeling that there is no design whereby computing over h'archy depth is designed into OBI and it's not a good way to work with OBI at present MC will speak to EM about this

Prefix helper classes with an _

 * obsolete, temp classes, etc

AI:An underscore will be added to each branches helper classes, each branch will deal with this themselves

Analyte/Stimulus
* now in the tracker and will be assigned at a dev call

AI:MC will add stimulus to the tracker

Technical Protege Issues
Adding meta data tags each time. There is code that can add these later from MC, and all code and helper applications, this will be added to the wiki and has been added to an existing action item.

How to do things in OWL

 * Importing from other ontologies
 * Mapping to other ontologuies
 * Roadmap to release, timelines
 * Dealing with time

AI:wiki timelines

OBI "Working" Release - Have OBI at a stage we are ready to have people use requires:
* Branch review of other branches
 * Curation_status curation_complete OK (TBD) on all terms - March 1
 * Individual review of OBI
 * Term;problem;solution submitted March 15
 * Problems without suggestions reviewed by group, then advisors
 * Use cases worked out through OBI to demonstrate "it works"
 * Versioning policy (and other OBO Foundry requirements http://obofoundry.org/crit.shtml)
 * Documentation on how to use
 * Each branch list of requirements to be completed to complete by March 1.

AR:want something intermediate for other editors in OBO discuss to look at

HP:will that actually happen

AR:they need a person to have a review for OBO process

HP:that could be the rate limiting step

AR:don't need docs for OBO to look at it

HP:this not reasonable, you need the docs to understand

SS:the times will affect what we can do in the next workshop, what we can do by then from that date

AR:what's the version that's in the bioportal

'''AI:Bioportal should point at the most recent version OBI-OWL merged file release so that progress is visible. We could release every 2 weeks, point at what changes in change log. Could be pull or push. CS'''

'''Bi-weekly releases of the OBI merged file will be made in SVN, it will be versioned. This will require unit tests from Bill (another AI from this workshop), will be in OWL-DL, likely this will mean use of pellet. Will be released on 1 and 15 of each Month. First release will be on March 1. For release it must classify in pellet at a minimum. This will be a per 1.0 release. JG will provide his an xls version as well BB, MC, CK, JG'''

Coordinators/Core Dev will review March 1 release and add to track for resolution

AR:we should have a version - in SF as it is a moving target.

SS:Is it the same on the bioportal and the foundy

RB:I assume that SVN is OK, and we can commit what's in SVN, and we make a version release on a regular basis.

JG:The OBI OWL file is not in subversion

AR:recommend that run a script, then svn copy etc to release

BB:And we can ask the Bioportal people for use to post on an SVN trigger

RB:Policy issue - issue with GO is release often, overhead with that, as they have issues with the existing annotations. In OWL we expect people to build from then we need to be concerned if things will break applications

HP:then that is their problem. It is not 1.0

BB:semantic entailment changes will not break things, typos etc will not impact. At this moment we need to consider how deal with the user base - we will know that

AR:we can discuss this when we get to a release

BB:some changes would be pushed off in a technical solution, for non impacting edits. We can reason vs pellet and this would be enough to deal with the problem.

RB:we need unit tests, list of what needs to be done, and implementation. In this

MC;how do we deal with validation issues

BB:unit test for each branch first, via pellet - BB will write this. Perl script (MC_ merges) and we make a release in a new tag branch of SVN, error handling will be manual.

MC:there is no clean up, terms without ids now.

RB:Editor notes removed.

AR:discussion on what terms will be in the obi.owl file, obsolete classes will be in. We can post bi-weekly, no clean up.

PRS:I would like the editor notes removed for release.

RB:till 1.0 we already agreed that these will be included

BP:they can be confusing and out of date

MC:Then it will be cleaned by March 1. Public 1.0 is official 1.0, we are talking about an intermediate release

RB:we can have another version with out all other stuff.

BB:we don't commit to that at this point

AR:could be scripted.

JB:I have a script that export it to XLS spreadsheet

JM:what does it buy us, credibility, interest

RB:there is a working group to look at what means curation complete - JM, MC, CS, DS

BB/MC will report of the resolution of the curation complete issues discussed elsewhere - DONE

Current status of the discussion reported by Melanie 31 Jan 2008:

Regarding the list of proposed values, this is the list as proposed by James:

insertion (which leads to...) yet, either metadata not all there, or values not correct/complete, etc. Notes should be added in "editor_note" property to record any specific issues, comments. (which leads to...) min metadata complete and are awaiting a review of the term (by someone other than the editor of the concept). (which leads to...) reviewed and will be included in next "release" of OBI. will therefore not be altered) - these terms must have some mapping to original source, i.e. ID code My only questions are (apart from does this look OK to everyone) do we need raw import and if so how do we deal with this, i.e. do we review these concepts as well and are they included in our owl file for OBI releases? 
 * uncurated: *nothing done yet, working term name and ID assigned on
 * under curation*: is being worked on by a curator but not complete
 * pending final vetting* all definitions, placement in hierarchy and
 * curation complete* ready for use, we curated it and it has been
 * raw import*: terms imported from an external ontology (and I presume

JM:we discussed in group about h'archy and defs related to cur complete. defs are contigent on is-a

BP:if curation complete means h'archy then we can't do that for Mar 1

SS:suggest that we need people to work who are on the calls

BP:we will make tracking tickets

AI:Coordinators/Core Dev will review March 1 release and add to track for resolution, will be added by Mar 15

BB:likely that anything in that period will not be fixed.

'''AI:we need the criteria that define what is the prioritization for issues and if nec. we take it to a vote for e.g. Mar 1 release, depends on CS mail to coordinators. SS will mail CS so that we can make the time line work. '''

Use Case Discussion, John Westbrook
Presentation of an investigation = collection of PDB entries contributed by different investigators, working on the same protein. structure comes from multi tech, x-ray, nmr...then used as models:tracking this info is important. Record instruments, settings, experiments....descriptive info report style, not paper style.

they want to reduce complexity associated with dealing with multiple types of files coming from multiple users.

3 kind of specific examples <=> 3 level of infos 1. protein expression protocol for structural genomics project: record at trial level the progress of production info is text, standards protocols, specific details for each trial is captured

AR: what granularity do we need? what are you mining for?

JW: mining for common methodology, materials and reagents

2. crystallization description x-ray experiment, single crystal as specimen 2 ways of collecting info: protocol desc: + and - info on trials for crystallization - methodology, detailed solutions conditions (concentrations, temperature, apparatus...) crystal itself

3. data collection on that crystal after diffraction experiment

example of OBI related: radiation source etc...-> instruments software used to process info essential features of dataset: qualities (accuracy) of the data

they have controlled vocabularies to describe every of these. These CVs could be the core of their term submission list.

Proposal to get a new submission from John, with no promise regarding the date of incorporation. AI: John will provide us with top-level hierarchy (low number of terms) for incorporation into OBI.

Cartik Kothari use case discussion
Conflicts in publications, eg proteomics (annotated in uniprot with CAUTION: for example) solved by looking up material and methods section

automation of framework for that -> describe experiments in a structured format

AI: Cartik has to share his annotations with OBI DL: 

Philippe Rocca-Serra Use Case Discussion
human nutrition perturbation introduced in 2 groups of animals affimetrix platform and NMR spectroscopy

set up: 2 groups * 6 animals - high fat diet + control food

glucose tolerance test challenge for all animals, after recovery from that challenge they will sample blood at different times, compute glucose concentration and deduce insulin. blood plasma, slice of livers (extract RNA->transcriptomics) normalization (bioconductor, R) linear model of data, corrections, get differentially expressed genes in their set

Experiment has aim, materials and methods (plan/protocol in OBI), results

AR: difference between results and conclusion? PRS: results = data, conclusion, generation of new hypothesis

Map this on OBI, using investigation, DT, plan, objective....


 * Has a use case from a paper for nutrigenomics
 * Wants to validate OBI using it
 * using a form approach
 * Add a link to PRS text docs

Working PRS Liver Transcriptomics example in OWL

 * protocol application: RNA abundance measurement
 * gave it a definition that referred to the protocol being realized
 * has_input: biomaterial - no problem
 * has_output: (information content entity AND (about SOME (RNA Concentration))
 * RNA Concentration is a quality