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: Julian U. <not...@gi...> - 2016-05-03 13:27:25
|
@germa send this location for the validator around a while ago: https://github.com/HUPO-PSI/mzIdentML/tree/master/validator/trunk/mzIdentMLValidator Anyways, I would vote rather to have the running validator under the releases of the project instead inside of the code. There are already some old releases, created by @ypriverol during the move to gitHub, I guess. It might be even cleaner to create a new project (HUPO-PSI/mzIdentMLValidator) for it and put the releases there? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/21#issuecomment-216527139 |
|
From: andrewrobertjones <not...@gi...> - 2016-05-03 12:54:23
|
I recall the idea is to have SpectrumIdentificationItem elements for each peptide chain within the group. As such, if there is a light-alpha; heavy-alpha; light-beta and heavy-beta, there would be four SpectrumIdentificationItems elements, each with the correct expMassToCharge and charge value. Does this not work? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19#issuecomment-216517941 |
|
From: andrewrobertjones <not...@gi...> - 2016-05-03 12:46:42
|
@germa Further note, I compiled this locally on Netbeans. When I try to run the validator, I get the following message:
`java.io.FileNotFoundException: E:\Work\PSI\mzIdentML\Git\validator\trunk\resources\validation.properties (The system can
not find the path specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at psidev.psi.pi.validator.PropertyFile.loadProperties(PropertyFile.java:36)
at psidev.psi.pi.validator.MzIdentMLValidatorGUI.getProperty(MzIdentMLValidatorGUI.java:929)
at psidev.psi.pi.validator.MzIdentMLValidatorGUI.getOntologiesFileInputStream(MzIdentMLValidatorGUI.java:757)
at psidev.psi.pi.validator.MzIdentMLValidatorGUI.access$900(MzIdentMLValidatorGUI.java:58)
at psidev.psi.pi.validator.MzIdentMLValidatorGUI$4.loadOntologyFiles(MzIdentMLValidatorGUI.java:723)
at psidev.psi.pi.validator.MzIdentMLValidatorGUI$4.construct(MzIdentMLValidatorGUI.java:655)
at psidev.psi.pi.validator.swingworker.SwingWorker$2.run(SwingWorker.java:147)
at java.lang.Thread.run(Unknown Source)
2016-05-03 13:35:53,020 ERROR MzIdentMLValidatorGUI - No ontologies file for validation.
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException`
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/21#issuecomment-216516295 |
|
From: andrewrobertjones <not...@gi...> - 2016-05-03 12:40:55
|
My recollection is that a valid mzIdentML file SHOULD be accompanied by the spectra searched in an external file, but I don't actually see this line in the 1.1 or 1.2-draft specs. Should we add this line? If so, 1. all our example files should have the searched file alongside them 2. The validator should check that the file exists as referenced in the file. Even better would check that experimentalMassToCharge values match what is reported in the file, based on referencing system used. This would be tricky to implement beyond referencing MGF or mzML files, so arguable whether useful in practice --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/23 |
|
From: andrewrobertjones <not...@gi...> - 2016-05-03 11:37:00
|
@germa Can you add support for .mzid.gz directly in the validator. As gzip is the recommended compression for mzid, and we have compressed files in GitHub, it would be nice if we could validate without manually decompressing. thanks Andy --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/22 |
|
From: andrewrobertjones <not...@gi...> - 2016-05-03 11:26:26
|
@germa Apologies if I missed it somewhere - it's not obvious if there is a release of the validator available for developers. It would be good to post this on the front page of the mzIdentML GitHub, or at least have it available inside the Git repository. I'm struggling to locate it? thanks Andy --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/21 |
|
From: Mathias W. <not...@gi...> - 2016-05-02 16:15:41
|
schema version number had to be bumped up as non-minor change regarding the attachment handling requested at PSI meeting in Ghent --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/20#issuecomment-216280578 |
|
From: Mathias W. <not...@gi...> - 2016-05-02 16:14:05
|
Added first in-GitHub-online-documentation to the current schema folder You can view, comment on, or merge this pull request online at: https://github.com/HUPO-PSI/qcML-development/pull/22 -- Commit Summary -- * added images for schema visualisation * added readme.md for 0.0.9 schema * added README.md for the schema base folder. * trying to fix relative link images in markdown * fixed relative image path in markdown files -- File Changes -- A schema/README.md (4) A schema/v0_0_9/README.md (23) A schema/v0_0_9/images/qcML_0_0_9_QualityParameter.png (0) A schema/v0_0_9/images/qcML_0_0_9_RunQuality.png (0) A schema/v0_0_9/images/qcML_0_0_9_root.png (0) -- Patch Links -- https://github.com/HUPO-PSI/qcML-development/pull/22.patch https://github.com/HUPO-PSI/qcML-development/pull/22.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/qcML-development/pull/22 |
|
From: Mathias W. <not...@gi...> - 2016-04-30 10:10:39
|
thread is getting too long, will just reference related issues here: #13 #20 --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/2#issuecomment-215950987 |
|
From: Mathias W. <not...@gi...> - 2016-04-30 10:04:54
|
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/20 |
|
From: Mathias W. <not...@gi...> - 2016-04-30 10:02:28
|
definitely something the chem. experts should consider during their offline discussions on the linker definitions list, see https://github.com/HUPO-PSI/mzIdentML/blob/master/cv/XLMOD.csv --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/13#issuecomment-215950678 |
|
From: Mathias W. <not...@gi...> - 2016-04-30 09:56:07
|
Sure we could put 'free form' annotations in there, but the question is @enetz to what extent we would want to make these annotations machine readable for others (e.g. for visualising). _Are there common operations in manual annotation?_ I'd guess something along the lines of ```manual peak tagging``` or ```manual peak annotation``` and ```manual peak group tagging```. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/14#issuecomment-215950418 |
|
From: Eugen N. <not...@gi...> - 2016-04-30 09:46:12
|
Current state: As it is specified now, the two spectra are referenced as an unordered list of spectrum IDs in the SpectrumIdentificationResult. For some use cases it could be useful to know which of these is the light and which is the heavy spectrum, since they are not necessarily treated equally. Also the experimentalMassToCharge and chargeState from only one spectrum are written in SpectrumIdentificationItem and it is not specified from which, while it would actually be useful to have both. For cleavable cross-linkers it was agreed to use different values here for the two SpectrumIdentificationItems corresponding to the MS3 spectra each containing one peptide. Although the information is there, it is still unclear here, which spectrum ID in the list belongs to which SpectrumIdentificationItem, MassToCharge and chargeState, since one only has the IDs and the other only the other values. But I think MassToCharge and chargeState values for each spectrum ID should be in the file and somehow linked to their corresponding IDs. Proposals: Could we add CV terms to make that more clear? One easy thing to do would be to specify, that in the case of labelled cross-linkers there is a fixed order for the spectrumIDs, e.g. the first ID must be the unlabelled or light spectrum, or more generally the IDs should be in ascending order of label weight or MassToCharge. That would already add a crucial bit of information. Or we could add lists of MassToCharge and chargeState values, that must have the same order as the list of IDs. I would like to avoid specific CV terms for light and heavy spectra and come up with something general enough to cover labelled and cleavable cross-linkers. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/19 |
|
From: Harald B. <not...@gi...> - 2016-04-29 22:45:49
|
If I recreate the PeptideShaker mzid 1.2 example file but remove all the new 1.2 additions, i.e., creating an mzid 1.1 compatible file, the validator is not happy and gives the following errors:
Message 1:
Rule ID: ProteinDetectionProtocolThreshold_rule
Level: ERROR
Context(/threshold/cvParam/@accession ) in 2 locations
--> The result found at: /threshold/cvParam/@accession for which the values is ''MS:1002369'' didn't match any of the 4 specified CV terms:
- The sole term MS:1001447 (prot:FDR threshold) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
- The sole term MS:1001494 (no threshold) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
- Any children term of MS:1001153 (search engine specific score). The term can be repeated. The matching value has to be the identifier of the term, not its name.
- Any children term of MS:1001302 (search engine specific input parameter). The term can be repeated. The matching value has to be the identifier of the term, not its name.
Message 2:
Rule ID: SpectrumIdentificationProtocolThreshold_must_rule
Level: ERROR
Context(/threshold/cvParam/@accession ) in 2 locations
--> The result found at: /threshold/cvParam/@accession for which the values are ''MS:1001364', 'MS:1002350', 'MS:1002567', 'MS:1002557'' didn't match any of the 4 specified CV terms:
- The sole term MS:1001448 (pep:FDR threshold) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
- The sole term MS:1001494 (no threshold) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
- Any children term of MS:1001153 (search engine specific score). The term can be repeated. The matching value has to be the identifier of the term, not its name.
- Any children term of MS:1001302 (search engine specific input parameter). The term can be repeated. The matching value has to be the identifier of the term, not its name.
Both seem to be due to the validator not considering new currently supported threshold terms?
In the first message it says that "MS:1001447 (prot:FDR threshold) or any of its children" ought to be used. I think the correct term now is "MS:1002572 (protein detection statistical threshold) or any of its children"? As this covers the new "protein group-level statistical threshold" terms?
Similar for the second message: "MS:1001448 (pep:FDR threshold) or any of its children" ought to be changed into "MS:1002484 (peptide-level statistical threshold) or any of its children"?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/18 |
|
From: Harald B. <not...@gi...> - 2016-04-29 20:03:46
|
@andrewrobertjones @germa Quick update on the validation of the PeptideShaker mzid 1.2 example file. After Gerhard's recent fixes the file now validates without any errors and with a lot less INFO messages. The remaining messages mainly relate to additional CV terms that could be added but that are not mandatory. There are only three remaining questions, all set up as separate issues: - Allow search statistics children terms: https://github.com/HUPO-PSI/mzIdentML/issues/8 - Use of the DenovoSearchType_may_rule: https://github.com/HUPO-PSI/mzIdentML/issues/17 - How to annotate immonium ions: https://github.com/HUPO-PSI/mzIdentML/issues/9 And on a related note to the last point, what about reporter ions? See: https://github.com/HUPO-PSI/mzIdentML/issues/16. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/3#issuecomment-215865544 |
|
From: Harald B. <not...@gi...> - 2016-04-29 19:59:19
|
What is the purpose of the DenovoSearchType_may_rule? I get the following for the PeptideShaker mzid 1.2 example file:
Rule ID: DenovoSearchType_may_rule
Level: INFO
Context(/additionalSearchParams/cvParam/@accession ) in 2 locations
--> Not all of the 6 values ParamList's CV terms ['MS:1001211', 'MS:1001256', 'MS:1002492', 'MS:1002490', 'MS:1002497', 'MS:1002491'] found using the Xpath '/additionalSearchParams/cvParam/@accession' matched any of the 1 CvTerm(s):
- The sole term MS:1001010 (de novo search) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
But this is not a de novo search. Shouldn't this rule only be triggered for mzid files that appear to be de novo searches?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/17 |
|
From: Harald B. <not...@gi...> - 2016-04-29 19:52:06
|
Related to https://github.com/HUPO-PSI/mzIdentML/issues/9, are there any of examples of how reporter ions from, for example, iTRAQ and TMT are to be annotated as part of the Fragmentation section? I could not find the required CV terms? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/16 |
|
From: Harald B. <not...@gi...> - 2016-04-29 19:38:02
|
Seems like the ProteinDetectionList_rule does not allow children of MS:1001184 (search statistics) only children of MS:1002406 (count of identified clusters)? Shouldn't children of MS:1001184 (search statistics) also be allowed?
Complete validator message:
```
Rule ID: ProteinDetectionList_rule
Level: INFO
Context(/cvParam/@accession ) in 2 locations
--> Not all of the 1 values ProteinDetectionList's CV terms ['MS:1002404'] found using the Xpath '/cvParam/@accession' matched any of the 2 CvTerm(s):
- Any children term of MS:1001184 (search statistics). The term can be repeated. The matching value has to be the identifier of the term, not its name.
- The sole term MS:1002406 (count of identified clusters) or any of its children. A single instance of this term can be specified. The matching value has to be the identifier of the term, not its name.
```
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/HUPO-PSI/mzIdentML/issues/8#issuecomment-215857440 |
|
From: Harald B. <not...@gi...> - 2016-04-29 19:37:22
|
Reopened #8. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/issues/8#event-646126620 |
|
From: stefanks <not...@gi...> - 2016-04-29 15:15:18
|
Closed #15. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15#event-645724058 |
|
From: stefanks <not...@gi...> - 2016-04-29 15:15:18
|
Yeah, I agree that it's not a good idea to change the schema to fix downstream bugs. I just wish standard tools were working without any hacks... --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15#issuecomment-215749987 |
|
From: andrewrobertjones <not...@gi...> - 2016-04-29 15:07:51
|
It appears that you would like to add an attribute "tmp" to one of the elements, to fix a downstream bug in a piece of Microsoft software? The addition of the attribute wouldn't be harmless, since people could put data in the attribute - or do I misunderstand? We wouldn't normally change the standard to fix downstream bugs in software --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15#issuecomment-215747290 |
|
From: stefanks <not...@gi...> - 2016-04-29 15:00:21
|
I'm trying to automatically generate a usable class to use in C# on windows. Usually it works by running the command xsd.exe theSchema.xsd /classes in the visual studio developer console. Because of a bug in xsd.exe, it generates a class with a double array instead of a single array anytime it encounters maxOccurs="unbounded" in the xsd schema. Since microsoft has not fixed the error, adding this harmless line streamlines the workflow for anyone trying to automatically generate a class from the schema. Does it break any use/test cases? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15#issuecomment-215745359 |
|
From: andrewrobertjones <not...@gi...> - 2016-04-29 14:51:26
|
Hi @stefanks can you give me the plain English description of the issue and solution? Thanks Andy --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15#issuecomment-215742630 |
|
From: stefanks <not...@gi...> - 2016-04-29 14:40:32
|
This error and solution: http://stackoverflow.com/questions/6678934/unable-to-generate-a-temporary-class-result-1-error-cs0030-cannot-convert-ty https://developer.salesforce.com/forums/?id=906F0000000AiPEIA0 http://stackoverflow.com/questions/5595779/xmlserializer-invalidoperationexc-known-issue-converting-types You can view, comment on, or merge this pull request online at: https://github.com/HUPO-PSI/mzIdentML/pull/15 -- Commit Summary -- * Fix error that occurs during cs class generation -- File Changes -- M schema/mzIdentML1.2.0-candidate.xsd (3) -- Patch Links -- https://github.com/HUPO-PSI/mzIdentML/pull/15.patch https://github.com/HUPO-PSI/mzIdentML/pull/15.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/HUPO-PSI/mzIdentML/pull/15 |
42 messages has been excluded from this view by a project administrator.
