Conference call developers 2007 notes
July 18 2007
Attending: Jennifer F, Bjoern P, Gilberto F, Tina B, Bill B, Chris S. (note: call in number from the UK had changed without notice preventing others from calling in. Aim - resolving items where no conclusion was reached at the Bethesda workshop Discussion: Ontology development issue on Biomaterial/ Instrument hierarchy will not be resolved through email. As it affects multiple branches, it should be addressed through a specified developers call with supporting documents posted for developers to think about. It was proposed that a wiki page be put up with a summary of the discussion so far, alternative hierarchies being considered, and their pros and cons. Bill Bug has volunteered to start this page. The ontology development issues of batch/ lot number and reagents should probably be handled is a similar way. NSF proposal due end of August. Alan R (not on the call) had raised at the OBI workshop, the possibility of applying for a NSF grant (http://www.nsf.gov/pubs/2007/nsf07565/nsf07565.htm). The idea is that Alan would supervise a full time OBI developer, provide training at Science Commons to OBI developers, and help support OBI workshops. Unfortunately, it turns out that Science Commons wants to submit a different proposal for the NSF call and does not want to compete with itself on the OBI grant. Bjoern has looked into his institution being the lead on an OBI proposal with the aims previously mentioned (full time developer working with Alan, etc.) and has volunteered to circulate a draft budget page to see whether we can get agreement on who would do what and with what funds. AA1. Bill B. will start a wiki page for the artefact/ intrument/ biomaterial discussion AA2. Bjoern P. will circulate a draft document for the NSF application to nail down PIs and institutions involved.
6 June 2007
Summary:
Daniel presented an instrument branch summary, full discussion below:
OBI dev call. Present James, Helen.
Chris S, Gilberto, Liju, Helen, Mervi, Daniel,Kevin,James, Bjoern, Tina
Agenda:
1. Instrument branch progress to date to be reviewed
Daniel sends a word document prev sent to the relations branch to the dev
Status report etc has been sent to the instrument branch.
Chris S. Forwards the status report to the dev list.
Daniel sent a report - see doc sent to OBI-deb and instrument lists
Min meta data is the main problem, not many people have these and limited the no of terms that could be uploaded.
CS:How many more will be added?
DS:~500 instrument terms potentially, need better definitions with examples. Discussion on requirement for examples as this slows thing down.
OBI platform probably belongs in instrument branch. Some terms look like instances e.g. BioSorter1000 - could be modelled at the instance level. No sense to provide defs for these, but we were forced to do that anyway.
HP:asking about instance level - could an instrument be an instance at the level of serial no, rather than the model
CS: agree at the level of a serial no then are at an instance eg. AffyU1333. Will be cases where there are model.
DS:then how would you have a definition. Do you want to provide a def for each?
CS:We are now handling terms that are of local not general interest
BP:We had a discussion with biomaterial. Could deal with vendor, lot not etc occur through out. E.g. cell sorter from a manufacturer - can be a defined class - no need to model at this level
KC:If I had to make an instrument - how do you handle a case where something is self made
GF:We need to include something that is 'unclassified' but make more specific. 'Home made instrumentatiobn etc', these would be less specific than the commercial ones.
KC:gel boxes are usually self made for e.g. need to allow for this. Capture what the 'thing' was supposed to do e.g. separation via electrophoresis
LF:in the homemade case could we use the parts - can pick the sub parts that they need.
KC:we put together in P/A pars such as separation - instrument could perform this protocol.
HP:the definitions are not useful in some cases e.g. FACS_caliber
GF:question abiut generality of definitions e.g. one that uses context in the case of cell counting in milk
BP:Daniels point is that doing definitions for the universals.
BP:reiterate that we want to deal with selfmade stuff and the commercial ones.
CS:Agree with you, all branches should be handling this way, You've described a way that makes sense.
HP:artefact seems to belong to BFO, will that stay?
See term list: http://spreadsheets.google.com/pub?key=pT8ShyqlllIUySkFP8biiTg
DS:is a placeholder - too broad
CS:should we propose as a term for BFO?
LF:discussion about this - has only one subclass - we don't need this. We will see if we can make any subclass
HP:another concern is that the definition is so broad that this impacts on other branches
DS:likely to change this term, is a placeholder for now.
Liju:can now import the OWL file.
GF:Instrument has a purpose - do you use this as a dimension and what was conclusion - faciliates protocol application step?
BP:we had the same thing in P/A utilizes instrument. Properties are something that we should be going through
We take a look at the properties.
https://wiki.cbil.upenn.edu/obiwiki/index.php/InstrumentRelations
Using OWL terminology for these object properties. Range, tried to stay within OBI.
BP:Some overlap with P/A should we discuss these?
DS:we can discuss inverse relns to deal with these on the relns branch call
LF:invite to join the call on Friday.
BP:Suggest we do it now
LF:we can combine with the weds call for dev?
CS:depends on what else we need to do
BP;is a function branch person? Bill and I were in agreement that has_function would go away as process and used for are realized in process then the functionis defined.
General agreement that this a better way to define function in context.
KC:We are talking about equipment - do we want to differentiate function between instrument and protocol and e.g. heart valve function. Do we want to differentiate
BP:Don't know if there is a need to define at that level, Function comes from BFO.
KC:equipment is included in equipment and performing expts, not much about general bio functions
BFO example of function is not specifically useful for OBI
BP:we are defining protocol applications and so no need for function
KC:agree
HP:consensus on two things then
DS:This is an initial list, data input/data output
HP:do you have material output/input?
KC:material input/material output or consumables might be useful
BP:this needs to be tied to protocol application - how the instrument is used uis determined there.
DS:part of system/part of platform - depends if we capture these collections. If we want users to provide descriptions e.g. environment - can affect performances. Last user etc.
Processing time was mean to capture how long it takes in a range - might be useful to capture this?
KC:could be a parameter?
BP:data input instead?
DS:we haven't looked into time handling
BP:In gen in P/A we are modelling input and output - could have e.g. input Sample, output DNA - these are required. Suggest that we model specifically what is required for an instrument and generally in terms of protocols. Replace consumes in terms of the protocol application. E.g. instrument always needs eppos, in protocols are general, instrument adds some more info about the instrument itself.
KC:exmaple of instrument parts reln to each other? Example of a DNA sequencer in detail
CS:Would we need this level of granularity
KC:might need for a benchmarking new technology
GF:seems like these are not defining relns, but relns between parts that we want to relate sometimes.
KC:If took a DNA Sequencer - and use for not PCR - e.g.
HP:But if you define in terms of function then this is hard to do, if you do this in p/a than can cover cases where instrument is used for a non std purpose.
GF:We need to devote some time to discuss the coord call.
AA: Next coord call - polish the agenda for the workshop on 13th
BP:nice job for instrument branch. Virtual round of applause
Dev Call Minutes, 30 May, 2007
(AI = Action Item) Call Minutes: - Workshop start monday afternoon
- Follow up on Protege import bugs Liju actioned. Went to Prot�g� archive and found problem with namespace. Email sent to dev list details how to get around this. Individually remove other branches to edit your own branch. AI: Alan and Trish to look into using CVS for editing branches in Prot�ge and create a read_me file to describe how to do this.
- CTO follow up, Jennifer Fostel/Richard S. JF: Reporting on workshop CTO has decided to Clinical Investigation Ontology because clinical trials has specific meaning. CIO will look like or be child of OBI. What is vision for use of OBI? Chris: Envisage transcriptomics will use OBI in future, OBI will eventually become major ref ontology that terms are submitted too from community (no separate ontology). JF: Workshop meeting bring people back together for initiative, JF gave talk on OBI using Suzanna�s core slides. Not huge progress for building things � developer is not entirely happy with OBI at moment. Liju: No OWL people there, only philosophy people not interested in development of relations. Focus on terms creation. JF: Have list of terms and made contact with other with terms. Currently trying to get terms and see how fit in OBI. They have list of minimal information spec which JF to model towards. Liju: Is CIO developing an ontology alongside OBI? JF: Query tool and data management system created in Germany which is basis of CTO � hoping to replace it with terms from OBI. Dev indicated at end of meeting that unhappy with this process currently. Barry assures everything is OK as long as follow BFO. Very independent efforts modeling similar things similar to OBI. Need one set of terms so that all other efforts can find their terms. SA: Map to OBI or to CIO? Trish: Map to OBI group Alan: It was a tense workshop, started out with talks from barry pointing out flaws in work for Bridge (who was in audience) which caused tension. People who do clinical trials do not consider their issue biology. They did not see how this methodology could benefit them and what they do. There was a reasonable portion of audience did not see methodology desirable. Could face trying to get consensus to audience which are potentially adverse to the idea. On other hand clinical investigations covers more people which are concerned with relevant issues. JF: Good contact was made with relevant groups, e.g. BRIDGE SA: I see CIO will be a view of OBI for clinical world? JF: Can�t say that initially because will put people off. Need to build up consensus first to show them that there terms will fit into OBI. Chris: Not clear if OBI is one big file or stub that parts are imported into yet. Philippe: German based clinical effort mentioned � how much is public and how much can be used by OBI? Chris: On Google Philippe: Can we use this? FP: There is a lag in how we can use terms and pull them in. Trish: We don�t want to pick and choose terms from this yet. FP: Terms are not yet stable. Trish: Is it best someone goes through list as terms come in? Philippe: Have they identified any terms we may have missed? Is it worth reviewing? FP: Gain information from website. What is missing is who takes the role for looking at these. However, it is not a final product. Bjoern: Biggest problem is that there is no OBI working version yet. We need this before we start these discussions. We need to get productive before workshop so that project keeps moving. Trish: Is there any value in adding to 0.6.6 version yet? Chris: No since current dev is fairly rapid. Alan: Can we add a version tag which is inline with usual versioning system format? Trish: I�m more familiar with normal way of tagging ontology version file though have no concerns about changing things Alan: Can I make a tagged version of what is currently there using format? AI: Alan look into version tagging for files
Milestones: JM: Concern about how we mark off milestones and whether we will hit them current. What we do on 1st June when hit next milestone and after? Trish: Some are finished and not marked off. Once we get branch files done (if done) how we then start building OBI as a whole from relations? Liju: Recommendation add relations. It is possible that if import files change how relations will also change. Alan: Is there an interest in latest Prot�g� (v4)? Chris: using OWL files so tool should be independent Alan: Theoretically yes but lot of discussion is about whether the tools can work for us. I would like to get confirmation first that Prot�g� 4 can deal properly with issues such as coop development. AI: Alan: Query on Prot�g� 4 suitability JM: how do we know when we have achieved the miletone on June 1st (review of terms)? Bjoern: If we had a branch with a file of terms, hierarchy and how that fits into ontology � but this is not going to happen I don�t think currently, too much discussion on policy rather than on practical work to progress project. Trish: deadline is review of terms Alan: One way might be to get all branch editors to speak on a call and try and address how these deadlines can be reached (currently not). Chris: I�ve been monitoring the branches to see where we are. I�m optimistic about how things are coming along since we have terms and people are starting to discuss relations. A major issue is getting people to make time to make calls. Evaluate the milestones and work at workshop. Alan: Why don�t we get Robert, Barry and Matthew on a call and walk through issues we have over a call before workshop. Liju: Barry wonders how we will do the relations Bjoern: I feel good way to bring things forward is to have an OWL file and use these rather than discuss issues Trish: I have several OWL files with this as early examples. Bjoern: Do we need observations modeled separately. Trish: This could be something brought forward.
AI: ALL RELEVANT BRANCH EDITORS: branches to be reviewed each week to help progress: Instrument branch to be reviewed at next dev call (6 Jun) Biomaterial branch to be reviewed week after that (13 Jun)
