Menu
▾
▴
psidev-ms-dev — Mass spectroscopy standard development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
(1) |
May
(5) |
Jun
(2) |
Jul
(3) |
Aug
(7) |
Sep
(18) |
Oct
(22) |
Nov
(10) |
Dec
(15) |
| 2006 |
Jan
(15) |
Feb
(8) |
Mar
(16) |
Apr
(8) |
May
(2) |
Jun
(5) |
Jul
(3) |
Aug
(1) |
Sep
(34) |
Oct
(21) |
Nov
(14) |
Dec
(2) |
| 2007 |
Jan
|
Feb
(17) |
Mar
(10) |
Apr
(25) |
May
(11) |
Jun
(30) |
Jul
(1) |
Aug
(38) |
Sep
|
Oct
(119) |
Nov
(18) |
Dec
(3) |
| 2008 |
Jan
(34) |
Feb
(202) |
Mar
(57) |
Apr
(76) |
May
(44) |
Jun
(33) |
Jul
(33) |
Aug
(32) |
Sep
(41) |
Oct
(49) |
Nov
(84) |
Dec
(216) |
| 2009 |
Jan
(102) |
Feb
(126) |
Mar
(112) |
Apr
(26) |
May
(91) |
Jun
(54) |
Jul
(39) |
Aug
(29) |
Sep
(16) |
Oct
(18) |
Nov
(12) |
Dec
(23) |
| 2010 |
Jan
(29) |
Feb
(7) |
Mar
(11) |
Apr
(22) |
May
(9) |
Jun
(13) |
Jul
(7) |
Aug
(10) |
Sep
(9) |
Oct
(20) |
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(4) |
Mar
(27) |
Apr
(15) |
May
(23) |
Jun
(13) |
Jul
(15) |
Aug
(11) |
Sep
(23) |
Oct
(18) |
Nov
(10) |
Dec
(7) |
| 2012 |
Jan
(23) |
Feb
(19) |
Mar
(7) |
Apr
(20) |
May
(16) |
Jun
(4) |
Jul
(6) |
Aug
(6) |
Sep
(14) |
Oct
(16) |
Nov
(31) |
Dec
(23) |
| 2013 |
Jan
(14) |
Feb
(19) |
Mar
(7) |
Apr
(25) |
May
(8) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(20) |
Oct
(19) |
Nov
(10) |
Dec
(12) |
| 2014 |
Jan
(6) |
Feb
(15) |
Mar
(6) |
Apr
(4) |
May
(16) |
Jun
(6) |
Jul
(4) |
Aug
(2) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(3) |
| 2015 |
Jan
(3) |
Feb
(8) |
Mar
(14) |
Apr
(3) |
May
(17) |
Jun
(9) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(13) |
Nov
|
Dec
(6) |
| 2016 |
Jan
(8) |
Feb
(1) |
Mar
(20) |
Apr
(16) |
May
(11) |
Jun
(6) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
(5) |
Nov
(7) |
Dec
(2) |
| 2017 |
Jan
(10) |
Feb
(3) |
Mar
(17) |
Apr
(7) |
May
(5) |
Jun
(11) |
Jul
(4) |
Aug
(12) |
Sep
(9) |
Oct
(7) |
Nov
(2) |
Dec
(4) |
| 2018 |
Jan
(7) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(7) |
Jun
(7) |
Jul
(7) |
Aug
(1) |
Sep
(9) |
Oct
(5) |
Nov
(3) |
Dec
(5) |
| 2019 |
Jan
(10) |
Feb
|
Mar
(4) |
Apr
(4) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(9) |
Dec
(1) |
| 2020 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Helen P. <par...@eb...> - 2007-03-20 13:39:17
|
Hi Ok then I suggest we add to the OBi dev call agenda if no-one objects cheers Helen frank gibson wrote: > Hi > > The next PSI meeting is due to be held on the 23-25th April. It would > be great if something was prepared, even only for discussion, for this > date. > > Cheers > Frank > > On 3/20/07, *Helen Parkinson* <par...@eb... > <mailto:par...@eb...>> wrote: > > Hi > > this was mentioned in a call last week and is also needed for MO. I > think we will need some guidelines on this, > > cheers > > Helen > > frank gibson wrote: > > Hi > > > > I would also like to highlight, that if term definitions or > > hierarchies are changed within OBI from the original CVs there needs > > to be some sort of feedback or mapping presented back to the PSI. As > > Daniel points out these exist for a particular purpose and for a > > particular community, if they dont find the terms they expect in OBI > > then they wont use it. Hopefully this feedback will also help > develop > > more well designed CVs in the future. > > > > Frank > > > > On 3/20/07, *Chris Taylor* <chr...@eb... > <mailto:chr...@eb...> > > <mailto:chr...@eb... <mailto:chr...@eb...>>> > wrote: > > > > Just in passing, its worth remembering also that (for example) > > the MS terms in OBI should also be amenable to use by > > metabolomics people, MS-based nucleotide sequencers, etc. > > > > I believe there is still a plan to 'flag' terms as appropriate > > to a particular domain (such as proteomics), but the use of > > omics-based conceptions of the world to shape the structure of > > the ontology is dysfunctional and won't feature in OBI per se. > > > > Cheers, Chris. > > > > > > Daniel Schober wrote: > > > Hello Stefan, OBI developers and PSI MS developers. > > > Yes, the OBI instrument branch will have to review PSI term > > definitions > > > for scope and applicability in OBI. Keep in mind that the PSI > > artifacts > > > are less formal CVs and were mostly created in 'xml > style'. That > > is why > > > their graph/taxonomy is often 'xmlienated' (build using > is-a _and_ > > > part-of relations in one hierarchy). Their CVs also do not use > > any top > > > level ontology and they sometimes have terms from the > > epistemiological > > > level as part of their compound term names, e.g. Detector > _Type_ and > > > Analyzer _Description_. Sometimes they are not really > explicit, > > using > > > 'ellipses' for term names, e.g. 'secondary electron' is_a > 'detector > > > type'. It should be 'secondary electron detector' is_a > > 'detector' instead. > > > But they concentrate on their domain only and have a specific > > > application in mind. They never claimed to be fully > ontological > > in the > > > first place. All that lead them to be very narrowing in their > > > definitions sometimes. So, Stefan is right. In many cases we > > have to > > > refine the definitions and render them applicable in a more > > general way > > > and e.g. a 'detector' class would be defined more broadly, > and would > > > probably get a mass_spectroscopy_detector subclass with would > > correspond > > > to the MS 'detector'. > > > I assume that some of these glitches will vanish once the > PSI design > > > principles document ( including the naming conventions, > > > http://www.psidev.info/index.php?q=node/100 ) will be > approved and > > > applied within PSI. > > > > > > Best regards, > > > Daniel Schober. > > > > > > Stefan Wiemann wrote: > > >> I have had a look at the PSI_MS-InstrumentTermsForOBI file. > > >> This contains <term names> that are quite common also in > other > > communities, > > >> however used there in a different sense. For example, the > term > > <Accuracy> is > > >> defined as the "Accuracy of mass assignment", the term > > <Chromatography> as > > >> "Chromatographic conditions used to obtain the sample". I > feel > > that this > > >> narrow definition of some terms might cause problems as the > > same terms may > > >> be used with a wider focus in other communities (Accuracy > could > > also be the > > >> accuracy of a very different measurement, chromatography > can be > > purely > > >> analytical). A <detector type> characterizes also the data > > acquisition > > >> mechanism in a video microscope, a FACS, or a plate > reader. How > > is this > > >> terminology dealt with in OBI? > > >> Stefan > > >> > > >> > > >>> -----Original Message----- > > >>> From: obi...@li... > <mailto:obi...@li...> > > <mailto:obi...@li... > <mailto:obi...@li...>> > > >>> [mailto: obi...@li... > <mailto:obi...@li...> > > <mailto:obi...@li... > <mailto:obi...@li...>>] On Behalf Of > > >>> Trish Whetzel > > >>> Sent: Tuesday, March 20, 2007 12:55 AM > > >>> To: OBI Developers > > >>> Subject: [Obi-devel] Instrument Branch Scope > > >>> > > >>> Just a quick note, those on the Instrument Branch call > last week > > >>> decided that for terms such as petri dish, gel tank, cage > > >>> etc. that we > > >>> would like to collect these terms and work out a > location for > > >>> them in OBI. > > >>> If your community has these kinds of terms, please post a > > >>> tab-delimited > > >>> file at: > > >>> https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms > > >>> containing the term name, definition and other Mandatory > > >>> metadata items as > > >>> listed on the wiki: > > >>> > https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata > > >>> > > >>> For those on that call, if have have missed any other > important > > >>> information for this item, please add. > > >>> > > >>> Trish > > >>> > > >>> > -------------------------------------------------------------- > > >>> ----------- > > >>> Take Surveys. Earn Cash. Influence the Future of IT > > >>> Join SourceForge.net's Techsay panel and you'll get the > > >>> chance to share your > > >>> opinions on IT & business topics through brief surveys-and > > earn cash > > >>> > http://www.techsay.com/default.php?page=join.php&p=sourceforge > <http://www.techsay.com/default.php?page=join.php&p=sourceforge> > > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge > <http://www.techsay.com/default.php?page=join.php&p=sourceforge>> > > >>> > > >> &CID=DEVDEV > > >> > > >>> _______________________________________________ > > >>> Obi-devel mailing list > > >>> Obi...@li... > <mailto:Obi...@li...> > > <mailto:Obi...@li... > <mailto:Obi...@li...>> > > >>> https://lists.sourceforge.net/lists/listinfo/obi-devel > <https://lists.sourceforge.net/lists/listinfo/obi-devel> > > >>> > > >>> > > >> > > >> > > >> > > > ------------------------------------------------------------------------- > > >> Take Surveys. Earn Cash. Influence the Future of IT > > >> Join SourceForge.net's Techsay panel and you'll get the > chance > > to share your > > >> opinions on IT & business topics through brief > surveys-and earn > > cash > > >> > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > < > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>> > > >> _______________________________________________ > > >> Obi-devel mailing list > > >> Obi...@li... > <mailto:Obi...@li...> > > <mailto: Obi...@li... > <mailto:Obi...@li...>> > > >> https://lists.sourceforge.net/lists/listinfo/obi-devel > > >> > > > > > > -- > > > > > > _______________________________________________________________________________________ > > > > > > > > Dr. Daniel Schober > > > > > > NET Project - Ontologist > > > > > > The European Bioinformatics Institute > > email: sc...@eb... <mailto:sc...@eb...> > <mailto:sc...@eb... <mailto:sc...@eb...>> > > > EMBL Outstation - Hinxton direct: +44 > (0)1223 494410 > > > Wellcome Trust Genome Campus fax: +44 (0)1223 > 494 468 > > > Cambridge CB10 1SD, UK Room: A2-37 > > > > > > Project page: www.ebi.ac.uk/net-project > <http://www.ebi.ac.uk/net-project> > > <http://www.ebi.ac.uk/net-project> > > > > > > Personal > > > page: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 > > > > Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > ------------------------------------------------------------------------- > > > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net 's Techsay panel and you'll get the > chance > > to share your > > > opinions on IT & business topics through brief surveys-and > earn > > cash > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>> > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > Psidev-ms-dev mailing list > > > Psi...@li... > <mailto:Psi...@li...> > > <mailto: Psi...@li... > <mailto:Psi...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > chr...@eb... <mailto:chr...@eb...> > <mailto:chr...@eb... <mailto:chr...@eb...>> > > http://mibbi.sf.net/ <http://mibbi.sf.net/> > <http://mibbi.sf.net/> > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the > chance to > > share your > > opinions on IT & business topics through brief surveys-and > earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>> > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > <mailto:Psi...@li...> > > <mailto: Psi...@li... > <mailto:Psi...@li...>> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > <https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev> > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance > to share your > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Obi-devel mailing list > > Obi...@li... > <mailto:Obi...@li...> > > https://lists.sourceforge.net/lists/listinfo/obi-devel > <https://lists.sourceforge.net/lists/listinfo/obi-devel> > > > > -- > Helen Parkinson, PhD > Curation Coordinator > Microarray Informatics Team, > EBI > > EBI 01223 494672 > Skype: helen.parkinson.ebi > > -- Helen Parkinson, PhD Curation Coordinator Microarray Informatics Team, EBI EBI 01223 494672 Skype: helen.parkinson.ebi |
|
From: frank g. <Fra...@nc...> - 2007-03-20 13:35:35
|
Hi The next PSI meeting is due to be held on the 23-25th April. It would be great if something was prepared, even only for discussion, for this date. Cheers Frank On 3/20/07, Helen Parkinson <par...@eb...> wrote: > > Hi > > this was mentioned in a call last week and is also needed for MO. I > think we will need some guidelines on this, > > cheers > > Helen > > frank gibson wrote: > > Hi > > > > I would also like to highlight, that if term definitions or > > hierarchies are changed within OBI from the original CVs there needs > > to be some sort of feedback or mapping presented back to the PSI. As > > Daniel points out these exist for a particular purpose and for a > > particular community, if they dont find the terms they expect in OBI > > then they wont use it. Hopefully this feedback will also help develop > > more well designed CVs in the future. > > > > Frank > > > > On 3/20/07, *Chris Taylor* <chr...@eb... > > <mailto:chr...@eb...>> wrote: > > > > Just in passing, its worth remembering also that (for example) > > the MS terms in OBI should also be amenable to use by > > metabolomics people, MS-based nucleotide sequencers, etc. > > > > I believe there is still a plan to 'flag' terms as appropriate > > to a particular domain (such as proteomics), but the use of > > omics-based conceptions of the world to shape the structure of > > the ontology is dysfunctional and won't feature in OBI per se. > > > > Cheers, Chris. > > > > > > Daniel Schober wrote: > > > Hello Stefan, OBI developers and PSI MS developers. > > > Yes, the OBI instrument branch will have to review PSI term > > definitions > > > for scope and applicability in OBI. Keep in mind that the PSI > > artifacts > > > are less formal CVs and were mostly created in 'xml style'. That > > is why > > > their graph/taxonomy is often 'xmlienated' (build using is-a _and_ > > > part-of relations in one hierarchy). Their CVs also do not use > > any top > > > level ontology and they sometimes have terms from the > > epistemiological > > > level as part of their compound term names, e.g. Detector _Type_ > and > > > Analyzer _Description_. Sometimes they are not really explicit, > > using > > > 'ellipses' for term names, e.g. 'secondary electron' is_a > 'detector > > > type'. It should be 'secondary electron detector' is_a > > 'detector' instead. > > > But they concentrate on their domain only and have a specific > > > application in mind. They never claimed to be fully ontological > > in the > > > first place. All that lead them to be very narrowing in their > > > definitions sometimes. So, Stefan is right. In many cases we > > have to > > > refine the definitions and render them applicable in a more > > general way > > > and e.g. a 'detector' class would be defined more broadly, and > would > > > probably get a mass_spectroscopy_detector subclass with would > > correspond > > > to the MS 'detector'. > > > I assume that some of these glitches will vanish once the PSI > design > > > principles document ( including the naming conventions, > > > http://www.psidev.info/index.php?q=node/100 ) will be approved and > > > applied within PSI. > > > > > > Best regards, > > > Daniel Schober. > > > > > > Stefan Wiemann wrote: > > >> I have had a look at the PSI_MS-InstrumentTermsForOBI file. > > >> This contains <term names> that are quite common also in other > > communities, > > >> however used there in a different sense. For example, the term > > <Accuracy> is > > >> defined as the "Accuracy of mass assignment", the term > > <Chromatography> as > > >> "Chromatographic conditions used to obtain the sample". I feel > > that this > > >> narrow definition of some terms might cause problems as the > > same terms may > > >> be used with a wider focus in other communities (Accuracy could > > also be the > > >> accuracy of a very different measurement, chromatography can be > > purely > > >> analytical). A <detector type> characterizes also the data > > acquisition > > >> mechanism in a video microscope, a FACS, or a plate reader. How > > is this > > >> terminology dealt with in OBI? > > >> Stefan > > >> > > >> > > >>> -----Original Message----- > > >>> From: obi...@li... > > <mailto:obi...@li...> > > >>> [mailto:obi...@li... > > <mailto:obi...@li...>] On Behalf Of > > >>> Trish Whetzel > > >>> Sent: Tuesday, March 20, 2007 12:55 AM > > >>> To: OBI Developers > > >>> Subject: [Obi-devel] Instrument Branch Scope > > >>> > > >>> Just a quick note, those on the Instrument Branch call last > week > > >>> decided that for terms such as petri dish, gel tank, cage > > >>> etc. that we > > >>> would like to collect these terms and work out a location for > > >>> them in OBI. > > >>> If your community has these kinds of terms, please post a > > >>> tab-delimited > > >>> file at: > > >>> https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms > > >>> containing the term name, definition and other Mandatory > > >>> metadata items as > > >>> listed on the wiki: > > >>> https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata > > >>> > > >>> For those on that call, if have have missed any other important > > >>> information for this item, please add. > > >>> > > >>> Trish > > >>> > > >>> -------------------------------------------------------------- > > >>> ----------- > > >>> Take Surveys. Earn Cash. Influence the Future of IT > > >>> Join SourceForge.net's Techsay panel and you'll get the > > >>> chance to share your > > >>> opinions on IT & business topics through brief surveys-and > > earn cash > > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge > > <http://www.techsay.com/default.php?page=join.php&p=sourceforge> > > >>> > > >> &CID=DEVDEV > > >> > > >>> _______________________________________________ > > >>> Obi-devel mailing list > > >>> Obi...@li... > > <mailto:Obi...@li...> > > >>> https://lists.sourceforge.net/lists/listinfo/obi-devel > > >>> > > >>> > > >> > > >> > > >> > > > ------------------------------------------------------------------------- > > >> Take Surveys. Earn Cash. Influence the Future of IT > > >> Join SourceForge.net's Techsay panel and you'll get the chance > > to share your > > >> opinions on IT & business topics through brief surveys-and earn > > cash > > >> > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > < > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > >> _______________________________________________ > > >> Obi-devel mailing list > > >> Obi...@li... > > <mailto:Obi...@li...> > > >> https://lists.sourceforge.net/lists/listinfo/obi-devel > > >> > > > > > > -- > > > > > > _______________________________________________________________________________________ > > > > > > > > Dr. Daniel Schober > > > > > > NET Project - Ontologist > > > > > > The European Bioinformatics Institute > > email: sc...@eb... <mailto:sc...@eb...> > > > EMBL Outstation - Hinxton direct: +44 (0)1223 494410 > > > Wellcome Trust Genome Campus fax: +44 (0)1223 494 468 > > > Cambridge CB10 1SD, UK Room: A2-37 > > > > > > Project page: www.ebi.ac.uk/net-project > > <http://www.ebi.ac.uk/net-project> > > > > > > Personal > > page: > http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 > > > Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------- > > > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance > > to share your > > > opinions on IT & business topics through brief surveys-and earn > > cash > > > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > < > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > Psidev-ms-dev mailing list > > > Psi...@li... > > <mailto:Psi...@li...> > > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > chr...@eb... <mailto:chr...@eb...> > > http://mibbi.sf.net/ <http://mibbi.sf.net/> > > ~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to > > share your > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > < > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > <mailto:Psi...@li...> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Obi-devel mailing list > > Obi...@li... > > https://lists.sourceforge.net/lists/listinfo/obi-devel > > > > -- > Helen Parkinson, PhD > Curation Coordinator > Microarray Informatics Team, > EBI > > EBI 01223 494672 > Skype: helen.parkinson.ebi > > |
|
From: Helen P. <par...@eb...> - 2007-03-20 13:16:29
|
Hi this was mentioned in a call last week and is also needed for MO. I think we will need some guidelines on this, cheers Helen frank gibson wrote: > Hi > > I would also like to highlight, that if term definitions or > hierarchies are changed within OBI from the original CVs there needs > to be some sort of feedback or mapping presented back to the PSI. As > Daniel points out these exist for a particular purpose and for a > particular community, if they dont find the terms they expect in OBI > then they wont use it. Hopefully this feedback will also help develop > more well designed CVs in the future. > > Frank > > On 3/20/07, *Chris Taylor* <chr...@eb... > <mailto:chr...@eb...>> wrote: > > Just in passing, its worth remembering also that (for example) > the MS terms in OBI should also be amenable to use by > metabolomics people, MS-based nucleotide sequencers, etc. > > I believe there is still a plan to 'flag' terms as appropriate > to a particular domain (such as proteomics), but the use of > omics-based conceptions of the world to shape the structure of > the ontology is dysfunctional and won't feature in OBI per se. > > Cheers, Chris. > > > Daniel Schober wrote: > > Hello Stefan, OBI developers and PSI MS developers. > > Yes, the OBI instrument branch will have to review PSI term > definitions > > for scope and applicability in OBI. Keep in mind that the PSI > artifacts > > are less formal CVs and were mostly created in 'xml style'. That > is why > > their graph/taxonomy is often 'xmlienated' (build using is-a _and_ > > part-of relations in one hierarchy). Their CVs also do not use > any top > > level ontology and they sometimes have terms from the > epistemiological > > level as part of their compound term names, e.g. Detector _Type_ and > > Analyzer _Description_. Sometimes they are not really explicit, > using > > 'ellipses' for term names, e.g. 'secondary electron' is_a 'detector > > type'. It should be 'secondary electron detector' is_a > 'detector' instead. > > But they concentrate on their domain only and have a specific > > application in mind. They never claimed to be fully ontological > in the > > first place. All that lead them to be very narrowing in their > > definitions sometimes. So, Stefan is right. In many cases we > have to > > refine the definitions and render them applicable in a more > general way > > and e.g. a 'detector' class would be defined more broadly, and would > > probably get a mass_spectroscopy_detector subclass with would > correspond > > to the MS 'detector'. > > I assume that some of these glitches will vanish once the PSI design > > principles document ( including the naming conventions, > > http://www.psidev.info/index.php?q=node/100 ) will be approved and > > applied within PSI. > > > > Best regards, > > Daniel Schober. > > > > Stefan Wiemann wrote: > >> I have had a look at the PSI_MS-InstrumentTermsForOBI file. > >> This contains <term names> that are quite common also in other > communities, > >> however used there in a different sense. For example, the term > <Accuracy> is > >> defined as the "Accuracy of mass assignment", the term > <Chromatography> as > >> "Chromatographic conditions used to obtain the sample". I feel > that this > >> narrow definition of some terms might cause problems as the > same terms may > >> be used with a wider focus in other communities (Accuracy could > also be the > >> accuracy of a very different measurement, chromatography can be > purely > >> analytical). A <detector type> characterizes also the data > acquisition > >> mechanism in a video microscope, a FACS, or a plate reader. How > is this > >> terminology dealt with in OBI? > >> Stefan > >> > >> > >>> -----Original Message----- > >>> From: obi...@li... > <mailto:obi...@li...> > >>> [mailto:obi...@li... > <mailto:obi...@li...>] On Behalf Of > >>> Trish Whetzel > >>> Sent: Tuesday, March 20, 2007 12:55 AM > >>> To: OBI Developers > >>> Subject: [Obi-devel] Instrument Branch Scope > >>> > >>> Just a quick note, those on the Instrument Branch call last week > >>> decided that for terms such as petri dish, gel tank, cage > >>> etc. that we > >>> would like to collect these terms and work out a location for > >>> them in OBI. > >>> If your community has these kinds of terms, please post a > >>> tab-delimited > >>> file at: > >>> https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms > >>> containing the term name, definition and other Mandatory > >>> metadata items as > >>> listed on the wiki: > >>> https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata > >>> > >>> For those on that call, if have have missed any other important > >>> information for this item, please add. > >>> > >>> Trish > >>> > >>> -------------------------------------------------------------- > >>> ----------- > >>> Take Surveys. Earn Cash. Influence the Future of IT > >>> Join SourceForge.net's Techsay panel and you'll get the > >>> chance to share your > >>> opinions on IT & business topics through brief surveys-and > earn cash > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge > <http://www.techsay.com/default.php?page=join.php&p=sourceforge> > >>> > >> &CID=DEVDEV > >> > >>> _______________________________________________ > >>> Obi-devel mailing list > >>> Obi...@li... > <mailto:Obi...@li...> > >>> https://lists.sourceforge.net/lists/listinfo/obi-devel > >>> > >>> > >> > >> > >> > ------------------------------------------------------------------------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance > to share your > >> opinions on IT & business topics through brief surveys-and earn > cash > >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > >> _______________________________________________ > >> Obi-devel mailing list > >> Obi...@li... > <mailto:Obi...@li...> > >> https://lists.sourceforge.net/lists/listinfo/obi-devel > >> > > > > -- > > > _______________________________________________________________________________________ > > > > > Dr. Daniel Schober > > > > NET Project - Ontologist > > > > The European Bioinformatics Institute > email: sc...@eb... <mailto:sc...@eb...> > > EMBL Outstation - Hinxton direct: +44 (0)1223 494410 > > Wellcome Trust Genome Campus fax: +44 (0)1223 494 468 > > Cambridge CB10 1SD, UK Room: A2-37 > > > > Project page: www.ebi.ac.uk/net-project > <http://www.ebi.ac.uk/net-project> > > > > Personal > page: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 > > Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance > to share your > > opinions on IT & business topics through brief surveys-and earn > cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > <mailto:Psi...@li...> > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~ > chr...@eb... <mailto:chr...@eb...> > http://mibbi.sf.net/ <http://mibbi.sf.net/> > ~~~~~~~~~~~~~~~~~~~~~~~~ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > <mailto:Psi...@li...> > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > Obi-devel mailing list > Obi...@li... > https://lists.sourceforge.net/lists/listinfo/obi-devel > -- Helen Parkinson, PhD Curation Coordinator Microarray Informatics Team, EBI EBI 01223 494672 Skype: helen.parkinson.ebi |
|
From: frank g. <Fra...@nc...> - 2007-03-20 12:54:21
|
Hi I would also like to highlight, that if term definitions or hierarchies are changed within OBI from the original CVs there needs to be some sort of feedback or mapping presented back to the PSI. As Daniel points out these exist for a particular purpose and for a particular community, if they dont find the terms they expect in OBI then they wont use it. Hopefully this feedback will also help develop more well designed CVs in the future. Frank On 3/20/07, Chris Taylor <chr...@eb...> wrote: > > Just in passing, its worth remembering also that (for example) > the MS terms in OBI should also be amenable to use by > metabolomics people, MS-based nucleotide sequencers, etc. > > I believe there is still a plan to 'flag' terms as appropriate > to a particular domain (such as proteomics), but the use of > omics-based conceptions of the world to shape the structure of > the ontology is dysfunctional and won't feature in OBI per se. > > Cheers, Chris. > > > Daniel Schober wrote: > > Hello Stefan, OBI developers and PSI MS developers. > > Yes, the OBI instrument branch will have to review PSI term definitions > > for scope and applicability in OBI. Keep in mind that the PSI artifacts > > are less formal CVs and were mostly created in 'xml style'. That is why > > their graph/taxonomy is often 'xmlienated' (build using is-a _and_ > > part-of relations in one hierarchy). Their CVs also do not use any top > > level ontology and they sometimes have terms from the epistemiological > > level as part of their compound term names, e.g. Detector _Type_ and > > Analyzer _Description_. Sometimes they are not really explicit, using > > 'ellipses' for term names, e.g. 'secondary electron' is_a 'detector > > type'. It should be 'secondary electron detector' is_a 'detector' > instead. > > But they concentrate on their domain only and have a specific > > application in mind. They never claimed to be fully ontological in the > > first place. All that lead them to be very narrowing in their > > definitions sometimes. So, Stefan is right. In many cases we have to > > refine the definitions and render them applicable in a more general way > > and e.g. a 'detector' class would be defined more broadly, and would > > probably get a mass_spectroscopy_detector subclass with would correspond > > to the MS 'detector'. > > I assume that some of these glitches will vanish once the PSI design > > principles document ( including the naming conventions, > > http://www.psidev.info/index.php?q=node/100 ) will be approved and > > applied within PSI. > > > > Best regards, > > Daniel Schober. > > > > Stefan Wiemann wrote: > >> I have had a look at the PSI_MS-InstrumentTermsForOBI file. > >> This contains <term names> that are quite common also in other > communities, > >> however used there in a different sense. For example, the term > <Accuracy> is > >> defined as the "Accuracy of mass assignment", the term <Chromatography> > as > >> "Chromatographic conditions used to obtain the sample". I feel that > this > >> narrow definition of some terms might cause problems as the same terms > may > >> be used with a wider focus in other communities (Accuracy could also be > the > >> accuracy of a very different measurement, chromatography can be purely > >> analytical). A <detector type> characterizes also the data acquisition > >> mechanism in a video microscope, a FACS, or a plate reader. How is this > >> terminology dealt with in OBI? > >> Stefan > >> > >> > >>> -----Original Message----- > >>> From: obi...@li... > >>> [mailto:obi...@li...] On Behalf Of > >>> Trish Whetzel > >>> Sent: Tuesday, March 20, 2007 12:55 AM > >>> To: OBI Developers > >>> Subject: [Obi-devel] Instrument Branch Scope > >>> > >>> Just a quick note, those on the Instrument Branch call last week > >>> decided that for terms such as petri dish, gel tank, cage > >>> etc. that we > >>> would like to collect these terms and work out a location for > >>> them in OBI. > >>> If your community has these kinds of terms, please post a > >>> tab-delimited > >>> file at: > >>> https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms > >>> containing the term name, definition and other Mandatory > >>> metadata items as > >>> listed on the wiki: > >>> https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata > >>> > >>> For those on that call, if have have missed any other important > >>> information for this item, please add. > >>> > >>> Trish > >>> > >>> -------------------------------------------------------------- > >>> ----------- > >>> Take Surveys. Earn Cash. Influence the Future of IT > >>> Join SourceForge.net's Techsay panel and you'll get the > >>> chance to share your > >>> opinions on IT & business topics through brief surveys-and earn cash > >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge > >>> > >> &CID=DEVDEV > >> > >>> _______________________________________________ > >>> Obi-devel mailing list > >>> Obi...@li... > >>> https://lists.sourceforge.net/lists/listinfo/obi-devel > >>> > >>> > >> > >> > >> > ------------------------------------------------------------------------- > >> Take Surveys. Earn Cash. Influence the Future of IT > >> Join SourceForge.net's Techsay panel and you'll get the chance to share > your > >> opinions on IT & business topics through brief surveys-and earn cash > >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >> _______________________________________________ > >> Obi-devel mailing list > >> Obi...@li... > >> https://lists.sourceforge.net/lists/listinfo/obi-devel > >> > > > > -- > > > _______________________________________________________________________________________ > > > > Dr. Daniel Schober > > > > NET Project - Ontologist > > > > The European Bioinformatics Institute email: sc...@eb... > > EMBL Outstation - Hinxton direct: +44 (0)1223 494410 > > Wellcome Trust Genome Campus fax: +44 (0)1223 494 468 > > Cambridge CB10 1SD, UK Room: A2-37 > > > > Project page: www.ebi.ac.uk/net-project > > > > Personal page: > http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 > > Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~ > chr...@eb... > http://mibbi.sf.net/ > ~~~~~~~~~~~~~~~~~~~~~~~~ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > |
|
From: Chris T. <chr...@eb...> - 2007-03-20 12:08:28
|
Just in passing, its worth remembering also that (for example) the MS terms in OBI should also be amenable to use by metabolomics people, MS-based nucleotide sequencers, etc. I believe there is still a plan to 'flag' terms as appropriate to a particular domain (such as proteomics), but the use of omics-based conceptions of the world to shape the structure of the ontology is dysfunctional and won't feature in OBI per se. Cheers, Chris. Daniel Schober wrote: > Hello Stefan, OBI developers and PSI MS developers. > Yes, the OBI instrument branch will have to review PSI term definitions > for scope and applicability in OBI. Keep in mind that the PSI artifacts > are less formal CVs and were mostly created in 'xml style'. That is why > their graph/taxonomy is often 'xmlienated' (build using is-a _and_ > part-of relations in one hierarchy). Their CVs also do not use any top > level ontology and they sometimes have terms from the epistemiological > level as part of their compound term names, e.g. Detector _Type_ and > Analyzer _Description_. Sometimes they are not really explicit, using > 'ellipses' for term names, e.g. 'secondary electron' is_a 'detector > type'. It should be 'secondary electron detector' is_a 'detector' instead. > But they concentrate on their domain only and have a specific > application in mind. They never claimed to be fully ontological in the > first place. All that lead them to be very narrowing in their > definitions sometimes. So, Stefan is right. In many cases we have to > refine the definitions and render them applicable in a more general way > and e.g. a 'detector' class would be defined more broadly, and would > probably get a mass_spectroscopy_detector subclass with would correspond > to the MS 'detector'. > I assume that some of these glitches will vanish once the PSI design > principles document ( including the naming conventions, > http://www.psidev.info/index.php?q=node/100 ) will be approved and > applied within PSI. > > Best regards, > Daniel Schober. > > Stefan Wiemann wrote: >> I have had a look at the PSI_MS-InstrumentTermsForOBI file. >> This contains <term names> that are quite common also in other communities, >> however used there in a different sense. For example, the term <Accuracy> is >> defined as the "Accuracy of mass assignment", the term <Chromatography> as >> "Chromatographic conditions used to obtain the sample". I feel that this >> narrow definition of some terms might cause problems as the same terms may >> be used with a wider focus in other communities (Accuracy could also be the >> accuracy of a very different measurement, chromatography can be purely >> analytical). A <detector type> characterizes also the data acquisition >> mechanism in a video microscope, a FACS, or a plate reader. How is this >> terminology dealt with in OBI? >> Stefan >> >> >>> -----Original Message----- >>> From: obi...@li... >>> [mailto:obi...@li...] On Behalf Of >>> Trish Whetzel >>> Sent: Tuesday, March 20, 2007 12:55 AM >>> To: OBI Developers >>> Subject: [Obi-devel] Instrument Branch Scope >>> >>> Just a quick note, those on the Instrument Branch call last week >>> decided that for terms such as petri dish, gel tank, cage >>> etc. that we >>> would like to collect these terms and work out a location for >>> them in OBI. >>> If your community has these kinds of terms, please post a >>> tab-delimited >>> file at: >>> https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms >>> containing the term name, definition and other Mandatory >>> metadata items as >>> listed on the wiki: >>> https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata >>> >>> For those on that call, if have have missed any other important >>> information for this item, please add. >>> >>> Trish >>> >>> -------------------------------------------------------------- >>> ----------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the >>> chance to share your >>> opinions on IT & business topics through brief surveys-and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge >>> >> &CID=DEVDEV >> >>> _______________________________________________ >>> Obi-devel mailing list >>> Obi...@li... >>> https://lists.sourceforge.net/lists/listinfo/obi-devel >>> >>> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Obi-devel mailing list >> Obi...@li... >> https://lists.sourceforge.net/lists/listinfo/obi-devel >> > > -- > _______________________________________________________________________________________ > > Dr. Daniel Schober > > NET Project - Ontologist > > The European Bioinformatics Institute email: sc...@eb... > EMBL Outstation - Hinxton direct: +44 (0)1223 494410 > Wellcome Trust Genome Campus fax: +44 (0)1223 494 468 > Cambridge CB10 1SD, UK Room: A2-37 > > Project page: www.ebi.ac.uk/net-project > > Personal page: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 > Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev -- ~~~~~~~~~~~~~~~~~~~~~~~~ chr...@eb... http://mibbi.sf.net/ ~~~~~~~~~~~~~~~~~~~~~~~~ |
|
From: Daniel S. <sc...@eb...> - 2007-03-20 11:46:39
|
Hello Stefan, OBI developers and PSI MS developers. Yes, the OBI instrument branch will have to review PSI term definitions for scope and applicability in OBI. Keep in mind that the PSI artifacts are less formal CVs and were mostly created in 'xml style'. That is why their graph/taxonomy is often 'xmlienated' (build using is-a _and_ part-of relations in one hierarchy). Their CVs also do not use any top level ontology and they sometimes have terms from the epistemiological level as part of their compound term names, e.g. Detector _Type_ and Analyzer _Description_. Sometimes they are not really explicit, using 'ellipses' for term names, e.g. 'secondary electron' is_a 'detector type'. It should be 'secondary electron detector' is_a 'detector' instead. But they concentrate on their domain only and have a specific application in mind. They never claimed to be fully ontological in the first place. All that lead them to be very narrowing in their definitions sometimes. So, Stefan is right. In many cases we have to refine the definitions and render them applicable in a more general way and e.g. a 'detector' class would be defined more broadly, and would probably get a mass_spectroscopy_detector subclass with would correspond to the MS 'detector'. I assume that some of these glitches will vanish once the PSI design principles document ( including the naming conventions, http://www.psidev.info/index.php?q=node/100 ) will be approved and applied within PSI. Best regards, Daniel Schober. Stefan Wiemann wrote: >I have had a look at the PSI_MS-InstrumentTermsForOBI file. >This contains <term names> that are quite common also in other communities, >however used there in a different sense. For example, the term <Accuracy> is >defined as the "Accuracy of mass assignment", the term <Chromatography> as >"Chromatographic conditions used to obtain the sample". I feel that this >narrow definition of some terms might cause problems as the same terms may >be used with a wider focus in other communities (Accuracy could also be the >accuracy of a very different measurement, chromatography can be purely >analytical). A <detector type> characterizes also the data acquisition >mechanism in a video microscope, a FACS, or a plate reader. How is this >terminology dealt with in OBI? >Stefan > > > >>-----Original Message----- >>From: obi...@li... >>[mailto:obi...@li...] On Behalf Of >>Trish Whetzel >>Sent: Tuesday, March 20, 2007 12:55 AM >>To: OBI Developers >>Subject: [Obi-devel] Instrument Branch Scope >> >>Just a quick note, those on the Instrument Branch call last week >>decided that for terms such as petri dish, gel tank, cage >>etc. that we >>would like to collect these terms and work out a location for >>them in OBI. >>If your community has these kinds of terms, please post a >>tab-delimited >>file at: >>https://www.cbil.upenn.edu/obiwiki/index.php/InstrumentTerms >>containing the term name, definition and other Mandatory >>metadata items as >>listed on the wiki: >>https://www.cbil.upenn.edu/obiwiki/index.php/WorkshopMetadata >> >>For those on that call, if have have missed any other important >>information for this item, please add. >> >>Trish >> >>-------------------------------------------------------------- >>----------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the >>chance to share your >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge >> >> >&CID=DEVDEV > > >>_______________________________________________ >>Obi-devel mailing list >>Obi...@li... >>https://lists.sourceforge.net/lists/listinfo/obi-devel >> >> >> > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Obi-devel mailing list >Obi...@li... >https://lists.sourceforge.net/lists/listinfo/obi-devel > > -- _______________________________________________________________________________________ Dr. Daniel Schober NET Project - Ontologist The European Bioinformatics Institute email: sc...@eb... EMBL Outstation - Hinxton direct: +44 (0)1223 494410 Wellcome Trust Genome Campus fax: +44 (0)1223 494 468 Cambridge CB10 1SD, UK Room: A2-37 Project page: www.ebi.ac.uk/net-project Personal page: http://www.ebi.ac.uk/Information/Staff/person_maint.php?s_person_id=734 Former home page: http://www.bioinf.mdc-berlin.de/%7Eschober/ |
|
From: Pierre-Alain B. <pie...@is...> - 2007-03-06 20:32:07
|
Sorry if you get multiple posts, and please distribute to people who might be interested. *The HUPO-PSI Spring Meeting 2007 is quickly approaching, register now!* Come and join us April 23-25th, 2007, at the Ecole Normale Supérieure (ENS) in Lyon (France) for the Spring meeting 2007 of the HUPO Proteomics Standards Initiative. A unique opportunity to participate in the development of current standards in Proteomics. The PSI working groups are targeting to discuss and deliver a number of standards, including (not exhaustively) - dataXML 1.0 for MS data, - schema for AnalysisXML, - Controlled Vocabularies for a number of PSI modules, - Interactome Quality Assessment and Quality Control, - MIAPE documentation for still remaining modules (column chromatography, capillary electrophoresis), - GelML 1.0, - spML, - Synchronisation of PSI-MOD. ** Detailed information and registration form can be found at http://psidev.info/index.php?q=node/113 Looking forward to seeing you in Lyon, For the meeting organisation committee and the PSI Steering Group Pierre-Alain Binz -- -- Dr. Pierre-Alain Binz Swiss Institute of Bioinformatics Proteome Informatics Group 1, Rue Michel Servet CH-1211 Geneve 4 Switzerland - - - - - - - - - - - - - - - - - Tel: +41-22-379 50 50 Fax: +41-22-379 58 58 Pie...@is... http://www.expasy.org/people/Pierre-Alain.Binz.html |
|
From: Kent L. <knl...@in...> - 2007-02-28 21:26:43
|
Hi Phil, dataRDF, anyone? ;-) It was late here when I read your first message. At this point there is really only one mechanism whereby you could nest/chain params. This comes by virtue of the fact that one of the element types allowed in the sequence under paramGroup is paramGroupRef, whose ref attribute holds the id of the of the paramGroup being referred to. You could also put in a userParam with a name or whatever to give it semantic "labeling" for your particular purpose. Any combination of lists, trees, etc. of linked param structure could be made, but as you imply, it can become a semantic wild west, so to speak. So we put in a structure that would be an improvement over the existing userParam/cvParam scheme while not being a brick wall for more creative uses. I think the real answer will only come when we are able to specify the computationally (i.e. implemented in software) mapping between a semantic structure in OBO/OWL/RDF (conforming to restrictions dictated by the standard's specifications/governance). I think this area should be a focus in the upcoming spring meeting. As always, good to hear from you Phil, a voice of reason and pragmatism. Regards, Kent > -----Original Message----- > From: Philip Jones [mailto:pj...@eb...]=20 > Sent: Wednesday, February 28, 2007 5:14 AM > To: Kent Laursen; psi...@li... > Subject: Re: [Psidev-ms-dev] Associating CV / ontology annotations >=20 > Hi Kent, >=20 > I have taken a closer look at the ParamGroup and=20 > ParamGroupList elements as you suggested. >=20 > These elements work extremely well for defining common /=20 > default sets of params that will be repeated identically for=20 > multiple annotations and as I recall this was their original purpose. >=20 > I do not think however that they solve the problem I=20 > described in my previous email, for two reasons. >=20 > First of all, taking the instance document located at > http://psidev.sourceforge.net/docstore/download.php?&id=3D121=20 > as an example, you can put any combination of cvParams into a=20 > ParamGroup element. The semantics of their association in=20 > this element is not defined, so they could be grouped=20 > together simply because they are a set of default values, as=20 > in the example instance document, or they could be grouped=20 > together because one param is an annotation of the other,=20 > which is the use case I described in my email. There is no=20 > attribute or other mechanism to indicate which of these two=20 > cases is being described. >=20 > Secondly, take the situation that the file contains a=20 > thousand spectra. =20 > You wish to annotate each spectrum with different=20 > information, but in each case you wish to use two or more=20 > associated cvParams for the annotation. If you use the=20 > ParamGroupList for this purpose, you would end up with a=20 > thousand isolated ParamGroup elements at the top of the file=20 > that would need to be cross referenced from the spectrum elements. =20 > This would create problems for parsers that would need to=20 > either hop backwards and forwards in the file or store the=20 > details of all of the ParamGroup elements before parsing the=20 > spectrum elements. >=20 > Best regards, >=20 > Phil. >=20 > Kent Laursen wrote: > > Hi Phil, > > > > Have a closer look at the ParamGoup and ParamGroupList types. They=20 > > were designed with this sort of flexibility and=20 > aggregability in mind. > > > > Regards, > > > > Kent > > > > =20 > >> -----Original Message----- > >> From: psi...@li... > >> [mailto:psi...@li...] On Behalf Of=20 > >> Philip Jones > >> Sent: Tuesday, February 27, 2007 1:18 PM > >> To: psi...@li... > >> Subject: [Psidev-ms-dev] Associating CV / ontology annotations > >> > >> Hi, > >> > >> I would like to suggest that it may be useful to include a=20 > mechanism=20 > >> to associate cvParam elements together to allow more complex=20 > >> annotation of entities in dataXML. Here is an artificial=20 > example to=20 > >> illustrate the > >> problem: > >> > >> <activation> > >> <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044" = name=3D"Method"=20 > >> value=3D"CID"/> > >> <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20 > >> name=3D"CollisionEnergy" value=3D"35.00"/> > >> <cvParam cvLabel=3D"UO" accession=3D"UO:0000112"=20 > >> name=3D"Joule"/> </activation> > >> > >> In this example, the third CV parameter is an annotation of the=20 > >> second, indicating the units of the value of collision energy from=20 > >> the OBO unit ontology. (I know that collision energy is normally=20 > >> measured in eV, but eV is not in the UO ontology ! .... Just an=20 > >> example.) > >> > >> So the question is, do we need this mechanism and if so, how do we=20 > >> implement it? > >> > >> From my point of view, I think it is needed. I have wanted to be=20 > >> able to do this on numerous occasions when creating PRIDE=20 > entries for=20 > >> submissions - PRIDE uses the existing mzData schema=20 > cvParam mechanism=20 > >> for annotation. > >> > >> I think this could / should be kept simple. It would be easy to=20 > >> allow an arbitrarily complex hierarchy of terms to be=20 > created, but I=20 > >> think that might result in chaos. > >> > >> Two possible solutions: > >> > >> 1. Perhaps just add an optional attribute to allow associated=20 > >> cvParams to be linked, e.g. with a number or perhaps=20 > something more=20 > >> guaranteed to be unique, like an LSID? > >> > >> 2. Perhaps add a single additional layer to the hierarchy,=20 > something=20 > >> like this: > >> > >> <activation> > >> <annotation> > >> <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044"=20 > name=3D"Method"=20 > >> value=3D"CID"/> > >> </annotation> > >> <annotation> > >> <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20 > >> name=3D"CollisionEnergy" value=3D"35.00"/> > >> <cvParam cvLabel=3D"UO" accession=3D"UO:0000112" = name=3D"Joule"/> > >> </annotation> > >> </activation> > >> > >> Best regards, > >> > >> Phil. > >> > >> -- > >> _______________________________________ > >> Phil Jones > >> Software Engineer > >> PRIDE Project Team > >> Sequence Database Group > >> EMBL-EBI > >> Wellcome Trust Genome Campus > >> Hinxton > >> Cambridge > >> CB10 1SD > >> UK > >> > >> Tel +44 (0)1223 492 610 (Direct Line) mailto:pj...@eb... > >> > >> > >> -------------------------------------------------------------- > >> ----------- > >> Take Surveys. Earn Cash. Influence the Future of IT Join=20 > >> SourceForge.net's Techsay panel and you'll get the chance to=20 > >> share your opinions on IT & business topics through brief=20 > >> surveys-and earn cash=20 > >> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > >> =20 > > &CID=3DDEVDEV > > =20 > >> _______________________________________________ > >> Psidev-ms-dev mailing list > >> Psi...@li... > >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > >> > >> =20 >=20 >=20 > --=20 > _______________________________________ > Phil Jones > Software Engineer > BioSapiens / PRIDE Project Team > Sequence Database Group > EMBL-EBI > Wellcome Trust Genome Campus > Hinxton > Cambridge > CB10 1SD > UK >=20 > Tel +44 (0)1223 492 610 (Direct Line) > mailto:pj...@eb... >=20 >=20 |
|
From: Angel P. <an...@ma...> - 2007-02-28 13:58:09
|
y, these are issues that caused many headaches for FuGE developers. There is always a trade-off between doc size and parsing simplicity. We didn't come up with any better a solution with respect to hopping around the document to get annotations, but at least there are ways of representing related sets of terms and instance values. This should only be an issue for API developers though, and once one sensible API is written, everyone else can base their efforts on that. So I realize that was no help, but maybe a comparison of how FuGE treats CV's to dataXML would be? -angel On 2/28/07, Philip Jones <pj...@eb...> wrote: > > Hi Kent, > > I have taken a closer look at the ParamGroup and ParamGroupList elements > as you suggested. > > These elements work extremely well for defining common / default sets of > params that will be repeated identically for multiple annotations and as > I recall this was their original purpose. > > I do not think however that they solve the problem I described in my > previous email, for two reasons. > > First of all, taking the instance document located at > http://psidev.sourceforge.net/docstore/download.php?&id=121 as an > example, you can put any combination of cvParams into a ParamGroup > element. The semantics of their association in this element is not > defined, so they could be grouped together simply because they are a set > of default values, as in the example instance document, or they could be > grouped together because one param is an annotation of the other, which > is the use case I described in my email. There is no attribute or other > mechanism to indicate which of these two cases is being described. > > Secondly, take the situation that the file contains a thousand spectra. > You wish to annotate each spectrum with different information, but in > each case you wish to use two or more associated cvParams for the > annotation. If you use the ParamGroupList for this purpose, you would > end up with a thousand isolated ParamGroup elements at the top of the > file that would need to be cross referenced from the spectrum elements. > This would create problems for parsers that would need to either hop > backwards and forwards in the file or store the details of all of the > ParamGroup elements before parsing the spectrum elements. > > Best regards, > > Phil. > > Kent Laursen wrote: > > Hi Phil, > > > > Have a closer look at the ParamGoup and ParamGroupList types. They were > > designed with this sort of flexibility and aggregability in mind. > > > > Regards, > > > > Kent > > > > > >> -----Original Message----- > >> From: psi...@li... > >> [mailto:psi...@li...] On > >> Behalf Of Philip Jones > >> Sent: Tuesday, February 27, 2007 1:18 PM > >> To: psi...@li... > >> Subject: [Psidev-ms-dev] Associating CV / ontology annotations > >> > >> Hi, > >> > >> I would like to suggest that it may be useful to include a > >> mechanism to associate cvParam elements together to allow > >> more complex annotation of entities in dataXML. Here is an > >> artificial example to illustrate the > >> problem: > >> > >> <activation> > >> <cvParam cvLabel="PSI" accession="PSI:1000044" name="Method" > >> value="CID"/> > >> <cvParam cvLabel="PSI" accession="PSI:1000045" > >> name="CollisionEnergy" value="35.00"/> > >> <cvParam cvLabel="UO" accession="UO:0000112" > >> name="Joule"/> </activation> > >> > >> In this example, the third CV parameter is an annotation of > >> the second, indicating the units of the value of collision > >> energy from the OBO unit ontology. (I know that collision > >> energy is normally measured in eV, but eV is not in the UO > >> ontology ! .... Just an example.) > >> > >> So the question is, do we need this mechanism and if so, how > >> do we implement it? > >> > >> From my point of view, I think it is needed. I have wanted > >> to be able to do this on numerous occasions when creating > >> PRIDE entries for submissions - PRIDE uses the existing > >> mzData schema cvParam mechanism for annotation. > >> > >> I think this could / should be kept simple. It would be easy > >> to allow an arbitrarily complex hierarchy of terms to be > >> created, but I think that might result in chaos. > >> > >> Two possible solutions: > >> > >> 1. Perhaps just add an optional attribute to allow associated > >> cvParams to be linked, e.g. with a number or perhaps > >> something more guaranteed to be unique, like an LSID? > >> > >> 2. Perhaps add a single additional layer to the hierarchy, > >> something like this: > >> > >> <activation> > >> <annotation> > >> <cvParam cvLabel="PSI" accession="PSI:1000044" name="Method" > >> value="CID"/> > >> </annotation> > >> <annotation> > >> <cvParam cvLabel="PSI" accession="PSI:1000045" > >> name="CollisionEnergy" value="35.00"/> > >> <cvParam cvLabel="UO" accession="UO:0000112" name="Joule"/> > >> </annotation> > >> </activation> > >> > >> Best regards, > >> > >> Phil. > >> > >> -- > >> _______________________________________ > >> Phil Jones > >> Software Engineer > >> PRIDE Project Team > >> Sequence Database Group > >> EMBL-EBI > >> Wellcome Trust Genome Campus > >> Hinxton > >> Cambridge > >> CB10 1SD > >> UK > >> > >> Tel +44 (0)1223 492 610 (Direct Line) > >> mailto:pj...@eb... > >> > >> > >> -------------------------------------------------------------- > >> ----------- > >> Take Surveys. Earn Cash. Influence the Future of IT Join > >> SourceForge.net's Techsay panel and you'll get the chance to > >> share your opinions on IT & business topics through brief > >> surveys-and earn cash > >> http://www.techsay.com/default.php?page=join.php&p=sourceforge > >> > > &CID=DEVDEV > > > >> _______________________________________________ > >> Psidev-ms-dev mailing list > >> Psi...@li... > >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > >> > >> > > > -- > _______________________________________ > Phil Jones > Software Engineer > BioSapiens / PRIDE Project Team > Sequence Database Group > EMBL-EBI > Wellcome Trust Genome Campus > Hinxton > Cambridge > CB10 1SD > UK > > Tel +44 (0)1223 492 610 (Direct Line) > mailto:pj...@eb... > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > -- Angel Pizarro Director, Bioinformatics Facility Institute for Translational Medicine and Therapeutics University of Pennsylvania 806 BRB II/III 421 Curie Blvd. Philadelphia, PA 19104-6160 P: 215-573-3736 F: 215-573-9004 |
|
From: Philip J. <pj...@eb...> - 2007-02-28 10:15:19
|
Hi Kent, I have taken a closer look at the ParamGroup and ParamGroupList elements as you suggested. These elements work extremely well for defining common / default sets of params that will be repeated identically for multiple annotations and as I recall this was their original purpose. I do not think however that they solve the problem I described in my previous email, for two reasons. First of all, taking the instance document located at http://psidev.sourceforge.net/docstore/download.php?&id=121 as an example, you can put any combination of cvParams into a ParamGroup element. The semantics of their association in this element is not defined, so they could be grouped together simply because they are a set of default values, as in the example instance document, or they could be grouped together because one param is an annotation of the other, which is the use case I described in my email. There is no attribute or other mechanism to indicate which of these two cases is being described. Secondly, take the situation that the file contains a thousand spectra. You wish to annotate each spectrum with different information, but in each case you wish to use two or more associated cvParams for the annotation. If you use the ParamGroupList for this purpose, you would end up with a thousand isolated ParamGroup elements at the top of the file that would need to be cross referenced from the spectrum elements. This would create problems for parsers that would need to either hop backwards and forwards in the file or store the details of all of the ParamGroup elements before parsing the spectrum elements. Best regards, Phil. Kent Laursen wrote: > Hi Phil, > > Have a closer look at the ParamGoup and ParamGroupList types. They were > designed with this sort of flexibility and aggregability in mind. > > Regards, > > Kent > > >> -----Original Message----- >> From: psi...@li... >> [mailto:psi...@li...] On >> Behalf Of Philip Jones >> Sent: Tuesday, February 27, 2007 1:18 PM >> To: psi...@li... >> Subject: [Psidev-ms-dev] Associating CV / ontology annotations >> >> Hi, >> >> I would like to suggest that it may be useful to include a >> mechanism to associate cvParam elements together to allow >> more complex annotation of entities in dataXML. Here is an >> artificial example to illustrate the >> problem: >> >> <activation> >> <cvParam cvLabel="PSI" accession="PSI:1000044" name="Method" >> value="CID"/> >> <cvParam cvLabel="PSI" accession="PSI:1000045" >> name="CollisionEnergy" value="35.00"/> >> <cvParam cvLabel="UO" accession="UO:0000112" >> name="Joule"/> </activation> >> >> In this example, the third CV parameter is an annotation of >> the second, indicating the units of the value of collision >> energy from the OBO unit ontology. (I know that collision >> energy is normally measured in eV, but eV is not in the UO >> ontology ! .... Just an example.) >> >> So the question is, do we need this mechanism and if so, how >> do we implement it? >> >> From my point of view, I think it is needed. I have wanted >> to be able to do this on numerous occasions when creating >> PRIDE entries for submissions - PRIDE uses the existing >> mzData schema cvParam mechanism for annotation. >> >> I think this could / should be kept simple. It would be easy >> to allow an arbitrarily complex hierarchy of terms to be >> created, but I think that might result in chaos. >> >> Two possible solutions: >> >> 1. Perhaps just add an optional attribute to allow associated >> cvParams to be linked, e.g. with a number or perhaps >> something more guaranteed to be unique, like an LSID? >> >> 2. Perhaps add a single additional layer to the hierarchy, >> something like this: >> >> <activation> >> <annotation> >> <cvParam cvLabel="PSI" accession="PSI:1000044" name="Method" >> value="CID"/> >> </annotation> >> <annotation> >> <cvParam cvLabel="PSI" accession="PSI:1000045" >> name="CollisionEnergy" value="35.00"/> >> <cvParam cvLabel="UO" accession="UO:0000112" name="Joule"/> >> </annotation> >> </activation> >> >> Best regards, >> >> Phil. >> >> -- >> _______________________________________ >> Phil Jones >> Software Engineer >> PRIDE Project Team >> Sequence Database Group >> EMBL-EBI >> Wellcome Trust Genome Campus >> Hinxton >> Cambridge >> CB10 1SD >> UK >> >> Tel +44 (0)1223 492 610 (Direct Line) >> mailto:pj...@eb... >> >> >> -------------------------------------------------------------- >> ----------- >> Take Surveys. Earn Cash. Influence the Future of IT Join >> SourceForge.net's Techsay panel and you'll get the chance to >> share your opinions on IT & business topics through brief >> surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge >> > &CID=DEVDEV > >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> -- _______________________________________ Phil Jones Software Engineer BioSapiens / PRIDE Project Team Sequence Database Group EMBL-EBI Wellcome Trust Genome Campus Hinxton Cambridge CB10 1SD UK Tel +44 (0)1223 492 610 (Direct Line) mailto:pj...@eb... |
|
From: Kent L. <knl...@in...> - 2007-02-28 02:32:42
|
Hi Phil, Have a closer look at the ParamGoup and ParamGroupList types. They were designed with this sort of flexibility and aggregability in mind. Regards, Kent=20 > -----Original Message----- > From: psi...@li...=20 > [mailto:psi...@li...] On=20 > Behalf Of Philip Jones > Sent: Tuesday, February 27, 2007 1:18 PM > To: psi...@li... > Subject: [Psidev-ms-dev] Associating CV / ontology annotations >=20 > Hi, >=20 > I would like to suggest that it may be useful to include a=20 > mechanism to associate cvParam elements together to allow=20 > more complex annotation of entities in dataXML. Here is an=20 > artificial example to illustrate the > problem: >=20 > <activation> > <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044" name=3D"Method" = > value=3D"CID"/> > <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20 > name=3D"CollisionEnergy" value=3D"35.00"/> > <cvParam cvLabel=3D"UO" accession=3D"UO:0000112"=20 > name=3D"Joule"/> </activation> >=20 > In this example, the third CV parameter is an annotation of=20 > the second, indicating the units of the value of collision=20 > energy from the OBO unit ontology. (I know that collision=20 > energy is normally measured in eV, but eV is not in the UO=20 > ontology ! .... Just an example.) >=20 > So the question is, do we need this mechanism and if so, how=20 > do we implement it? >=20 > From my point of view, I think it is needed. I have wanted=20 > to be able to do this on numerous occasions when creating=20 > PRIDE entries for submissions - PRIDE uses the existing=20 > mzData schema cvParam mechanism for annotation. >=20 > I think this could / should be kept simple. It would be easy=20 > to allow an arbitrarily complex hierarchy of terms to be=20 > created, but I think that might result in chaos.=20 >=20 > Two possible solutions: >=20 > 1. Perhaps just add an optional attribute to allow associated=20 > cvParams to be linked, e.g. with a number or perhaps=20 > something more guaranteed to be unique, like an LSID? >=20 > 2. Perhaps add a single additional layer to the hierarchy,=20 > something like this: >=20 > <activation> > <annotation> > <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044" = name=3D"Method"=20 > value=3D"CID"/> > </annotation> > <annotation> > <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20 > name=3D"CollisionEnergy" value=3D"35.00"/> > <cvParam cvLabel=3D"UO" accession=3D"UO:0000112" = name=3D"Joule"/> > </annotation> > </activation> >=20 > Best regards, >=20 > Phil. >=20 > -- > _______________________________________ > Phil Jones > Software Engineer > PRIDE Project Team > Sequence Database Group > EMBL-EBI > Wellcome Trust Genome Campus > Hinxton > Cambridge > CB10 1SD > UK >=20 > Tel +44 (0)1223 492 610 (Direct Line) > mailto:pj...@eb... >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys-and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge &CID=3DDEVDEV > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >=20 |
|
From: Philip J. <pj...@eb...> - 2007-02-27 18:18:53
|
Hi,
I would like to suggest that it may be useful to include a mechanism to
associate cvParam elements together to allow more complex annotation of
entities in dataXML. Here is an artificial example to illustrate the
problem:
<activation>
<cvParam cvLabel="PSI" accession="PSI:1000044" name="Method"
value="CID"/>
<cvParam cvLabel="PSI" accession="PSI:1000045"
name="CollisionEnergy" value="35.00"/>
<cvParam cvLabel="UO" accession="UO:0000112" name="Joule"/>
</activation>
In this example, the third CV parameter is an annotation of the second,
indicating the units of the value of collision energy from the OBO unit
ontology. (I know that collision energy is normally measured in eV, but
eV is not in the UO ontology ! .... Just an example.)
So the question is, do we need this mechanism and if so, how do we
implement it?
From my point of view, I think it is needed. I have wanted to be able
to do this on numerous occasions when creating PRIDE entries for
submissions - PRIDE uses the existing mzData schema cvParam mechanism
for annotation.
I think this could / should be kept simple. It would be easy to allow
an arbitrarily complex hierarchy of terms to be created, but I think
that might result in chaos.
Two possible solutions:
1. Perhaps just add an optional attribute to allow associated cvParams
to be linked, e.g. with a number or perhaps something more guaranteed to
be unique, like an LSID?
2. Perhaps add a single additional layer to the hierarchy, something
like this:
<activation>
<annotation>
<cvParam cvLabel="PSI" accession="PSI:1000044" name="Method"
value="CID"/>
</annotation>
<annotation>
<cvParam cvLabel="PSI" accession="PSI:1000045"
name="CollisionEnergy" value="35.00"/>
<cvParam cvLabel="UO" accession="UO:0000112" name="Joule"/>
</annotation>
</activation>
Best regards,
Phil.
--
_______________________________________
Phil Jones
Software Engineer
PRIDE Project Team
Sequence Database Group
EMBL-EBI
Wellcome Trust Genome Campus
Hinxton
Cambridge
CB10 1SD
UK
Tel +44 (0)1223 492 610 (Direct Line)
mailto:pj...@eb...
|
|
From: Pierre-Alain B. <pie...@is...> - 2007-02-26 20:04:44
|
Dear all, this is to remind you that we will have a MS group phone conf tomorrow Tue Feb. 27th, 8amPST (4pm GMT). Agenda: - first feedbacks about dataXML 0.9 - pre-Lyon activities For those who want to join and do not know how, drop me an email. Pierre-Alain |
|
From: David C. <dc...@ma...> - 2007-02-12 14:57:18
|
Hi Fabio, This list is for psi related issues. Normally better to ask this sort of question by sending an email to su...@ma... Answers in-line below: Fabio Cerqueira wrote: > Hi, > > Does anybody there use Mascot for protein identification by MS/MS ion serch? > I'm trying to use it for the first time, but I don't know how options to > choose for > fixed and variable modifications. > > Concerning the fixed modifications I'd like to indicate a C-term mass of > 14.01570; and for the amino acids C, D, E the masses: 160.03068, > 129.04264, and 143.05829, respectively. Carbamidomethyl (C) Methyl (DE) > > Concerning the variable modifications, I'd like to indicate phosphorylation, > oxidation of methionine and loss of water in amino acids S and T. > Phosphorylation and oxidation of methionine are easy. > But I don't know > how option to choose concerning the loss of water in S and T. Probably easiest to select an instrument type that deals with loss of water in the relevant ions series: http://www.matrixscience.com/help/search_field_help.html#INSTRUMENT Best regards, David > > Could anybody help me? > > Thanks, Fabio. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev -- David Creasy Matrix Science 64 Baker Street London W1U 7GB, UK Tel: +44 (0)20 7486 1050 Fax: +44 (0)20 7224 1344 dc...@ma... http://www.matrixscience.com |
|
From: David C. <su...@ma...> - 2007-02-12 14:43:11
|
Hi Fabio, This list is for psi related issues. Normally better to ask this sort of question by sending an email to su...@ma... Answers in-line below: Fabio Cerqueira wrote: > Hi, > > Does anybody there use Mascot for protein identification by MS/MS ion serch? > I'm trying to use it for the first time, but I don't know how options to > choose for > fixed and variable modifications. > > Concerning the fixed modifications I'd like to indicate a C-term mass of > 14.01570; and for the amino acids C, D, E the masses: 160.03068, > 129.04264, and 143.05829, respectively. Carbamidomethyl (C) Methyl (DE) > > Concerning the variable modifications, I'd like to indicate phosphorylation, > oxidation of methionine and loss of water in amino acids S and T. > Phosphorylation and oxidation of methionine are easy. > But I don't know > how option to choose concerning the loss of water in S and T. Probably easiest to select an instrument type that deals with loss of water in the relevant ions series: http://www.matrixscience.com/help/search_field_help.html#INSTRUMENT Best regards, David > > Could anybody help me? > > Thanks, Fabio. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev -- David Creasy Matrix Science 64 Baker Street London W1U 7GB, UK Tel: +44 (0)20 7486 1050 Fax: +44 (0)20 7224 1344 dc...@ma... http://www.matrixscience.com |
|
From: Fabio C. <frc...@gm...> - 2007-02-12 13:42:52
|
Hi, Does anybody there use Mascot for protein identification by MS/MS ion serch? I'm trying to use it for the first time, but I don't know how options to choose for fixed and variable modifications. Concerning the fixed modifications I'd like to indicate a C-term mass of 14.01570; and for the amino acids C, D, E the masses: 160.03068, 129.04264, and 143.05829, respectively. Concerning the variable modifications, I'd like to indicate phosphorylation, oxidation of methionine and loss of water in amino acids S and T. Phosphorylation and oxidation of methionine are easy. But I don't know how option to choose concerning the loss of water in S and T. Could anybody help me? Thanks, Fabio. |
|
From: Pierre-Alain B. <pie...@is...> - 2007-02-08 09:33:34
|
Dear all, Eric Deutsch is compiling all feedbacks for dataXML (Either made directly to him or to the list). All issues that can be solved before Lyon are welcome to be tracked. All others will be addressed in Lyon Do not hesitate to make your comments ASAP, so that we can remove all blocking issues before April 23. We'll make a status at the next phone conference, Feb 27th, 8amPST. Regards, Pierre-Alain Kent Laursen wrote: > Hi Alexandre, > > I can quickly answer question 1. You're preferred form of fileName has > been requested by multiople parties, and the unofficial consensus is > that it should be of the form. > > <fileName><![CDATA[....]]></fileName> > > The issue of the the value of a controlled vocabulary term be in the > element content as opposed to an attribute has also been discussed, but > without apparent consensus. > > We should build a concise list that we can work from at the conference. > > Regards, > > Kent > > > >> -----Original Message----- >> From: psi...@li... >> [mailto:psi...@li...] On >> Behalf Of Alexandre Masselot >> Sent: Wednesday, February 07, 2007 5:11 AM >> To: psi...@li... >> Subject: Re: [Psidev-ms-dev] X-IMail-SPAM-URL-DBL Comments on >> dataXML0.9 >> >> >> Hi a few comments after a quick glance: >> >> 1) Attribute limit (this was already a comment a few months ago)? >> >> <sourceFile id="1" fileName="ICAT_test4.RAW" >> filePath="file://F:/for Jim" fileType="RAW 2.0" >> >> we shall not put file name or whatever "rich" info into >> attribute, or will have to encode/decode it everytime. Think >> of all the strange character that can come here (every one, >> by far do not use [\w+] into ther file names... >> unfortunaltely Tag value (so possibly with CDATA) would be >> more than welcome. >> >> <fileName><![CDATA[....]]></fileName> >> >> >> The sam eproblem may occur with things like >> >> <cvParam cvLabel="TMO" accession="TMO:1000001" name="Filter" >> value="+ c d Full ms2 445.35@cid35.00 [ 110.00-905.00]"/> >> >> no? >> >> >> 2) >> multiple charge >> I don't see any example of that in the example, but how will >> we handle multiple charges for >> * parent peak? >> * more difficult (as info is stored into an array): >> fragmentation peaks? >> >> And I'm sure there is something for multiple moz for the precursor >> >> best regards >> Alex >> >> >> Fredrik Levander wrote: >> >>> Hello, >>> >>> After a quick inspection of dataXML0.9, the first >>> >> impression is that >> >>> it looks very promising and that all people working with it >>> >> have done >> >>> some great work in the fusing of the mz's. >>> >>> I've got some small specific comments which I guess you've already >>> discussed, but anyway: >>> >>> 1) The attribute "count" which can be found at some places >>> (softwareList, spectrumList etc) could be more of an >>> >> obstacle than of >> >>> help. There is no easy way to validate that this number corresponds >>> with the actual number of list elements in the XML world. Such a >>> validation would require specific validators for each programming >>> language. In cases where the count attribute is not equal to the >>> number of elements in the list, there could be different parsing >>> results depending on if the implementation is using the 'count' or >>> standard parsing, the later ignoring the count attribute. >>> >> Actually, the example file: >> >> http://db.systemsbiology.net/projects/PSI/dataXML/tiny1.dataXML0.9.xml >> >>> is an example where the softwareList count="2", but the >>> >> actual number >> >>> of elements is 3. >>> I would suggest that either the 'count's are omitted, or >>> >> PSIDEV should >> >>> at some time provide validators which verify that list >>> >> lengths equals >> >>> to the count attribute. Another option is that the attribute is >>> documented only to be used for visual inspection of files, and that >>> the actual number of list elements can differ. Are any of >>> >> the current >> >>> mzData-parsers using the 'count's anyway? >>> >>> 2) The indexing extension of dataXML. It is evident that such an >>> indexing is useful for fast file access, and it should >>> >> definitely be >> >>> part of the standard. However, if I understand the schema correctly >>> (no sample file yet), an indexed file would mean that the >>> >> dataXML is >> >>> encapsuled within the <indexedDataXML>, with the indexing >>> >> information >> >>> at the end of the file. Why not use a separate file for the >>> >> indexing, >> >>> which references the dataXML file as an URI? I think that >>> >> would make >> >>> up for faster data access with the indexes in the beginning of the >>> file, even if the 'indexOffset' should allow for quick >>> >> access to the >> >>> index. A small consideration is that the offset / indexes >>> >> would differ >> >>> depending on if the file is opened in binary or text mode, at least >>> for large files on a Windows system. I know that it is >>> >> working for RAP >> >>> and mzXML, but for new implementations which use other >>> >> libraries and >> >>> file readers there may be problems. Anyway, it should be >>> >> made clear >> >>> that indexes (offsets) are for binary file reading (or text >>> >> if that is >> >>> the case) The fileCheckSum would also become clearer with >>> >> two separate >> >>> files. It is quite complex to have the fileCheckSum of the file >>> contained within the file itself, since the checksum is affected by >>> the writing of the actual checksum ... If the file checksum is >>> contained in a separate file it is clear that the checksum is the >>> checksum of the actual dataXML, excluding the index file. >>> On the other hand it could be more handy to have just one >>> >> file to work >> >>> with, but is it really such an advantage? In cases where the index >>> file is lost it would be easy to generate a new index file with a >>> specific application for generation of dataXML index files anyway. >>> >>> Regards >>> >>> Fredrik Levander >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> >>> --- Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to >>> >> make your job easier. >> >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> >>> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=1216 >> >>> 42 _______________________________________________ >>> Psidev-ms-dev mailing list >>> Psi...@li... >>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >>> >>> >> -- >> Alexandre Masselot, phD >> Senior bioinformatician >> www.genebio.com >> voice: +41 22 702 99 00 >> >> >> >> -------------------------------------------------------------- >> ----------- >> Using Tomcat but need to do more? Need to support web >> services, security? >> Get stuff done quickly with pre-integrated technology to make >> your job easier. >> Download IBM WebSphere Application Server v.1.0.1 based on >> Apache Geronimo >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& >> dat=121642 >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- -- Dr. Pierre-Alain Binz Swiss Institute of Bioinformatics Proteome Informatics Group 1, Rue Michel Servet CH-1211 Geneve 4 Switzerland - - - - - - - - - - - - - - - - - Tel: +41-22-379 50 50 Fax: +41-22-379 58 58 Pie...@is... http://www.expasy.org/people/Pierre-Alain.Binz.html |
|
From: Kent L. <knl...@in...> - 2007-02-07 21:04:02
|
Hi Alexandre, I can quickly answer question 1. You're preferred form of fileName has been requested by multiople parties, and the unofficial consensus is that it should be of the form. <fileName><![CDATA[....]]></fileName> The issue of the the value of a controlled vocabulary term be in the element content as opposed to an attribute has also been discussed, but without apparent consensus. We should build a concise list that we can work from at the conference. Regards, Kent =20 > -----Original Message----- > From: psi...@li...=20 > [mailto:psi...@li...] On=20 > Behalf Of Alexandre Masselot > Sent: Wednesday, February 07, 2007 5:11 AM > To: psi...@li... > Subject: Re: [Psidev-ms-dev] X-IMail-SPAM-URL-DBL Comments on=20 > dataXML0.9 >=20 >=20 > Hi a few comments after a quick glance: >=20 > 1) Attribute limit (this was already a comment a few months ago)? >=20 > <sourceFile id=3D"1" fileName=3D"ICAT_test4.RAW"=20 > filePath=3D"file://F:/for Jim" fileType=3D"RAW 2.0" >=20 > we shall not put file name or whatever "rich" info into=20 > attribute, or will have to encode/decode it everytime. Think=20 > of all the strange character that can come here (every one,=20 > by far do not use [\w+] into ther file names...=20 > unfortunaltely Tag value (so possibly with CDATA) would be=20 > more than welcome. >=20 > <fileName><![CDATA[....]]></fileName> >=20 >=20 > The sam eproblem may occur with things like >=20 > <cvParam cvLabel=3D"TMO" accession=3D"TMO:1000001" name=3D"Filter"=20 > value=3D"+ c d Full ms2 445.35@cid35.00 [ 110.00-905.00]"/> >=20 > no? >=20 >=20 > 2) > multiple charge > I don't see any example of that in the example, but how will=20 > we handle multiple charges for > * parent peak? > * more difficult (as info is stored into an array):=20 > fragmentation peaks? >=20 > And I'm sure there is something for multiple moz for the precursor >=20 > best regards > Alex >=20 >=20 > Fredrik Levander wrote: > > Hello, > > > > After a quick inspection of dataXML0.9, the first=20 > impression is that=20 > > it looks very promising and that all people working with it=20 > have done=20 > > some great work in the fusing of the mz's. > > > > I've got some small specific comments which I guess you've already=20 > > discussed, but anyway: > > > > 1) The attribute "count" which can be found at some places=20 > > (softwareList, spectrumList etc) could be more of an=20 > obstacle than of=20 > > help. There is no easy way to validate that this number corresponds=20 > > with the actual number of list elements in the XML world. Such a=20 > > validation would require specific validators for each programming=20 > > language. In cases where the count attribute is not equal to the=20 > > number of elements in the list, there could be different parsing=20 > > results depending on if the implementation is using the 'count' or=20 > > standard parsing, the later ignoring the count attribute.=20 > Actually, the example file: > >=20 > http://db.systemsbiology.net/projects/PSI/dataXML/tiny1.dataXML0.9.xml > > is an example where the softwareList count=3D"2", but the=20 > actual number=20 > > of elements is 3. > > I would suggest that either the 'count's are omitted, or=20 > PSIDEV should=20 > > at some time provide validators which verify that list=20 > lengths equals=20 > > to the count attribute. Another option is that the attribute is=20 > > documented only to be used for visual inspection of files, and that=20 > > the actual number of list elements can differ. Are any of=20 > the current=20 > > mzData-parsers using the 'count's anyway? > > > > 2) The indexing extension of dataXML. It is evident that such an=20 > > indexing is useful for fast file access, and it should=20 > definitely be=20 > > part of the standard. However, if I understand the schema correctly=20 > > (no sample file yet), an indexed file would mean that the=20 > dataXML is=20 > > encapsuled within the <indexedDataXML>, with the indexing=20 > information=20 > > at the end of the file. Why not use a separate file for the=20 > indexing,=20 > > which references the dataXML file as an URI? I think that=20 > would make=20 > > up for faster data access with the indexes in the beginning of the=20 > > file, even if the 'indexOffset' should allow for quick=20 > access to the=20 > > index. A small consideration is that the offset / indexes=20 > would differ=20 > > depending on if the file is opened in binary or text mode, at least=20 > > for large files on a Windows system. I know that it is=20 > working for RAP=20 > > and mzXML, but for new implementations which use other=20 > libraries and=20 > > file readers there may be problems. Anyway, it should be=20 > made clear=20 > > that indexes (offsets) are for binary file reading (or text=20 > if that is=20 > > the case) The fileCheckSum would also become clearer with=20 > two separate=20 > > files. It is quite complex to have the fileCheckSum of the file=20 > > contained within the file itself, since the checksum is affected by=20 > > the writing of the actual checksum ... If the file checksum is=20 > > contained in a separate file it is clear that the checksum is the=20 > > checksum of the actual dataXML, excluding the index file. > > On the other hand it could be more handy to have just one=20 > file to work=20 > > with, but is it really such an advantage? In cases where the index=20 > > file is lost it would be easy to generate a new index file with a=20 > > specific application for generation of dataXML index files anyway. > > > > Regards > > > > Fredrik Levander > > > > > >=20 > ---------------------------------------------------------------------- > > --- Using Tomcat but need to do more? Need to support web services,=20 > > security? > > Get stuff done quickly with pre-integrated technology to=20 > make your job easier. > > Download IBM WebSphere Application Server v.1.0.1 based on Apache=20 > > Geronimo > >=20 > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 1216 > > 42 _______________________________________________ > > Psidev-ms-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > =20 >=20 > -- > Alexandre Masselot, phD > Senior bioinformatician > www.genebio.com > voice: +41 22 702 99 00 >=20 >=20 >=20 > -------------------------------------------------------------- > ----------- > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on=20 > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > dat=3D121642 > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >=20 |
|
From: Alexandre M. <ol...@ge...> - 2007-02-07 10:13:42
|
Hi a few comments after a quick glance: 1) Attribute limit (this was already a comment a few months ago)? <sourceFile id="1" fileName="ICAT_test4.RAW" filePath="file://F:/for Jim" fileType="RAW 2.0" we shall not put file name or whatever "rich" info into attribute, or will have to encode/decode it everytime. Think of all the strange character that can come here (every one, by far do not use [\w+] into ther file names... unfortunaltely Tag value (so possibly with CDATA) would be more than welcome. <fileName><![CDATA[....]]></fileName> The sam eproblem may occur with things like <cvParam cvLabel="TMO" accession="TMO:1000001" name="Filter" value="+ c d Full ms2 445.35@cid35.00 [ 110.00-905.00]"/> no? 2) multiple charge I don't see any example of that in the example, but how will we handle multiple charges for * parent peak? * more difficult (as info is stored into an array): fragmentation peaks? And I'm sure there is something for multiple moz for the precursor best regards Alex Fredrik Levander wrote: > Hello, > > After a quick inspection of dataXML0.9, the first impression is that it > looks very promising and that all people working with it have done some > great work in the fusing of the mz's. > > I've got some small specific comments which I guess you've already > discussed, but anyway: > > 1) The attribute "count" which can be found at some places > (softwareList, spectrumList etc) could be more of an obstacle than of > help. There is no easy way to validate that this number corresponds with > the actual number of list elements in the XML world. Such a validation > would require specific validators for each programming language. In > cases where the count attribute is not equal to the number of elements > in the list, there could be different parsing results depending on if > the implementation is using the 'count' or standard parsing, the later > ignoring the count attribute. Actually, the example file: > http://db.systemsbiology.net/projects/PSI/dataXML/tiny1.dataXML0.9.xml > is an example where the softwareList count="2", but the actual number of > elements is 3. > I would suggest that either the 'count's are omitted, or PSIDEV should > at some time provide validators which verify that list lengths equals to > the count attribute. Another option is that the attribute is documented > only to be used for visual inspection of files, and that the actual > number of list elements can differ. Are any of the current > mzData-parsers using the 'count's anyway? > > 2) The indexing extension of dataXML. It is evident that such an > indexing is useful for fast file access, and it should definitely be > part of the standard. However, if I understand the schema correctly (no > sample file yet), an indexed file would mean that the dataXML is > encapsuled within the <indexedDataXML>, with the indexing information at > the end of the file. Why not use a separate file for the indexing, which > references the dataXML file as an URI? I think that would make up for > faster data access with the indexes in the beginning of the file, even > if the 'indexOffset' should allow for quick access to the index. A small > consideration is that the offset / indexes would differ depending on if > the file is opened in binary or text mode, at least for large files on a > Windows system. I know that it is working for RAP and mzXML, but for new > implementations which use other libraries and file readers there may be > problems. Anyway, it should be made clear that indexes (offsets) are > for binary file reading (or text if that is the case) > The fileCheckSum would also become clearer with two separate files. It > is quite complex to have the fileCheckSum of the file contained within > the file itself, since the checksum is affected by the writing of the > actual checksum ... If the file checksum is contained in a separate > file it is clear that the checksum is the checksum of the actual > dataXML, excluding the index file. > On the other hand it could be more handy to have just one file to work > with, but is it really such an advantage? In cases where the index file > is lost it would be easy to generate a new index file with a specific > application for generation of dataXML index files anyway. > > Regards > > Fredrik Levander > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > -- Alexandre Masselot, phD Senior bioinformatician www.genebio.com voice: +41 22 702 99 00 |
|
From: Eric D. <ede...@sy...> - 2007-02-06 21:14:24
|
Hi Frederik, thank you for your input. 1) Regarding "count", this is not a settled topic. There are some who would leave them out and some who like them in. The rationale is that for parsers in languages that would like to pre-allocate arrays to hold the information, it is very handy to have a count. Obviously an incorrect count does no one any good. I believe the plan is to write a validator that will validate several items beyond schema compliance including when important ontology terms are present and whether the ontology terms used are vlid. Validating that the count attributes are accurate should be includes. 2) Your input regarding indexes is very valuable. We had decided to maintain the same indexing scheme as used by mzXML for simplicity of porting software and since it seemed to work for everyone who used it. However, the points you bring up are interesting. I was not aware of the Windows OS issues you bring up. I personally find having separate indexes would be less tidy than everything in a single file. Indexing has always been a somewhat contentious issue, but it is worth discussing. Regards, Eric > -----Original Message----- > From: Fredrik Levander [mailto:Fre...@el...] > Sent: Tuesday, February 06, 2007 7:20 AM > To: PSI MS Dev > Cc: Eric Deutsch > Subject: Comments on dataXML0.9 >=20 > Hello, >=20 > After a quick inspection of dataXML0.9, the first impression is that it > looks very promising and that all people working with it have done some > great work in the fusing of the mz's. >=20 > I've got some small specific comments which I guess you've already > discussed, but anyway: >=20 > 1) The attribute "count" which can be found at some places > (softwareList, spectrumList etc) could be more of an obstacle than of > help. There is no easy way to validate that this number corresponds with > the actual number of list elements in the XML world. Such a validation > would require specific validators for each programming language. In > cases where the count attribute is not equal to the number of elements > in the list, there could be different parsing results depending on if > the implementation is using the 'count' or standard parsing, the later > ignoring the count attribute. Actually, the example file: > http://db.systemsbiology.net/projects/PSI/dataXML/tiny1.dataXML0.9.xml > is an example where the softwareList count=3D"2", but the actual = number of > elements is 3. > I would suggest that either the 'count's are omitted, or PSIDEV should > at some time provide validators which verify that list lengths equals to > the count attribute. Another option is that the attribute is documented > only to be used for visual inspection of files, and that the actual > number of list elements can differ. Are any of the current > mzData-parsers using the 'count's anyway? >=20 > 2) The indexing extension of dataXML. It is evident that such an > indexing is useful for fast file access, and it should definitely be > part of the standard. However, if I understand the schema correctly (no > sample file yet), an indexed file would mean that the dataXML is > encapsuled within the <indexedDataXML>, with the indexing information at > the end of the file. Why not use a separate file for the indexing, which > references the dataXML file as an URI? I think that would make up for > faster data access with the indexes in the beginning of the file, even > if the 'indexOffset' should allow for quick access to the index. A small > consideration is that the offset / indexes would differ depending on if > the file is opened in binary or text mode, at least for large files on a > Windows system. I know that it is working for RAP and mzXML, but for new > implementations which use other libraries and file readers there may be > problems. Anyway, it should be made clear that indexes (offsets) are > for binary file reading (or text if that is the case) > The fileCheckSum would also become clearer with two separate files. It > is quite complex to have the fileCheckSum of the file contained within > the file itself, since the checksum is affected by the writing of the > actual checksum ... If the file checksum is contained in a separate > file it is clear that the checksum is the checksum of the actual > dataXML, excluding the index file. > On the other hand it could be more handy to have just one file to work > with, but is it really such an advantage? In cases where the index file > is lost it would be easy to generate a new index file with a specific > application for generation of dataXML index files anyway. >=20 > Regards >=20 > Fredrik Levander |
|
From: Eric D. <ede...@sy...> - 2007-02-06 21:02:47
|
Hi Mike, thank you for your comments. In response, I would say: 1) The detailed prose describing the schema is still something that needs to be done, either before or during the April workshop. 2) Your example of the meaning of m/z should probably be handled in the ontology, because the axis is defined by an ontology keyword. The ontology also needs significant work before or during the workshop. 3) Regarding your question about the type and use of float values, this should indeed be defined. I don't think this was quite so explicitly defined in either of the original specifications, but in any case, we should be as precise as possible for dataXML. Thank you for these comments. Feel free to respond and/or send more. I will assemble a list of open issues to be discussed on the list or in Lyon and resolved before release. Regards, Eric > -----Original Message----- > From: Mike Coleman [mailto:tu...@gm...] > Sent: Tuesday, February 06, 2007 7:53 AM > To: Pierre-Alain Binz; Eric Deutsch > Cc: PSI MS Dev > Subject: Re: [Psidev-ms-dev] dataXML 0.9 ready for first feedbacks >=20 > On 2/6/07, Pierre-Alain Binz <pie...@is...> wrote: > > dataXML (as being the merge between mzData and mzXML, and becoming the > PSI > > MS data standard replacing mzData) is ready for a first feedback from > you, > > implementers and PSI MS active members. We target to finalise version > 1.0 > > right after the next PSI Spring Workshop (see below) >=20 > Looking on this page, the only normative material I'm seeing are the > two XML schema. Is there other material that I'm missing? I would > have expected to see detailed normative prose describing the meaning > and proper usage of the various elements. Without this, implementers > will probably use this schema in incompatible ways, leading to future > headaches. >=20 > Here are a couple of examples of what seems to be missing. I think I > know that the X axis for spectrum data represents M/Z values, where M > is mass in amu's and Z is the integer charge. This ought to be > specified explicitly. >=20 > As a more detailed example, I think I know that spectrum data is > represented as the base64-encoded form of IEEE float values. (This > also needs to be specified.) IEEE floats can take on several special > values like "positive infinity" and error values. Is it legal to > place these values in a dataXML file? Whether or not this is so, what > is a receiver expected to do if it encounters such values? >=20 > As an example of the kind of normative prose I'm thinking of, here is > a link to a working copy of an ANSI C standard >=20 > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf >=20 > (Obviously, the dataXML prose would be much shorter.) >=20 > Another nice thing that the ANSI C committee produces is a rationale > document, which explains the reasoning behind many of the major > decisions taken, correlated to the specification. It would be nice to > have an mzData rationale document as well, to explain the thinking > behind its design decisions (e.g., base64/binary representation of > floats). >=20 > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf >=20 > Regards, > Mike Coleman |
|
From: Mike C. <tu...@gm...> - 2007-02-06 15:52:45
|
On 2/6/07, Pierre-Alain Binz <pie...@is...> wrote:
> dataXML (as being the merge between mzData and mzXML, and becoming the PSI
> MS data standard replacing mzData) is ready for a first feedback from you,
> implementers and PSI MS active members. We target to finalise version 1.0
> right after the next PSI Spring Workshop (see below)
Looking on this page, the only normative material I'm seeing are the
two XML schema. Is there other material that I'm missing? I would
have expected to see detailed normative prose describing the meaning
and proper usage of the various elements. Without this, implementers
will probably use this schema in incompatible ways, leading to future
headaches.
Here are a couple of examples of what seems to be missing. I think I
know that the X axis for spectrum data represents M/Z values, where M
is mass in amu's and Z is the integer charge. This ought to be
specified explicitly.
As a more detailed example, I think I know that spectrum data is
represented as the base64-encoded form of IEEE float values. (This
also needs to be specified.) IEEE floats can take on several special
values like "positive infinity" and error values. Is it legal to
place these values in a dataXML file? Whether or not this is so, what
is a receiver expected to do if it encounters such values?
As an example of the kind of normative prose I'm thinking of, here is
a link to a working copy of an ANSI C standard
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
(Obviously, the dataXML prose would be much shorter.)
Another nice thing that the ANSI C committee produces is a rationale
document, which explains the reasoning behind many of the major
decisions taken, correlated to the specification. It would be nice to
have an mzData rationale document as well, to explain the thinking
behind its design decisions (e.g., base64/binary representation of
floats).
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
Regards,
Mike Coleman
|
|
From: Fredrik L. <Fre...@el...> - 2007-02-06 15:22:02
|
Hello, After a quick inspection of dataXML0.9, the first impression is that it looks very promising and that all people working with it have done some great work in the fusing of the mz's. I've got some small specific comments which I guess you've already discussed, but anyway: 1) The attribute "count" which can be found at some places (softwareList, spectrumList etc) could be more of an obstacle than of help. There is no easy way to validate that this number corresponds with the actual number of list elements in the XML world. Such a validation would require specific validators for each programming language. In cases where the count attribute is not equal to the number of elements in the list, there could be different parsing results depending on if the implementation is using the 'count' or standard parsing, the later ignoring the count attribute. Actually, the example file: http://db.systemsbiology.net/projects/PSI/dataXML/tiny1.dataXML0.9.xml is an example where the softwareList count="2", but the actual number of elements is 3. I would suggest that either the 'count's are omitted, or PSIDEV should at some time provide validators which verify that list lengths equals to the count attribute. Another option is that the attribute is documented only to be used for visual inspection of files, and that the actual number of list elements can differ. Are any of the current mzData-parsers using the 'count's anyway? 2) The indexing extension of dataXML. It is evident that such an indexing is useful for fast file access, and it should definitely be part of the standard. However, if I understand the schema correctly (no sample file yet), an indexed file would mean that the dataXML is encapsuled within the <indexedDataXML>, with the indexing information at the end of the file. Why not use a separate file for the indexing, which references the dataXML file as an URI? I think that would make up for faster data access with the indexes in the beginning of the file, even if the 'indexOffset' should allow for quick access to the index. A small consideration is that the offset / indexes would differ depending on if the file is opened in binary or text mode, at least for large files on a Windows system. I know that it is working for RAP and mzXML, but for new implementations which use other libraries and file readers there may be problems. Anyway, it should be made clear that indexes (offsets) are for binary file reading (or text if that is the case) The fileCheckSum would also become clearer with two separate files. It is quite complex to have the fileCheckSum of the file contained within the file itself, since the checksum is affected by the writing of the actual checksum ... If the file checksum is contained in a separate file it is clear that the checksum is the checksum of the actual dataXML, excluding the index file. On the other hand it could be more handy to have just one file to work with, but is it really such an advantage? In cases where the index file is lost it would be easy to generate a new index file with a specific application for generation of dataXML index files anyway. Regards Fredrik Levander |
|
From: Pierre-Alain B. <pie...@is...> - 2007-02-06 10:03:21
|
Dear mzdata implementers and psi-ms-dev mailing list registrants, 1) *dataXML* dataXML (as being the merge between mzData and mzXML, and becoming the PSI MS data standard replacing mzData) is ready for a first feedback from you, implementers and PSI MS active members. We target to finalise version 1.0 right after the next PSI Spring Workshop (see below) The related documents and information can be obtained on the new PSI website http://psidev.info, and more precisely at http://psidev.info/index.php?q=node/257 The page has a restriction to MS group registrants. If you cannot access the page, you can register to the website and ask to view the MS group information Please look at the documents and feedback to psidev-ms-dev mailing list or to Eric Deutsch directly. 2) *PSI Spring Meeting 2007* I would also like to inform you about the PSI spring meeting http://psidev.info/index.php?q=node/113. It is organized in Lyon, France, April 23-25th, 2007. A preliminary agenda is available. We target to get a version 1.0 of dataXML right after the workshop. The registration is not formally open, but you can already book the dates. Information on hotels will also appear soon. With my best regards Pierre-Alain -- -- Dr. Pierre-Alain Binz Swiss Institute of Bioinformatics Proteome Informatics Group 1, Rue Michel Servet CH-1211 Geneve 4 Switzerland - - - - - - - - - - - - - - - - - Tel: +41-22-379 50 50 Fax: +41-22-379 58 58 Pie...@is... http://www.expasy.org/people/Pierre-Alain.Binz.html |
|
From: Pierre-Alain B. <pie...@is...> - 2006-12-04 17:09:39
|
The only ones I'm aware of are Eric Deutsch and Kent Laursen (both mentioned at the last ccall). I did not get any proposal. Pierre-Alain Randy Julian wrote: > Are there any other nominations - there is a PSI-SG conference call > tomorrow (11am EST/4pm GMT), please forward your nominations for > discussion. > > Thanks, > Randy > > ------------------------------------------------------------------------ > *From:* Randy Julian [mailto:rj...@pu...] > *Sent:* Friday, November 24, 2006 9:29 AM > *To:* 'psi...@li...' > *Cc:* 'ru...@sy...'; 'hh...@eb...'; > 'chr...@eb...'; 'no...@cs...'; > 'k.s...@bi...'; 'or...@eb...'; 'lu...@eb...'; > 'pie...@is...'; 'Sey...@ap...'; > 'joh...@eb...'; 'an...@ma...'; > 'dc...@ma...'; 'Andy Jones' > *Subject:* Call for nominations for PSI-MS Chair > > The PSI-MS Working Group is seeking nominations for the group co-chair > beginning in 2007. The group is current co-chaired by Randy > Julian and Pierre-Alain Binz. Starting in 2007 Randy will focus > on the PSI Steering Group and developing the standards document > process. The role of WG chair is described in the PSI management > documents: > > http://psidev.sourceforge.net/docstore/download.php?id=58 (Overview) > > http://psidev.sourceforge.net/docstore/download.php?id=56 (Management) > http://psidev.sourceforge.net/docstore/download.php?id=57 (Structure) > > Anyone who is actively engaged in the PSI-MS working group who would > like to contribute their leadership to the MS initiative should > contact a Steering Group member. Nominations will be accepted from > the PSI-MS-WG and a final selection will be made by the PSI-SG. > > PSI-SG: > Ruedi Aebersold (ru...@sy... > <mailto:ru...@sy...>) > Henning Hermjakob (hh...@eb... <mailto:hh...@eb...>) > Randy Julian (rj...@pu... <mailto:rj...@pu...>) > Chris Taylor (chr...@eb... <mailto:chr...@eb...>) > Norman Paton (no...@cs... <mailto:no...@cs...>) > Katherine Lilley (k.s...@bi... > <mailto:k.s...@bi...>) > Sandra Orchard (or...@eb... <mailto:or...@eb...>) > Luisa Montecchi (lu...@eb... <mailto:lu...@eb...>) > Pierre-Alain Binz (pie...@is... > <mailto:pie...@is...>) > Sean Seymour (Sey...@ap... > <mailto:Sey...@ap...>) > John Garavelli (joh...@eb... > <mailto:joh...@eb...>) > Angel Pizzaro (an...@ma... <mailto:an...@ma...>) > David Creasy (dc...@ma... > <mailto:dc...@ma...>) > Andy Jones (aj...@cs... <mailto:aj...@cs...>) > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys - and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >------------------------------------------------------------------------ > >_______________________________________________ >Psidev-ms-dev mailing list >Psi...@li... >https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > > -- -- Dr. Pierre-Alain Binz Swiss Institute of Bioinformatics Proteome Informatics Group 1, Rue Michel Servet CH-1211 Geneve 4 Switzerland - - - - - - - - - - - - - - - - - Tel: +41-22-379 50 50 Fax: +41-22-379 58 58 Pie...@is... http://www.expasy.org/people/Pierre-Alain.Binz.html |
49 messages has been excluded from this view by a project administrator.
