Menu
▾
▴
psidev-pi-dev — General Development List for Proteomics Informatics
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(4) |
Oct
(10) |
Nov
(1) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(8) |
May
(40) |
Jun
(30) |
Jul
(61) |
Aug
(21) |
Sep
(12) |
Oct
(56) |
Nov
(99) |
Dec
(83) |
| 2009 |
Jan
(3) |
Feb
(9) |
Mar
(1) |
Apr
(5) |
May
(88) |
Jun
(43) |
Jul
(60) |
Aug
(54) |
Sep
(4) |
Oct
(18) |
Nov
(9) |
Dec
(5) |
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(8) |
May
(10) |
Jun
(8) |
Jul
(10) |
Aug
(18) |
Sep
(11) |
Oct
(19) |
Nov
(14) |
Dec
(26) |
| 2011 |
Jan
(27) |
Feb
(38) |
Mar
(50) |
Apr
(128) |
May
(54) |
Jun
(116) |
Jul
(79) |
Aug
(163) |
Sep
(21) |
Oct
(14) |
Nov
(19) |
Dec
(9) |
| 2012 |
Jan
(7) |
Feb
(34) |
Mar
(34) |
Apr
(50) |
May
(70) |
Jun
(23) |
Jul
(8) |
Aug
(24) |
Sep
(35) |
Oct
(40) |
Nov
(276) |
Dec
(34) |
| 2013 |
Jan
(25) |
Feb
(23) |
Mar
(12) |
Apr
(59) |
May
(31) |
Jun
(11) |
Jul
(21) |
Aug
(7) |
Sep
(18) |
Oct
(11) |
Nov
(12) |
Dec
(18) |
| 2014 |
Jan
(37) |
Feb
(22) |
Mar
(9) |
Apr
(10) |
May
(38) |
Jun
(20) |
Jul
(15) |
Aug
(4) |
Sep
(4) |
Oct
(3) |
Nov
(8) |
Dec
(5) |
| 2015 |
Jan
(13) |
Feb
(34) |
Mar
(27) |
Apr
(5) |
May
(12) |
Jun
(10) |
Jul
(12) |
Aug
(3) |
Sep
(1) |
Oct
(13) |
Nov
|
Dec
(6) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
(17) |
Apr
(139) |
May
(120) |
Jun
(90) |
Jul
(10) |
Aug
|
Sep
|
Oct
(11) |
Nov
(6) |
Dec
(2) |
| 2017 |
Jan
(24) |
Feb
(8) |
Mar
(7) |
Apr
(2) |
May
(5) |
Jun
(11) |
Jul
(5) |
Aug
(9) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(4) |
| 2018 |
Jan
(7) |
Feb
|
Mar
(4) |
Apr
(6) |
May
(10) |
Jun
(6) |
Jul
(7) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(3) |
Dec
(3) |
| 2019 |
Jan
(3) |
Feb
|
Mar
(4) |
Apr
(3) |
May
(2) |
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(12) |
Dec
(1) |
| 2020 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David C. <dc...@ma...> - 2009-05-05 18:19:07
|
Hi, Bringing up an old topic... In the documentation for analysisXML (now called mzIdentML) we have: Spectra represented in mzML (in the <Spectrum> element) have two unique identifiers, one newly generated for mzML stored in the ID attribute, and one using the system above derived from the source file, stored in the nativeID attribute. If the source file is mzML, SpectrumIdentificationResult SHOULD reference the ID in mzML since this value has a data type of xsd:id and is thus guaranteed to be unique. Should this be replaced with something like: Spectra represented in mzML (in the <Spectrum> element) have two unique identifiers, one newly generated for mzML stored in the index attribute, and one using the system above derived from the source file, stored in the id attribute. If the source file is mzML, SpectrumIdentificationResult SHOULD reference the id in mzML since this value is more descriptive and is guaranteed to be unique. David -- 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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: <cod...@go...> - 2009-05-05 15:11:29
|
Comment #1 on issue 48 by dcreasy: calculatedMassToCharge and sequenceMass have the same information http://code.google.com/p/psi-pi/issues/detail?id=48 Pierre-Alain - email: This is only true if chargeState is specified and has only one value that is not 0 or unknown. Is chargeState mandatory and only unique? David: chargeState is not a required attribute. But neither is calculatedMassToCharge. There must have been a reason for having the calculated value in both places, but we can't remember. However, it is useful to have the calculatedMassToCharge here - less calculations for an importer to make. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 14:10:38
|
Comment #4 on issue 47 by delagoya: The name of AnalysisXML http://code.google.com/p/psi-pi/issues/detail?id=47 Agreed in Turku and in email that the analysisXML be split into two file formats, one for identification (mzIdentML), one for quantification (mzQuantML). Proposed file extensions for mzIdentML and mzQuantML are ".mzid" and ".mzqt", respectively. Original email from Andy Jones: Hi all, I have uploaded a new version of the schema updated with the changes agreed in Turku. For those of you not present in Turku, only very minor changes have been made to the core schema in response to reviewers comments. One major change has been made in that the name has changed from analysisXML to mzIdentML. We realise that this is a pretty major decision that we discussed at great length. Working through use cases for quantification demonstrated that quantification support would be far easier to develop in a separate file format to reduce interdependencies – most software packages separate the process of identification from that of quantification. With this being the case AnalysisXML will now become two formats: mzIdentML and mzQuantML. We will re-submit the final changes to the PSI process shortly and mzIdentML is very close to release as a version 1. I anticipate that the name change should not cause a problem with the PSI process since looking over the issues list, this was requested by both Eric and Randy during the process. I’ve uploaded a new schema file to reflect the name change (mzIdentML_working.xsd). The following changes have been made: 1. Changed name of schema, root element and all references from AnalysisXML to mzIdentML 2. Changed SpecificityRule (0 to many) which extended cvParamType: <SpecificityRule accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/> To: SpecificityRules (0 to 1) with a sub-element of cvParam (1 to many) <SpecificityRules> < cvParam accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/> </SpecificityRules> 3. Changed IonType from extending cvParam to having a 1:1 sub-element of cvParam 4. Changed ModParam to have a sub-element cvParam <ModParam massDelta="15.994919" residues="M"> <pf:cvParam accession="UNIMOD:35" name="Oxidation" cvRef="UNIMOD" unitCvRef="UO" unitAccession="UO:0000221"/> </ModParam> 5. Moved peptideSequence above other sub-elements of Peptide – I don’t see this in the minutes but recall this was agreed – correct? If I missed any agreed changes, please let me know ASAP. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 14:10:01
|
Comment #8 on issue 31 by delagoya: Specifying the Search Database(s) Unambiguously - MIRIAM? http://code.google.com/p/psi-pi/issues/detail?id=31 I agree with David. Defer this until there is at least versioned database support. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 14:07:01
|
Comment #6 on issue 31 by delagoya: Specifying the Search Database(s) Unambiguously - MIRIAM? http://code.google.com/p/psi-pi/issues/detail?id=31 E-Mail Comment from Pierre-Alain: Hi: a comment: MIRIAM does not have an entry for Swiss-Prot, for TrEMBL, for uniparc, for uniref etc. Only one for Uniprot (which is by the way not the official abbreviation). Apparently, according to the information Luisa had, ther is no intention to have separate entries for these Uniprot "sub-"databases. It is therefore not usable so far. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 14:01:48
|
Comment #7 on issue 31 by delagoya: Specifying the Search Database(s) Unambiguously - MIRIAM? http://code.google.com/p/psi-pi/issues/detail?id=31 E-Mail comment from David Creasy: Hi Pierre-Alain, Yes, it's not so useful at the moment. Even for IPI it isn't so useful because there is no entry for MSIPI, and I guess it's unlikely that there will be looking at the current strategy. Oh, and it also looks as though the information about IPI is very out of date which doesn't inspire confidence. Um... also a bit strange that there is absolutely no mention of anything from the NCBI. The agreement at the Turku meeting was to make it an option to use miriam *or* the existing the current method. My feeling is now that we should defer supporting it until it's more comprehensive and a little more 'neutral', but we can discuss on the next conference call. Thanks, David -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: Angel P. <del...@gm...> - 2009-05-05 13:59:18
|
Folks, please reply to the issue on the issue list, not email. I already posted these two from Pierre-Alain and David on the issue. -angel On Tue, May 5, 2009 at 8:21 AM, David Creasy <dc...@ma...>wrote: > Hi Pierre-Alain, > > Yes, it's not so useful at the moment. Even for IPI it isn't so useful > because there is no entry for MSIPI, and I guess it's unlikely that > there will be looking at the current strategy. Oh, and it also looks as > though the information about IPI is very out of date which doesn't > inspire confidence. > > Um... also a bit strange that there is absolutely no mention of anything > from the NCBI. > > The agreement at the Turku meeting was to make it an option to use > miriam *or* the existing the current method. My feeling is now that we > should defer supporting it until it's more comprehensive and a little > more 'neutral', but we can discuss on the next conference call. > > Thanks, > > David > > Pierre-Alain Binz wrote: > > Hi: > > a comment: > > MIRIAM does not have an entry for Swiss-Prot, for TrEMBL, for uniparc, > > for uniref etc. Only one for Uniprot (which is by the way not the > > official abbreviation). Apparently, according to the information Luisa > > had, ther is no intention to have separate entries for these Uniprot > > "sub-"databases. It is therefore not usable so far. > > > > Pierre-Alain > > > > cod...@go... wrote: > >> Updates: > >> Status: Started > >> > >> Comment #5 on issue 31 by dcreasy: Specifying the Search Database(s) > >> Unambiguously - MIRIAM? > >> http://code.google.com/p/psi-pi/issues/detail?id=31 > >> > >> At Turku meeting, decided to re-open this issue. Have the option of > >> specifying a > >> miriam id rather than using CV. However, it would not be enough for > >> mzIdentML on it’s > >> own. For example, IPI is a single MIRIAM id, by the files are available > as > >> IPI_Human, > >> IPI_Mouse etc. so it would also need a taxID coupled to it. > >> > >> -- > >> You received this message because you are listed in the owner > >> or CC fields of this issue, or because you starred this issue. > >> You may adjust your issue notification preferences at: > >> http://code.google.com/hosting/settings > >> > ------------------------------------------------------------------------------ > >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > >> production scanning environment may not be a perfect world - but thanks > to > >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > >> Series Scanner you'll get full speed at 300 dpi even with all image > >> processing features enabled. http://p.sf.net/sfu/kodak-com > >> _______________________________________________ > >> Psidev-pi-dev mailing list > >> Psi...@li... > >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > >> > >> > > > > > ------------------------------------------------------------------------------ > > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > > production scanning environment may not be a perfect world - but thanks > to > > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > > Series Scanner you'll get full speed at 300 dpi even with all image > > processing features enabled. http://p.sf.net/sfu/kodak-com > > _______________________________________________ > > Psidev-pi-dev mailing list > > Psi...@li... > > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 > > Matrix Science Ltd. is registered in England and Wales > Company number 3533898 > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > -- Angel |
|
From: David C. <dc...@ma...> - 2009-05-05 12:21:39
|
Hi Pierre-Alain, Yes, it's not so useful at the moment. Even for IPI it isn't so useful because there is no entry for MSIPI, and I guess it's unlikely that there will be looking at the current strategy. Oh, and it also looks as though the information about IPI is very out of date which doesn't inspire confidence. Um... also a bit strange that there is absolutely no mention of anything from the NCBI. The agreement at the Turku meeting was to make it an option to use miriam *or* the existing the current method. My feeling is now that we should defer supporting it until it's more comprehensive and a little more 'neutral', but we can discuss on the next conference call. Thanks, David Pierre-Alain Binz wrote: > Hi: > a comment: > MIRIAM does not have an entry for Swiss-Prot, for TrEMBL, for uniparc, > for uniref etc. Only one for Uniprot (which is by the way not the > official abbreviation). Apparently, according to the information Luisa > had, ther is no intention to have separate entries for these Uniprot > "sub-"databases. It is therefore not usable so far. > > Pierre-Alain > > cod...@go... wrote: >> Updates: >> Status: Started >> >> Comment #5 on issue 31 by dcreasy: Specifying the Search Database(s) >> Unambiguously - MIRIAM? >> http://code.google.com/p/psi-pi/issues/detail?id=31 >> >> At Turku meeting, decided to re-open this issue. Have the option of >> specifying a >> miriam id rather than using CV. However, it would not be enough for >> mzIdentML on it’s >> own. For example, IPI is a single MIRIAM id, by the files are available as >> IPI_Human, >> IPI_Mouse etc. so it would also need a taxID coupled to it. >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings >> ------------------------------------------------------------------------------ >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >> production scanning environment may not be a perfect world - but thanks to >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 >> Series Scanner you'll get full speed at 300 dpi even with all image >> processing features enabled. http://p.sf.net/sfu/kodak-com >> _______________________________________________ >> Psidev-pi-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev >> >> > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-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 Matrix Science Ltd. is registered in England and Wales Company number 3533898 |
|
From: Pierre-Alain B. <pie...@is...> - 2009-05-05 11:53:36
|
This is only true if chargeState is specified and has only one value that is not 0 or unknown. Is chargeState mandatory and only unique? Pierre-Alain cod...@go... wrote: > Status: Accepted > Owner: dcreasy > Labels: Type-Defect Priority-Medium > > New issue 48 by dcreasy: calculatedMassToCharge and sequenceMass have the > same information > http://code.google.com/p/psi-pi/issues/detail?id=48 > > Reported by Eugene Kapp > > <SpectrumIdentificationItem calculatedMassToCharge="670.86261" > chargeState="2" Peptide_ref="peptide_1_1" > > and > > <Peptide id="peptide_1_1" sequenceMass="1341.72522" > > > These both have the same information. Do we really need both? > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > |
|
From: Pierre-Alain B. <pie...@is...> - 2009-05-05 11:49:06
|
Hi: a comment: MIRIAM does not have an entry for Swiss-Prot, for TrEMBL, for uniparc, for uniref etc. Only one for Uniprot (which is by the way not the official abbreviation). Apparently, according to the information Luisa had, ther is no intention to have separate entries for these Uniprot "sub-"databases. It is therefore not usable so far. Pierre-Alain cod...@go... wrote: > Updates: > Status: Started > > Comment #5 on issue 31 by dcreasy: Specifying the Search Database(s) > Unambiguously - MIRIAM? > http://code.google.com/p/psi-pi/issues/detail?id=31 > > At Turku meeting, decided to re-open this issue. Have the option of > specifying a > miriam id rather than using CV. However, it would not be enough for > mzIdentML on it’s > own. For example, IPI is a single MIRIAM id, by the files are available as > IPI_Human, > IPI_Mouse etc. so it would also need a taxID coupled to it. > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Psidev-pi-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev > > |
|
From: <cod...@go...> - 2009-05-05 11:26:27
|
Comment #9 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 Element <DatabaseFilters> Include an example of an exclude value. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:22:23
|
Comment #8 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 Add an example of Element<Modification>, Substitution modification. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:18:23
|
Comment #7 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 Add an example of <pf:components> is used -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:14:26
|
Comment #6 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 No examples of how mzIdentML is tied with mzML. DC to provide one. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:10:25
|
Comment #5 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 Report the type of the decoy: reverse, shuffled, concatenated … Add this to the instance examples. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:06:19
|
Comment #64 on issue 42 by dcreasy: Issues with the CV http://code.google.com/p/psi-pi/issues/detail?id=42 In the PI CV there are peptide and protein Global FDRs. The location for some of the terms in the schema must change. -SpectrumIdentificationList (peptide global FDR). -ProteinIdentificationList (protein global FDR). Solution: Collapse the two terms into one (global FDR). Add this global FDR to the example. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 11:02:18
|
Comment #4 on issue 44 by dcreasy: Issues with all instance docs http://code.google.com/p/psi-pi/issues/detail?id=44 Need to show how chemical and post translational modifications are handled with the 15N example. (DC) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 10:48:11
|
Updates: Status: Started Comment #5 on issue 31 by dcreasy: Specifying the Search Database(s) Unambiguously - MIRIAM? http://code.google.com/p/psi-pi/issues/detail?id=31 At Turku meeting, decided to re-open this issue. Have the option of specifying a miriam id rather than using CV. However, it would not be enough for mzIdentML on it’s own. For example, IPI is a single MIRIAM id, by the files are available as IPI_Human, IPI_Mouse etc. so it would also need a taxID coupled to it. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-05-05 10:44:10
|
Status: Accepted Owner: dcreasy Labels: Type-Defect Priority-Medium New issue 48 by dcreasy: calculatedMassToCharge and sequenceMass have the same information http://code.google.com/p/psi-pi/issues/detail?id=48 Reported by Eugene Kapp <SpectrumIdentificationItem calculatedMassToCharge="670.86261" chargeState="2" Peptide_ref="peptide_1_1" and <Peptide id="peptide_1_1" sequenceMass="1341.72522" These both have the same information. Do we really need both? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: Seymour, S. <Sea...@li...> - 2009-05-01 16:49:46
|
Hi all,
I've very sorry to have missed the meeting this year (for the first time).
Regarding the name change and split, my first reaction was umm... not positive. However, dwelling on it a lot more, I think it may be ok. ID and quant are very naturally connected for some kinds of quant - especially isobaric quant like iTRAQ, but I can see separation as being a very clean and perhaps more flexible way of doing it. Of course, this is all my thinking in the abstract and the specific details in use cases will be very important. There are an awful lot of quant types, but I'm sure you were considering that.
I like Angel's extension suggestions.
Sean
From: Jones, Andy [mailto:And...@li...]
Sent: Friday, May 01, 2009 6:27 AM
To: 'psi...@li...'
Subject: Re: [Psidev-pi-dev] Update from Turku
mzid and mzqt sound good to me and don't see to come up with anything else in google.
Andy
From: Angel Pizarro [mailto:del...@gm...]
Sent: 01 May 2009 14:08
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Update from Turku
Woo-hoo! I have access again to the mail list!
Anywho, re: namechange, previously we had the file extension "axml"
For mzIdentML mzQuantML I propose "mzid" and "mzqt", repsectively. Thoughts?
-angel
2009/5/1 Jones, Andy <And...@li...<mailto:And...@li...>>
Hi all,
I have uploaded a new version of the schema updated with the changes agreed in Turku. For those of you not present in Turku, only very minor changes have been made to the core schema in response to reviewers comments. One major change has been made in that the name has changed from analysisXML to mzIdentML. We realise that this is a pretty major decision that we discussed at great length. Working through use cases for quantification demonstrated that quantification support would be far easier to develop in a separate file format to reduce interdependencies - most software packages separate the process of identification from that of quantification. With this being the case AnalysisXML will now become two formats: mzIdentML and mzQuantML.
We will re-submit the final changes to the PSI process shortly and mzIdentML is very close to release as a version 1. I anticipate that the name change should not cause a problem with the PSI process since looking over the issues list, this was requested by both Eric and Randy during the process.
I've uploaded a new schema file to reflect the name change (mzIdentML_working.xsd). The following changes have been made:
1. Changed name of schema, root element and all references from AnalysisXML to mzIdentML
2. Changed SpecificityRule (0 to many) which extended cvParamType:
<SpecificityRule accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
To:
SpecificityRules (0 to 1) with a sub-element of cvParam (1 to many)
<SpecificityRules>
< cvParam accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
</SpecificityRules>
3. Changed IonType from extending cvParam to having a 1:1 sub-element of cvParam
4. Changed ModParam to have a sub-element cvParam
<ModParam massDelta="15.994919" residues="M">
<pf:cvParam accession="UNIMOD:35" name="Oxidation" cvRef="UNIMOD" unitCvRef="UO" unitAccession="UO:0000221"/>
</ModParam>
5. Moved peptideSequence above other sub-elements of Peptide - I don't see this in the minutes but recall this was agreed - correct?
If I missed any agreed changes, please let me know ASAP.
The next step is for Andreas to update CV and mapping (the CV is now merged with the PSI-MS CV), then we will update the instance docs. I think we will look to have a call next Thurs at 4pm UK time to discuss all the remaining issues.
Best wishes,
Andy
|
|
From: Jones, A. <And...@li...> - 2009-05-01 13:26:42
|
mzid and mzqt sound good to me and don’t see to come up with anything else in google.
Andy
From: Angel Pizarro [mailto:del...@gm...]
Sent: 01 May 2009 14:08
To: psi...@li...
Subject: Re: [Psidev-pi-dev] Update from Turku
Woo-hoo! I have access again to the mail list!
Anywho, re: namechange, previously we had the file extension "axml"
For mzIdentML mzQuantML I propose "mzid" and "mzqt", repsectively. Thoughts?
-angel
2009/5/1 Jones, Andy <And...@li...<mailto:And...@li...>>
Hi all,
I have uploaded a new version of the schema updated with the changes agreed in Turku. For those of you not present in Turku, only very minor changes have been made to the core schema in response to reviewers comments. One major change has been made in that the name has changed from analysisXML to mzIdentML. We realise that this is a pretty major decision that we discussed at great length. Working through use cases for quantification demonstrated that quantification support would be far easier to develop in a separate file format to reduce interdependencies – most software packages separate the process of identification from that of quantification. With this being the case AnalysisXML will now become two formats: mzIdentML and mzQuantML.
We will re-submit the final changes to the PSI process shortly and mzIdentML is very close to release as a version 1. I anticipate that the name change should not cause a problem with the PSI process since looking over the issues list, this was requested by both Eric and Randy during the process.
I’ve uploaded a new schema file to reflect the name change (mzIdentML_working.xsd). The following changes have been made:
1. Changed name of schema, root element and all references from AnalysisXML to mzIdentML
2. Changed SpecificityRule (0 to many) which extended cvParamType:
<SpecificityRule accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
To:
SpecificityRules (0 to 1) with a sub-element of cvParam (1 to many)
<SpecificityRules>
< cvParam accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
</SpecificityRules>
3. Changed IonType from extending cvParam to having a 1:1 sub-element of cvParam
4. Changed ModParam to have a sub-element cvParam
<ModParam massDelta="15.994919" residues="M">
<pf:cvParam accession="UNIMOD:35" name="Oxidation" cvRef="UNIMOD" unitCvRef="UO" unitAccession="UO:0000221"/>
</ModParam>
5. Moved peptideSequence above other sub-elements of Peptide – I don’t see this in the minutes but recall this was agreed – correct?
If I missed any agreed changes, please let me know ASAP.
The next step is for Andreas to update CV and mapping (the CV is now merged with the PSI-MS CV), then we will update the instance docs. I think we will look to have a call next Thurs at 4pm UK time to discuss all the remaining issues.
Best wishes,
Andy
|
|
From: Angel P. <del...@gm...> - 2009-05-01 13:08:10
|
Woo-hoo! I have access again to the mail list! Anywho, re: namechange, previously we had the file extension "axml" For mzIdentML mzQuantML I propose "mzid" and "mzqt", repsectively. Thoughts? -angel 2009/5/1 Jones, Andy <And...@li...> > Hi all, > > > > I have uploaded a new version of the schema updated with the changes agreed > in Turku. For those of you not present in Turku, only very minor changes > have been made to the core schema in response to reviewers comments. One > major change has been made in that the name has changed from analysisXML to > mzIdentML. We realise that this is a pretty major decision that we discussed > at great length. Working through use cases for quantification demonstrated > that quantification support would be far easier to develop in a separate > file format to reduce interdependencies – most software packages separate > the process of identification from that of quantification. With this being > the case AnalysisXML will now become two formats: mzIdentML and mzQuantML. > > > > We will re-submit the final changes to the PSI process shortly and > mzIdentML is very close to release as a version 1. I anticipate that the > name change should not cause a problem with the PSI process since looking > over the issues list, this was requested by both Eric and Randy during the > process. > > > > I’ve uploaded a new schema file to reflect the name change > (mzIdentML_working.xsd). The following changes have been made: > > > > 1. Changed name of schema, root element and all references from AnalysisXML > to mzIdentML > > 2. Changed SpecificityRule (0 to many) which extended cvParamType: > > > > <SpecificityRule accession="PI:00189" cvRef="PSI-PI" name="modification > specificity N-term"/> > > > > To: > > > > SpecificityRules (0 to 1) with a sub-element of cvParam (1 to many) > > > > <SpecificityRules> > > < cvParam accession="PI:00189" cvRef="PSI-PI" name="modification > specificity N-term"/> > > </SpecificityRules> > > > > 3. Changed IonType from extending cvParam to having a 1:1 sub-element of > cvParam > > 4. Changed ModParam to have a sub-element cvParam > > <ModParam massDelta="15.994919" residues="M"> > <pf:cvParam accession="UNIMOD:35" name="Oxidation" > cvRef="UNIMOD" unitCvRef="UO" unitAccession="UO:0000221"/> > </ModParam> > > 5. Moved peptideSequence above other sub-elements of Peptide – I don’t see > this in the minutes but recall this was agreed – correct? > > > > If I missed any agreed changes, please let me know ASAP. > > > > The next step is for Andreas to update CV and mapping (the CV is now merged > with the PSI-MS CV), then we will update the instance docs. I think we will > look to have a call next Thurs at 4pm UK time to discuss all the remaining > issues. > > > > Best wishes, > > Andy > > > |
|
From: Jones, A. <And...@li...> - 2009-05-01 12:54:32
|
Hi all,
I have uploaded a new version of the schema updated with the changes agreed in Turku. For those of you not present in Turku, only very minor changes have been made to the core schema in response to reviewers comments. One major change has been made in that the name has changed from analysisXML to mzIdentML. We realise that this is a pretty major decision that we discussed at great length. Working through use cases for quantification demonstrated that quantification support would be far easier to develop in a separate file format to reduce interdependencies - most software packages separate the process of identification from that of quantification. With this being the case AnalysisXML will now become two formats: mzIdentML and mzQuantML.
We will re-submit the final changes to the PSI process shortly and mzIdentML is very close to release as a version 1. I anticipate that the name change should not cause a problem with the PSI process since looking over the issues list, this was requested by both Eric and Randy during the process.
I've uploaded a new schema file to reflect the name change (mzIdentML_working.xsd). The following changes have been made:
1. Changed name of schema, root element and all references from AnalysisXML to mzIdentML
2. Changed SpecificityRule (0 to many) which extended cvParamType:
<SpecificityRule accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
To:
SpecificityRules (0 to 1) with a sub-element of cvParam (1 to many)
<SpecificityRules>
< cvParam accession="PI:00189" cvRef="PSI-PI" name="modification specificity N-term"/>
</SpecificityRules>
3. Changed IonType from extending cvParam to having a 1:1 sub-element of cvParam
4. Changed ModParam to have a sub-element cvParam
<ModParam massDelta="15.994919" residues="M">
<pf:cvParam accession="UNIMOD:35" name="Oxidation" cvRef="UNIMOD" unitCvRef="UO" unitAccession="UO:0000221"/>
</ModParam>
5. Moved peptideSequence above other sub-elements of Peptide - I don't see this in the minutes but recall this was agreed - correct?
If I missed any agreed changes, please let me know ASAP.
The next step is for Andreas to update CV and mapping (the CV is now merged with the PSI-MS CV), then we will update the instance docs. I think we will look to have a call next Thurs at 4pm UK time to discuss all the remaining issues.
Best wishes,
Andy
|
|
From: <cod...@go...> - 2009-04-29 07:11:29
|
Comment #63 on issue 42 by eisenachM: Issues with the CV http://code.google.com/p/psi-pi/issues/detail?id=42 add database file format "PEFF" -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
|
From: <cod...@go...> - 2009-04-29 06:21:12
|
Updates: Status: Fixed Comment #2 on issue 45 by dcreasy: Number of peptides / proteins to be reported http://code.google.com/p/psi-pi/issues/detail?id=45 Added PassThreshold attribute to SpectrumIdentificationItem and ProteinDetectionHypothesis -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings |
42 messages has been excluded from this view by a project administrator.
