psidev-ms-dev — Mass spectroscopy standard development

[Psidev-ms-dev] dta2mzData converter

[Patricia H. <pat...@is...>]

Hi all,
I'm looking for a free dta2mzData converter, but I can't find one 
(although I found several mzData2dta/mgf converters).
Does anybody knows such a tool? (dta/mgf2mzData or dta/mgf2mzXML)
Thanks,

-- 
Patricia Hernandez, Ph.D.
Swiss Institute of Bioinformatics (SIB)
Proteome Informatics Group (PIG)
CMU-rue Michel-Servet 1
1206 Geneva
Switzwerland

[Psidev-ms-dev] IEEE CBMS 2006 Special Track on Computational Proteomics

[Cannataro_Mario <can...@un...>]

IEEE Symposium on Computer-Based Medical Systems (IEEE CBMS 2006)
Marriott Salt Lake City =96 City Center,
Salt Lake City, Utah, USA, June 22-23, 2006.

Special Track
Computational Proteomics: Management and Analysis of Proteomics Data

Special Track Website: http://bioinformatics.unicz.it/cbms2006/


CALL FOR PAPERS
Proteomics is a fastly developing area of biochemical investigation. The =
basic
aim of proteomic analysis is the identification of specific protein patte=
rns
from cells, tissues and biological fluids related to physiological or
pathological conditions. It provides a different view as compared to gene
expression profiling, which does not evaluate post-transcriptional,
post-translational modifications as well as protein compartimentalization=
 and
half-life changes (for instance ubiquitination and proteasome-driven
degradation). All these characteristics make the protein profile much mor=
e
complex but more informative compared to gene expression profiling.

Several approaches have been used to perform proteomic analysis; among th=
em,
technologies based on Mass Spectrometry (MS) have revolutionized proteomi=
cs and
are heavily used to make high-throughput measurements for identifying
macromolecules in a specific compound. Recently, Liotta=92s group at the =
National
Institutes of Health, USA, using SELDI-TOF mass spectrometry, has identif=
ied in
the serum of patients with ovarian cancer a cluster pattern that complete=
ly
segregated cancer from non-cancer. These results, characterized by a high
degree of sensitivity and specificity, represent an extraordinary step fo=
rward
in the early detection and diagnosis of ovarian cancer and justify a
prospective population-based assessment of proteomic pattern technology a=
s a
screening tool for all stages of ovarian cancer in high-risk and general
populations. Similar studies performed on different types of neoplastic
diseases have confirmed the importance of identification of =93molecular =
profiles
or!signatures=94 (either at RNA or protein level) as a powerful tool for =
innovative
diagnostic and therapeutic approaches.

This Special Track is designed to bring together computer scientists, bio=
logists
and clinicians for exploring the current state-of-the-art research taking=
 place
in all aspects of computational proteomics, from basic science to clinica=
l
practice. The track intends to provide a forum for the presentation of or=
iginal
research, valuable software tools (basic algorithms, modelling, analysis,=
 and
visualization tools, databases), and clinical fallouts, on topics of impo=
rtance
to computational proteomics, with special emphasis on MS-based approaches.

Matrix-Assisted Laser Desorption/Ionisation Time Of Flight (MALDI-TOF),
Surface-Enhanced Laser Desorption/Ionization Time Of Flight (SELDI-TOF), =
and
Liquid Chromatography (LC-MS/MS) are the main techniques. They separate g=
as
phase ions according to their m/Z (mass to charge ratio) values producing=
 huge
volumes of data. MS output is represented, as a (large) sequence of value
pairs, containing a measured intensity, which depends on the quantity of =
the
detected biomolecules and a mass to charge ratio m/Z, which depends on th=
e
molecular mass of detected biomolecules. A MS experiment usually generate=
s one
or more datasets, said spectra, that contains a huge quantity of measurem=
ents
(m/Z, intensity) said peaks.

MS-based proteomics requires bioinformatics methods that can make biologi=
cal
inferences from both the raw experimental data sources (e.g., peptide
identifications and mass measurements) and the resulting identifications.
Prior to be analysed, spectra need to be cleaned, pre-processed, organize=
d, and
stored in an efficient way. Moreover, standard formats enabling laborator=
y
interoperation and experiment replication are needed. The Human Proteome
Organization-Proteomic Standard Initiative (HUPO-PSI) is defining novel
standards for proteomics data and experiments such as mzData to store spe=
ctra
data as well as metadata information about proteomics experiments, and mz=
Ident
capturing parameters and results of search engines such as Mascot and Seq=
uest.
On the other hand, alone or in combination with MS, fluorescence-based
techniques are also used for proteomics analysis. Differential display
proteomics increases the information content and throughput of proteomics
studies through multiplexed analysis. Main approaches to differential dis=
play
proteomics such as Difference Gel Electrophoresis (DIGE), Multiplexed
Proteomics (MP), and Isotope-Coded Affinity Tagging (ICAT), greatly enhan=
ce the
applicability of the Two-Dimensional Gel Electrophoresis technique (2D-Ge=
l).
Representation, organization and analysis of fluorescence-based proteomic=
s data,
such as 2D-Gel data, are also important topics.

Genomic and Proteomic data need to be analyzed in combination. The full
realization of the concept of =93genomic medicine=94, where genomics and =
proteomics
are used to improve healthcare, requires the integration of knowledge fro=
m
biology and medicine. To exploit the data available in research centres a=
nd
care facilities new frameworks integrating data, computational methods an=
d
tools have to be provided, that bridge bioinformatics, biology and medici=
ne.
The semantic integration and further analysis of genomic, proteomics and
clinical data is a first step toward the deployment of novel biomedical
applications involving research-oriented competence centres, specialized
proteomics facilities, and health centres where clinical guidelines are
applied.

Key issues to be faced when considering integrated management and analysi=
s of MS
proteomics data are:
* spectra data models and databases;
* spectra pre-processing;
* spectra analysis (e.g. peptide identification, protein identification, =
etc.);
* spectra visualization;
* integration and interaction with biological data banks (e.g. sequence,
structure, and peptide data banks);
* data models and databases for integrated genomics and proteomics data;
* integrated analysis of genomic and proteomic data with clinical/instrum=
ental
findings;
* identification of new biomarkers for early diagnosis and tailored
therapeutics;


TOPICS OF INTEREST
Methods, algorithms and techniques for proteomics data organization, stor=
age and
analysis, as well as the use of proteomics methods and techniques in clin=
ical
practice are the key topics of this Special Track. Whatever technique bei=
ng
used, proteomics data are huge, involve heterogeneous platforms and requi=
re
high performance computing, so presentation of high performance and Grid-=
based
computational methods, as well as semantic-rich methods for in silico wor=
kflow
composition are welcomed. Examples of areas of interest include, but are =
not
restricted to:

* Spectra data models and databases
* Spectra-related data banks (e.g. Mascot, Sequest)
* Spectra pre-processing algorithms
* Peptide/protein identification
* Protein-protein interactions
* Data Mining techniques for proteomics data
* Statistical analysis of proteomics data
* Image analysis and visualization of proteomics data
* 2-D Gel proteomics data and analysis
* Virtual Proteomics Laboratory
* Data integration and proteomics
* Technologies and models to store phenotype, genotype and proteotype dat=
a;
* Integration of proteomics and clinical data for diagnosis and treatment
* Application of proteomics methods in clinical practice
* Workflow of proteomics experiments
* Knowledge Management and ontologies in proteomics
* Parallel and Grid-based computational proteomics
* Standards in proteomics


IMPORTANT DATES:
January 31, 2006		Deadline for paper submissions
March 1, 2006		Notification of acceptance
April 5, 2006		Final camera-ready paper (6 pages, maximum) due
April 8, 2006		Pre-registration deadline
May 22, 2006		Hotel room reservations due
June 22-23, 2006		Conference


PAPER SUBMISSION
Unlike workshops, where position papers and reports on initial and intend=
ed work
are appropriate, papers selected for a special track should report on
significant unpublished work suitable for publication as a conference pap=
er.
Interested authors should submit a 3-6 pages manuscript (or approximately
1500-3000 words) clearly describing background, goals, methods, results a=
nd a
listing of primary references. Presented material should include sufficie=
nt
detail to enable the program committee in reviewing the article.

The article should be composed on US Letter page format and submitted as =
a PDF
or Microsoft Word document. The article review is double blind and as suc=
h
personally identifying information is discouraged. Author name and addres=
s
should be withheld from the article text for review purposes.
Article text should be in font size of at least 10 point. Authors should
indicate the Special Track title in their submissions. All submissions
including special track papers will be done electronically via the CBMS w=
eb
submission system, which will be open approximately one month before the
deadline.
Please note that the format of IEEE CBMS 2006 proceedings will be the IEE=
E
Computer Science Press 8.5x11-inch format, available at:
ftp://pubftp.computer.org/press/outgoing/proceedings/8.5x11%20-%20Formatt=
ing
%20files
For more details please see the website of IEEE CBMS 2006:
http://cbms2006.ece.byu.edu/how.html#submission


TRACK CHAIRS
* Mario Cannataro		(University =93Magna Gr=E6cia=94 of Catanzaro,
Italy)
* Giovanni Cuda		(University =93Magna Gr=E6cia=94 of Catanzaro, Italy)
* Pierangelo Veltri	(University =93Magna Gr=E6cia=94 of Catanzaro, Italy)


PROGRAM COMMITTEE (provisional)
* Alberto Apostolico 	(Georgia Institute of Technology, USA, and
University of Padova, Italy)
* Gerard Cagney 		(Conway Institute, University College
Dublin, Ireland)
* Tim Clark 		(Harvard Medical School -  MassGeneral Institute for
Neurodegenerative Disease, USA)
* David De Roure 		(University of Southampton, UK)
* Giuseppe Di Fatta 	(ICAR-CNR, Italy, and University of Konstanz,
Germany)
* Marco Gaspari 		(University =93Magna Gr=E6cia=94 of Catanzaro,
Italy)
* Carole Goble 		(University of Manchester, UK)
* Concettina Guerra 	(University of Padova, Italy)
* Des Higgins 		(Conway Institute, University College Dublin,
Ireland)
* Hasan Jamil     	(Wayne State University, Michigan, USA)
* Maria Mirto		(University of Lecce, Italy)
* Giovanni Morrone 	(University =93Magna Gr=E6cia=94 of Catanzaro, Italy)
* Luigi Palopoli 		(University of Calabria, Italy)
* Helen Parkinson 	(European Bioinformatics Institute, UK)
* Stephen Pennington 	(Conway Institute, University College Dublin,
Ireland)
* Emmanuel F. Petricoin (National Cancer Institute, USA)
* Omer F. Rana 		(Cardiff University, UK)
* Roberto Tagliaferri 	(University of Salerno, Italy)
* Domenico Talia 		(University of Calabria, Italy)
* Chris Taylor 		(European Bioinformatics Institute, UK)
* Rosa Terracciano 	(University =93Magna Gr=E6cia=94 of Catanzaro, Italy)
* Gordon R. Whiteley 	(National Cancer Institute, USA)




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Psidev-ms-dev] MzData comments

[Fredrik L. <Fre...@el...>]

Working on implementation of mzData and mzAnalysis in the Proteios database 
project (www.proteios.org) I came up with some questions on mzData which 
some of you may be interested in and have comments on. As I got some 
excellent answers from Randall Julian these are posted too, along with some 
new comments (maybe a bit messy):

At 14:04 2005-12-16, Randy Julian wrote:
>Fredrik,
>
>Thanks for your note - I have some comments mixed in below:
>
>
>Fredrik Levander wrote:
>
>>
>>We are a little bit confused on how to use mzData 1.05 when a peak list 
>>is processed multiple times with different software. We do peak 
>>extraction of MALDI spectra with one software module and then filtering 
>>and recalibration with another. The question is how to handle this with 
>>mzData. One approach would be to generate one mzData for the first step 
>>and another for the second step. This way the 
>>description.admin.sourceFile for the second mzData could be the first 
>>mzData and the 'software' element in each is the software that was used 
>>in that processing step. This should be ok. However, if we do not keep 
>>the intermediate peak lists there should be multiple 
>>description.dataProcessing elements which is not allowed in the mzData. I 
>>therefore suggest that multiple dataProcessing elements should be 
>>allowed, or is there any other solution on how to treat this?
>I will look at the idea of making the dataProcessing elements unbounded, 
>but the way we imagined doing what you are suggesting is to use the 
>supplemental data section.  Depending on what you want to be considered 
>the primary spectrum, you can store one spectrum in the mz/Inten vectors, 
>and all other spectra as supplemental data.  The description of how the 
>supplemental data were created is supposed to be handled by the 
>supplemental data description.  This part has not been tested that much 
>and the original use case was for storing time-domain or frequency-domain 
>data which were used to compute a mass spectrum.  I would like to work 
>with you on this so that if there is some problem with your use case we 
>can correct mzData for the 1.1 release.
Storing intermediate spectra as supplemental data should work fine. 
However, I would guess that most search engines and other software would 
only handle the peak lists that come in the intenArrayBinary and 
mzArrayBinary elements. If one would like to use peak lists that are in the 
supplementary data section this may be less straightforward.
Making 'dataProcessing' unbounded would still be useful for the use case 
when several software modules are used in a pipe without any need for 
storing intermediate data. It is still of interest to store all the 
parameters from the different modules, and I think that the dataProcessing 
section would be the most logical place.


>>I have had a look at the mzData 1.10 draft and I do not think I get how 
>>the chromatogram info is going to be used. As I see it the mzData could 
>>either contain raw data, in which case chromatogram data do not have to 
>>be there since it is contained in the spectra, or peak lists. If the data 
>>is peak lists, every 'spectrum' is actually a peak list which may have 
>>been generated from the summing of neighboring spectra, maybe in 
>>combination with peak extraction. In this case chromatographic 
>>information for that specific peak list, or rather for individual peaks 
>>could be intersting to keep for quantitation purposes. However, then the 
>>chromatogram info should belong to individual spectrum elements, and not 
>>to the entire mzData as is currently suggested. As it is now the 
>>chromatogramList is placed in the top of the structure, I therefore 
>>wonder what it is supposed to contain? Is it for intensity traces of 
>>individual masses over an entire LC-MS run?
>The chromatogram element was intended to answer two use cases: 1) single- 
>and multiple-reaction-monitoring experiments in which the output from the 
>instrument is more rightly considered single channel than spectral; 2) 
>convenience for those who wanted to store TIC, BP or Extracted-Ion 
>chromatograms (the case you mentioned).
>
>The TIC, BP and XIC can always be computed, so we left it out of 1.05, but 
>the MRM experiments now being developed for targeted proteomics are a 
>problem for 1.05.  In principle, you could store a single mz value and a 
>single intensity for thousands of 'spectra', but this is a waste compared 
>to storing them as a chromatogram.



>>The mzData accessionNumber: has it been dropped? I actually liked it as 
>>it was a quick way of identifying mzData files. Of course the sampleName 
>>could be used as an identifier, but it was nice to have it as a top level 
>>attribute, and accession Number sounds more like an ID than sampleName. I 
>>guess no one else wanted to keep that attribute?
>No, we should still have an accession number, but it may have been 
>accidentally dropped while editing - I will check on this.
I just didn't find it in the documentation, but I can see now that it is 
still in the schemas, sorry. Anyway, how about making this identifier 
really unique by specifying a URI-type format or similar. When people start 
to make their mzData files publicly available it would be great if the 
files could be identified unambiguously.



>>A last comment is that the models contains many nodes and one-to-one 
>>relations which could be 'flattened'. For example. The 'software' element 
>>could be put directly into the dataProcessing element or even in the 
>>description container. I think this would make processing of the files 
>>easier and the schemas could be used straight off as database models with 
>>good performance. However, I guess it is more important that the xml 
>>files are easy to read by eye, so I'm not that sure.
>There are some legacy ideas still captured in the schema which should 
>eventually be worked out, in this area the most important idea is to 
>maintain stability unless some change adds exceptional value.  There are 
>some very "relational" things in this schema which are either easy or hard 
>depending on your perspective.  The idea that we use references to allow 
>spectra to point to parent spectra and to experimental descriptions seems 
>hard to deal with in straight XML, but maps well onto relational tables 
>and models.  Originally, the idea was to design a schema which, when fed 
>into an XML binding API (like JAXB, or Castor) would produce reasonable 
>classes.  In some instances, this is true, in others, it's not true - the 
>output from the JAXB schema compiler is a bit hard to read.
>
>Right now, refactoring ideas are centering on how to merge mzData with 
>mzXML to get a single data representation specification.  The main 
>difference appears to be in the method of extension: the use of controlled 
>vocabularies compared to fixed schema elements.  The plan is to have 1.1 
>come out with a formal specification and remain stable through most of 
>2006 while the PSI team works with the ISB and mzXML developers to propose 
>a merger for public review in the summer/fall 2006 and adoption via vote 
>by the PSI, but likely to be targeted to the 2007 Spring PSI meeting.


Fredrik Levander

Dept of Protein Technology
Lund University
Sweden

Re: [Psidev-ms-dev] Clarification on mzData specification

[simon a. (B. <sim...@bb...>]

On 15 Dec 2005, at 16:55, Randy Julian wrote:

> Based on some recent conversations on the list (and some experience 
> helping others develop mzData readers and writers), I suspect we need 
> better definition of the base64 arrays.  The last comment was:
>
>> ... The error is similar in each case - for example:
>>   Byte data array had length 56 which isn't a multiple of 8

I should point out that this error had nothing at all to do with the 
specification (56 is of course a multiple of 8!), just my inability to 
type :-)

Having spent the last few days working through a load of example mzData 
files I thought I'd share a few observations about things I found in 
some files which caused problems in our application and which may 
pre-warn others trying to work with the format.

1) Some spectra which are part of a series do not have a time value 
associated with them (or any other value which would indicate their 
order).

2) Spectra within a time series do not always appear in time order in 
the mzData file

3) A single mzData file can contain more than one series at the same ms 
level (eg zoom scans).  There isn't a nice way within the mzData format 
to distinguish these series.  We ended up just combining them into a 
single series, but this looks rather odd (you get a sawtooth pattern in 
the chromoatogram).

4) Some spectra denoted as continuous do not provide their data in the 
order of increasing m/z values.  This just seems wrong (although it's 
not against the spec), and we treat these as discontinuous spectra and 
throw up a warning.

5) Some spectra marked as having 64 bit precision actually only contain 
32 bit precision data padded with zeros.  Although not strictly 
incorrect, this is a bit naughty.

6) Some files have more than one spectrum, but only ever have one file 
per msLevel.  This isn't in any way an error, but it caught us out when 
trying to draw chromatograms!


Simon.

-- 
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

[Psidev-ms-dev] mvData Viewer

[simon a. (B. <sim...@bb...>]

Many thanks to those who responded to my post here last week about our 
mzData viewer.  I've now received a number of extra example files from 
different sources which have enabled much more rigourous testing of our 
tool.

I've put out an updated version of the viewer (v0.4) which addresses 
many of the issues people reported previously.  Anyone who had problems 
with the last version should give this one a try as it's much more 
likely to work now.

You can get the viewer from

http://www.bioinformatics.bbsrc.ac.uk/projects/mzviewer/

Cheers

Simon.
-- 
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

[Psidev-ms-dev] Clarification on mzData specification

[Randy J. <rkj...@in...>]

Based on some recent conversations on the list (and some experience 
helping others develop mzData readers and writers), I suspect we need 
better definition of the base64 arrays.  The last comment was:

> ... The error is similar in each case - for example:
>   Byte data array had length 56 which isn't a multiple of 8
>
The documentation being added to the specification is pretty meager:

spectrumType/mzArrayBinary:
The list of m/z values (for any type of spectrum). The array is stored 
as a base64 encoded binary.The only type allowed is IEEE-754 floating 
point; the precision must be specified as either 32- or 64-bit; 
endianess must also be specified.

The data element (given as a binaryDataGroup) has the attributes:

precision    xs:string    required   
endian       xs:string    required   
length        xs:int        required   

But we don't give a good description of how the data are to be loaded 
into the array.  All of the working implementations are using an 
unpadded binary array which is converted in its entirety to the base64 
string in conformance with: http://www.ietf.org/rfc/rfc3548.txt

In the latest version of the specification document, I have included Kai 
Runte's original base64 utility class implemented in Java as an example 
(Section 4).  Take a look at the developing specification document to 
see how to make the data storage part easier to understand:

http://psidev.sourceforge.net/docstore/view.php?sess=0&parent=7&expand=1&id=35&action=file_details

Thanks,
Randy

Re: [Psidev-ms-dev] mzData issues

[simon a. (B. <sim...@bb...>]

On 15 Dec 2005, at 13:41, Chris Taylor wrote:

> Hiya. The viewer looks nice -- I got it to work with one of the 
> example files (myo_full) and it is clean and simple. No need to RTFM  
> :)

Probably a good job as there isn't a FM yet :)

Actually a couple of reports have suggested that it has problems with 
other mzdata files (it was written using the examples off psidev as we 
use an ABI machine and don't have an official mzData converter yet).  
It would be really useful to get some more examples on the psidev 
examples page from the major instrument manufacturers to help with 
developing mzData tools.


> On PIMS, I saw this first on a poster at BSPR and meant to follow up 
> on a particular issue; are you aware of the FuGE project 
> (fuge.sf.net)? The model will soon be at milestone 2 (hopefully all of 
> the issues sorted, and all the required functionality in).

You mentioned it when we spoke at BSPR.  I have looked at it but 
haven't gone any further in implementing it in PIMS.  The scope of Fuge 
seems to be somewhat larger than what we had intended for PIMS.  PIMS 
is really a glorified sample tracking system which also stores data.  
It does model the experimental process, but in a very simple way.  I'm 
eventually aiming to extend it to store the analysis of MS data as well 
(mzIdent and the like), but trying to strictly model the whole workflow 
would make it more complex than we would either need or want.


> Another thing would be the (very new) FuGO project (ontology). This 
> project needs contributors and in that respect I'm wondering how much 
> of a controlled vocabulary you've accumulated in developing PIMS?

We've incorporated existing ontologies wherever we can (eg Brenda for 
tissues, EBI taxonomy and the appropriate limits from the psidev 
ontology), but haven't developed our own.  FuGO sounds interesting - 
I'm happy to extend our ontology support with whatever comes out of it 
though I don't know how useful I'd be at contributing to the actual 
ontology construction.


> P.S. Where do you put stuff collected through PIMS -- do you have a 
> bespoke repository? Is that public? Is it anything like this: 
> http://www.ebi.ac.uk/pride/ ?

There isn't a central repository - you can download the PIMS server 
from our site and create your own.  I'm aiming to eventually allow 
automated export from PIMS into pride (I think we already collect all 
of the necessary information in a suitable form), but that's still on 
the to-do list.  Our schema is included as part of the PIMS server 
download.

TTFN

Simon.
-- 
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

Re: [Psidev-ms-dev] mzData issues

[Chris T. <chr...@eb...>]

Hiya. The viewer looks nice -- I got it to work with one of the 
example files (myo_full) and it is clean and simple. No need to 
RTFM  :)

On PIMS, I saw this first on a poster at BSPR and meant to 
follow up on a particular issue; are you aware of the FuGE 
project (fuge.sf.net)? The model will soon be at milestone 2 
(hopefully all of the issues sorted, and all the required 
functionality in). At least one other free LIMS-like system is 
implementing FuGE already (CPAS from the Fred Hutch CRC in 
Seattle) and maybe even a commercial firm I know of might switch 
to it once it is properly stable. I wonder if you have the 
person hours at your disposal to make PIMS able to im/export in 
FuGE? A big job, and maybe a bit over the top if you are seeking 
only to support your immediate user base but it would be cool 
(sharing/repositing workflows, third party tool accessibility etc.).

Another thing would be the (very new) FuGO project (ontology). 
This project needs contributors and in that respect I'm 
wondering how much of a controlled vocabulary you've accumulated 
in developing PIMS?

Cheers, Chris.

P.S. Where do you put stuff collected through PIMS -- do you 
have a bespoke repository? Is that public? Is it anything like 
this: http://www.ebi.ac.uk/pride/ ?


simon andrews (BI) wrote:
> On 30 Nov 2005, at 03:47, Randy Julian wrote:
> 
>> If everyone who has a working mzData tool will drop a line to this 
>> mailing list, I will make sure the tools section gets updated.
> 
> 
> After an age of waiting for official permission to release our code I've 
> put a couple of tools which make use of mzData up onto our website.
> 
> mzViewer is a simple viewer for mzData files.  It also provides an API 
> to embed an mzData viewer into your own java applications.
> 
> PIMS is a larger LIMS application for proteomics which keeps track of 
> samples, protocols and MS data.
> 
> Both can be downloaded from our projects page:
> 
> http://www.bioinformatics.bbsrc.ac.uk/projects/
> 
> Both tools are pretty new so we'd appreciate bug reports if anyone has 
> problems with either of them.
> 
> Simon.
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://psidev.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] mzData issues

[simon a. (B. <sim...@bb...>]

On 15 Dec 2005, at 12:02, David Creasy wrote:

> Hi Simon,
> Looks useful, but unfortunately fails to open files exported from data 
> systems from Thermo, Sciex and Waters. The error is similar in each 
> case - for example:
>   Byte data array had length 56 which isn't a multiple of 8

I was kind of expecting this.  The parsers were written off the example 
mzData files at the psidev site.  I'm sure that other implementations 
will bring out subtle bugs.


> Hopefully somebody from one of these manufacturers will be able to 
> send you an example file.

I'd appreciate that.  Bugs can be sent to me, or filed at:

http://www.bioinformatics.bbsrc.ac.uk/bugzilla/

Cheers

Simon.
-- 
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

Re: [Psidev-ms-dev] mzData issues

[David C. <dc...@ma...>]

Hi Simon,
Looks useful, but unfortunately fails to open files exported from data 
systems from Thermo, Sciex and Waters. The error is similar in each case 
- for example:
   Byte data array had length 56 which isn't a multiple of 8

Hopefully somebody from one of these manufacturers will be able to send 
you an example file.

David

simon andrews (BI) wrote:
> On 30 Nov 2005, at 03:47, Randy Julian wrote:
> 
>> If everyone who has a working mzData tool will drop a line to this 
>> mailing list, I will make sure the tools section gets updated.
> 
> 
> After an age of waiting for official permission to release our code I've 
> put a couple of tools which make use of mzData up onto our website.
> 
> mzViewer is a simple viewer for mzData files.  It also provides an API 
> to embed an mzData viewer into your own java applications.
> 
> PIMS is a larger LIMS application for proteomics which keeps track of 
> samples, protocols and MS data.
> 
> Both can be downloaded from our projects page:
> 
> http://www.bioinformatics.bbsrc.ac.uk/projects/
> 
> Both tools are pretty new so we'd appreciate bug reports if anyone has 
> problems with either of them.
> 
> Simon.
> 

-- 
David Creasy
Matrix Science
8 Wyndham Place
London W1H 1PP
Tel +44 (0)20 7723 2142
Fax +44 (0)20 7725 9360

dc...@ma...
http://www.matrixscience.com


Re: [Psidev-ms-dev] mzData issues

[simon a. (B. <sim...@bb...>]

On 30 Nov 2005, at 03:47, Randy Julian wrote:

> If everyone who has a working mzData tool will drop a line to this 
> mailing list, I will make sure the tools section gets updated.

After an age of waiting for official permission to release our code 
I've put a couple of tools which make use of mzData up onto our 
website.

mzViewer is a simple viewer for mzData files.  It also provides an API 
to embed an mzData viewer into your own java applications.

PIMS is a larger LIMS application for proteomics which keeps track of 
samples, protocols and MS data.

Both can be downloaded from our projects page:

http://www.bioinformatics.bbsrc.ac.uk/projects/

Both tools are pretty new so we'd appreciate bug reports if anyone has 
problems with either of them.

Simon.

-- 
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

Re: [Psidev-ms-dev] Today's Call

[Pierre-Alain B. <pie...@is...>]

Dear Randy, Kent,

is there anoother date been schedule for the next call?

Pierre-Alain

Randy Julian wrote:

> Late update:
>
> The PSI-MS teleconference is scheduled for 16:00 GMT.  Regular phone 
> number (contact Kent Laursen <ken...@ge...>) if you 
> need the number.
>
> David Creasy pointed me here (thanks!):
>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=12&year=2005&hour=16&min=0&sec=0&p1=0 
>
>
> I have a student completing the first draft of the actual written 
> specification for mzData and the first 10 pages are available to review:
>
> http://psidev.sourceforge.net/docstore/browse.php?sess=0&parent=7&expand=1 
>
>
> Today I would like to cover the following:
>
> 1. Discussion on overall mzData plan for 2006
> 2. Documentation for mzData
> 3. analysisXML plan (schema and docs)
> 4. Update on management and process
> 5. Update on MCP
> 6. Schedule/Agenda for next few calls
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> 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

[Psidev-ms-dev] Today's Call

[Randy J. <rkj...@in...>]

Late update:

The PSI-MS teleconference is scheduled for 16:00 GMT.  Regular phone 
number (contact Kent Laursen <ken...@ge...>) if you need 
the number.

 David Creasy pointed me here (thanks!):

http://www.timeanddate.com/worldclock/fixedtime.html?day=6&month=12&year=2005&hour=16&min=0&sec=0&p1=0

I have a student completing the first draft of the actual written 
specification for mzData and the first 10 pages are available to review:

http://psidev.sourceforge.net/docstore/browse.php?sess=0&parent=7&expand=1

Today I would like to cover the following:

1. Discussion on overall mzData plan for 2006
2. Documentation for mzData
3. analysisXML plan (schema and docs)
4. Update on management and process
5. Update on MCP
6. Schedule/Agenda for next few calls

Re: [Psidev-ms-dev] mzData issues

[Alexandre M. <ale...@ge...>]

Hi,

You may also have a look to the nearly release web tool
http://insilicospectro.vital-it.ch/cgi/cgiConvertSpectra.pl

regards
Alex

Jimmy Eng wrote:

> Andy,
>
> One nice peak list data conversion tool which is capable of taking
> peak lists in various ASCII formats (Mascot generic format, PKL, DTA,
> etc.) and outputting to mzData is the Peak List Conversion Utility
> available at the Proteome Commons website
>
>    http://www.proteomecommons.org/tools.jsp#File%20Format%20Manipulation
>
> It's an easy to use Java Web Start app that might suit your needs.
>
> - Jimmy

>
>     Andy Jones wrote:
>
>     > Hi,
>     >
>     > I'm trying to convert data from various different instruments into
>     > mzData and I have a few questions.
>     >
>     >    1. One of the instruments produces plain text output for the peak
>     >       list (peak [tab] intensity). Does anyone have a script or some
>     >       code for turning this into the mzData base 64 binary.
>     Otherwise,
>     >       any advice for how best to do this would be welcome.
>     >   
>
>


-- 
Alexandre Masselot, phD
Senior bioinformatician
www.genebio.com
voice: +41 22 702 99 00

Re: [Psidev-ms-dev] analysisXML/mzIdent & quantitation

[Randy J. <rkj...@in...>]

Jennifer,

As Chris indicated, analysisXML has been designed for storing 
quantitation results.  Both chromatographic (label-free) and 
spectrometric (labeled) quantitation where considered along with the 
'protein/peptide identification' use case.  There are two sub-schema in 
the current draft which address quantitation: quant_method.xsd and 
quant_result.xsd.  These are currently implemented as controlled 
vocabulary schema.  We need to create a proper vocabulary for 
quantitation to use these schema.  Alternatively they can be used as 
examples for creating more specific sub-schema for representing 
quantitation results using explicitly named parameters as elements 
rather than simply using a CV.  The goal is to have a standard HUPO 
quantitation schema developed with the participation and review of the 
entire PSI.

If you have ideas about alternatives to a simple flat CV for they type 
of quantitation results you have, let me know and we can develop some 
prototype sub-schema to test.

Thanks,
Randy


Chris Taylor wrote:

> Hi Jen. Just a quick response before all the Americans wake up :)
>
> Basically analysisXML has this structure that allows a number of 
> (sub)schema 'modules' to be plugged into a 'core' bit. This means that 
> in one incarnation it is a model of peptide/protein identification, 
> with a description of data source, engine and parameters in one bit, 
> the reults in the next one and finally the 'knowledge' in the third.
>
> For quantitation, there will be a similar set of modules (to cut to 
> the chase, they aren't there yet except as stubs afaik). Basically 
> these too may split three ways (although it isn't immediately clear to 
> me what will be in the third bit, possibly nothing). Number one would 
> be a 'how did I measure intensities and with what data' bit; number 
> two being the 'here's the actual measured amounts after scaling, 
> normalising, taking ratios etc.
>
> As I say though, it isn't there yet afaik. And I stand to be corrected 
> once this post has been seen by those more fully in the know than I.
>
> Cheers, Chris.
>
>
> Jennifer Siepen wrote:
>
>> Hi,
>>
>> I am new to the list and have a query about analysisXML/mzIdent. Here 
>> at Manchester we have a number of groups carrying out studies with 
>> quantitation in proteomics. My query is how does analysisXML/mzIdent 
>> cope with quantitation, and are relative and absolute quantitation 
>> both catered for?
>>
>> Many thanks for any help/information,
>>
>> Jennifer
>>
>

Re: [Psidev-ms-dev] analysisXML/mzIdent & quantitation

[Chris T. <chr...@eb...>]

Hi Jen. Just a quick response before all the Americans wake up :)

Basically analysisXML has this structure that allows a number of 
(sub)schema 'modules' to be plugged into a 'core' bit. This 
means that in one incarnation it is a model of peptide/protein 
identification, with a description of data source, engine and 
parameters in one bit, the reults in the next one and finally 
the 'knowledge' in the third.

For quantitation, there will be a similar set of modules (to cut 
to the chase, they aren't there yet except as stubs afaik). 
Basically these too may split three ways (although it isn't 
immediately clear to me what will be in the third bit, possibly 
nothing). Number one would be a 'how did I measure intensities 
and with what data' bit; number two being the 'here's the actual 
measured amounts after scaling, normalising, taking ratios etc.

As I say though, it isn't there yet afaik. And I stand to be 
corrected once this post has been seen by those more fully in 
the know than I.

Cheers, Chris.


Jennifer Siepen wrote:
> Hi,
> 
> I am new to the list and have a query about analysisXML/mzIdent. Here at 
> Manchester we have a number of groups carrying out studies with 
> quantitation in proteomics. My query is how does analysisXML/mzIdent 
> cope with quantitation, and are relative and absolute quantitation both 
> catered for?
> 
> Many thanks for any help/information,
> 
> Jennifer
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://psidev.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

[Psidev-ms-dev] analysisXML/mzIdent & quantitation

[Jennifer S. <jen...@ma...>]

Hi,

I am new to the list and have a query about analysisXML/mzIdent. Here at 
Manchester we have a number of groups carrying out studies with 
quantitation in proteomics. My query is how does analysisXML/mzIdent 
cope with quantitation, and are relative and absolute quantitation both 
catered for?

Many thanks for any help/information,

Jennifer

-- 

Dr. Jennifer Siepen
Faculty of Life Sciences, 
University of Manchester, 
Smith Building, Oxford Rd, 
Manchester, M13 9PT, UK.
Tel: +44 (0)161 2751680 

RE: [Psidev-ms-dev] mzData issues

[Brian P. <bri...@in...>]

> If everyone who has a working mzData=20
> tool will drop a line to this mailing list, I will make sure=20
> the tools=20
> section gets updated.

InsilicosViewer (available at www.insilicos.com) supports mzData. =20

The Trans-Proteomic Pipeline from the ISB also supports mzData (see =
http://tools.proteomecenter.org/software.php).

- Brian Pratt, Insilicos

> -----Original Message-----
> From: psi...@li...=20
> [mailto:psi...@li...] On Behalf=20
> Of Randy Julian
> Sent: Tuesday, November 29, 2005 7:47 PM
> To: Andy Jones
> Cc: psi...@li...
> Subject: Re: [Psidev-ms-dev] mzData issues
>=20
> PSI-MS Developers,
>=20
> Just a quick note regarding mzData 1.1 prototype. It now=20
> looks like the=20
> smart way to go is to provide a mzData 1.1 for review in January (as=20
> agreed in Geneva) with the goal of completing the release at=20
> the Spring=20
> 2006 meeting. My preference is for mzData 1.1 to be a maintenance=20
> release adding new 'optional' elements which mean anyone=20
> generating 1.05=20
> files can continue to do so, and anyone who wants to use the new=20
> features of 1.1 will not break any current parsers. The main=20
> reason for=20
> the proposed schedule is that we are making plans to merge=20
> mzData with=20
> mzXML, and I don't see how this could be done easily before January=20
> allowing sufficient review time before a meeting in the Spring. What=20
> does seem possible is to keep mzData as stable as possible while=20
> addressing the main complaints regarding redundancy of instrument=20
> parameters by grouping of 'scans' into 'experiments' and providing a=20
> mechanism for providing all of the instrument parameters for=20
> a 'group'=20
> of scans. We could have the merged mzData/mzXML in draft mode by the=20
> Spring meeting (if we get help) and finalized by the Fall=20
> meeting which=20
> could mean adoption in the Fall, or if there is more=20
> refinement needed=20
> by the end of 2006.
>=20
> Keeping mzData stable should allow developers to add tools=20
> without the=20
> worry you are expressing - that the thing will move too fast=20
> and prevent=20
> stable development. This is countered by people who say 'why=20
> should it=20
> take so long? fix it and be done with it...' We could use=20
> more feedback=20
> on this.
>=20
> I have heard that the XSLT-based translator is slow on large=20
> files. This=20
> is because there is a script which splits the mzXML joint=20
> mz/inten data=20
> vector into the separated vectors used in mzData. This could be done=20
> very quickly in C/C++ or in Java. No one has written such a=20
> program yet,=20
> but given the example of the ProteomeSystems converter, it would not=20
> take anyone with a serious number of mzXML files to convert long to=20
> write - I am not aware of anyone who has done this yet.
>=20
> I have also not heard of any attempt to resurrect the=20
> original Java GUI=20
> application Kai Runte wrote while at the EBI which could perform the=20
> type of ASCII->mzData conversion you mentioned. This code=20
> base is in the=20
> CVS tree and could be picked up by a Java-capable volunteer and made=20
> compatible with 1.05 (and beyond). Anyone wishing to work on=20
> this please=20
> contact me.
>=20
> Finally, there are reports of a number of viewers - several=20
> groups seem=20
> to be working on them, and we have our own (which I'll share if you=20
> want), so I don't have experience with anyone else's. This is how I=20
> check the base64 strings. There are other base64/IEEE-float analysis=20
> tools which you could use if you want to strip out the string for=20
> testing, but I just use an mzData parsing viewer. It would be=20
> helpful if=20
> we organized the toolset for mzData and gave pointers to things like=20
> viewers, parsers and converters. If everyone who has a working mzData=20
> tool will drop a line to this mailing list, I will make sure=20
> the tools=20
> section gets updated.
>=20
> Randy Julian
>=20
>=20
> Andy Jones wrote:
>=20
> > Hi,
> >
> > I'm trying to convert data from various different instruments into=20
> > mzData and I have a few questions.
> >
> >    1. One of the instruments produces plain text output for the peak
> >       list (peak [tab] intensity). Does anyone have a script or some
> >       code for turning this into the mzData base 64 binary.=20
> Otherwise,
> >       any advice for how best to do this would be welcome.
> >    2. What is the current time scale for the updated=20
> version of mzData
> >       that is being discussed. If I produce parsers that convert to
> >       mzData v 1.05, will I need to re-write them fairly=20
> soon for the
> >       next version?
> >    3. What are the current plans with respect to future versions of
> >       mzXML and mzData. I have tried out the ProteomeSystems
> >       converter. It runs very slowly over large files but it does
> >       produce valid mzData files, although I don't know how to check
> >       if the peak list conversion is correct. Is this a=20
> viable way of
> >       producing mzData if I can get mzXML files first? Does anyone
> >       have any experience of using the converter in practice.
> >
> > Any advice would be most appreciated, cheers,
> >
> > Andy
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web. =20
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dick
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>=20

Re: [Psidev-ms-dev] mzData issues

[Jimmy E. <jk...@gm...>]

Andy,

One nice peak list data conversion tool which is capable of taking peak
lists in various ASCII formats (Mascot generic format, PKL, DTA, etc.) and
outputting to mzData is the Peak List Conversion Utility available at the
Proteome Commons website

   http://www.proteomecommons.org/tools.jsp#File%20Format%20Manipulation

It's an easy to use Java Web Start app that might suit your needs.

- Jimmy

Andy Jones wrote:
>
> > Hi,
> >
> > I'm trying to convert data from various different instruments into
> > mzData and I have a few questions.
> >
> >    1. One of the instruments produces plain text output for the peak
> >       list (peak [tab] intensity). Does anyone have a script or some
> >       code for turning this into the mzData base 64 binary. Otherwise,
> >       any advice for how best to do this would be welcome.
> >
>

Re: [Psidev-ms-dev] mzData issues

[Randy J. <rkj...@mi...>]

PSI-MS Developers,

Just a quick note regarding mzData 1.1 prototype. It now looks like the=
=20
smart way to go is to provide a mzData 1.1 for review in January (as=20
agreed in Geneva) with the goal of completing the release at the Spring=
=20
2006 meeting. My preference is for mzData 1.1 to be a maintenance=20
release adding new 'optional' elements which mean anyone generating 1.0=
5=20
files can continue to do so, and anyone who wants to use the new=20
features of 1.1 will not break any current parsers. The main reason for=
=20
the proposed schedule is that we are making plans to merge mzData with=20
mzXML, and I don't see how this could be done easily before January=20
allowing sufficient review time before a meeting in the Spring. What=20
does seem possible is to keep mzData as stable as possible while=20
addressing the main complaints regarding redundancy of instrument=20
parameters by grouping of 'scans' into 'experiments' and providing a=20
mechanism for providing all of the instrument parameters for a 'group'=20
of scans. We could have the merged mzData/mzXML in draft mode by the=20
Spring meeting (if we get help) and finalized by the Fall meeting which=
=20
could mean adoption in the Fall, or if there is more refinement needed=20
by the end of 2006.

Keeping mzData stable should allow developers to add tools without the=20
worry you are expressing - that the thing will move too fast and preven=
t=20
stable development. This is countered by people who say 'why should it=20
take so long? fix it and be done with it...' We could use more feedback=
=20
on this.

I have heard that the XSLT-based translator is slow on large files. Thi=
s=20
is because there is a script which splits the mzXML joint mz/inten data=
=20
vector into the separated vectors used in mzData. This could be done=20
very quickly in C/C++ or in Java. No one has written such a program yet=
,=20
but given the example of the ProteomeSystems converter, it would not=20
take anyone with a serious number of mzXML files to convert long to=20
write - I am not aware of anyone who has done this yet.

I have also not heard of any attempt to resurrect the original Java GUI=
=20
application Kai Runte wrote while at the EBI which could perform the=20
type of ASCII->mzData conversion you mentioned. This code base is in th=
e=20
CVS tree and could be picked up by a Java-capable volunteer and made=20
compatible with 1.05 (and beyond). Anyone wishing to work on this pleas=
e=20
contact me.

=46inally, there are reports of a number of viewers - several groups se=
em=20
to be working on them, and we have our own (which I'll share if you=20
want), so I don't have experience with anyone else's. This is how I=20
check the base64 strings. There are other base64/IEEE-float analysis=20
tools which you could use if you want to strip out the string for=20
testing, but I just use an mzData parsing viewer. It would be helpful i=
f=20
we organized the toolset for mzData and gave pointers to things like=20
viewers, parsers and converters. If everyone who has a working mzData=20
tool will drop a line to this mailing list, I will make sure the tools=20
section gets updated.

Randy Julian


Andy Jones wrote:

> Hi,
>
> I=92m trying to convert data from various different instruments into=20
> mzData and I have a few questions.
>
>    1. One of the instruments produces plain text output for the peak
>       list (peak [tab] intensity). Does anyone have a script or some
>       code for turning this into the mzData base 64 binary. Otherwise=
,
>       any advice for how best to do this would be welcome.
>    2. What is the current time scale for the updated version of mzDat=
a
>       that is being discussed. If I produce parsers that convert to
>       mzData v 1.05, will I need to re-write them fairly soon for the
>       next version?
>    3. What are the current plans with respect to future versions of
>       mzXML and mzData. I have tried out the ProteomeSystems
>       converter. It runs very slowly over large files but it does
>       produce valid mzData files, although I don=92t know how to chec=
k
>       if the peak list conversion is correct. Is this a viable way of
>       producing mzData if I can get mzXML files first? Does anyone
>       have any experience of using the converter in practice.
>
> Any advice would be most appreciated, cheers,
>
> Andy
>

Re: [Psidev-ms-dev] mzData issues

[simon a. (B. <sim...@bb...>]

On 29 Nov 2005, at 12:01, Andy Jones wrote:

> Hi,
> I=92m trying to convert data from various different instruments into=20=

> mzData and I have a few questions.
> =A0
> 	1 	One of the instruments produces plain text output for =
the peak=20
> list (peak [tab] intensity). Does anyone have a script or some code=20
> for turning this into the mzData base 64 binary. Otherwise, any advice=20=

> for how best to do this would be welcome.

You didn't mention which language you were using to do your processing.=20=

  When I was decoding Base64 in Java I used this nice little (free)=20
library, which also does encoding.

http://iharder.sourceforge.net/base64/

Before the Base64 encoding you'll need to convert your float/double=20
values to byte arrays (4 bytes per float or 8 bytes per double), then=20
encode the byte array.  The Float and Double classes have built-in=20
methods to convert to int / long and then you just need to split these=20=

down to their component bytes.

eg for a float f, to get the 4 little endian bytes would be

int i =3D Float.float.ToIntBits(f);

byte [] bytes =3D new byte[4];

bytes[0] =3D (i & 0xFF);
bytes[1] =3D (i >> 8) & 0xFF;
bytes[2] =3D (i>>16) & 0xFF;
bytes[3] =3D (i>>24) & 0xFF;

You'd then encode this to get the string you include in the mzData file:

String s =3D Base64.encodeBytes(bytes);


Hope this helps

Simon.

--=20
Simon Andrews PhD
Bioinformatics Dept.
The Babraham Institute

sim...@bb...
+44 (0) 1223 496463

[Psidev-ms-dev] mzData issues

[Andy J. <aj...@cs...>]

Hi,

I'm trying to convert data from various different instruments into mzData
and I have a few questions.

 

1.	One of the instruments produces plain text output for the peak list
(peak [tab] intensity). Does anyone have a script or some code for turning
this into the mzData base 64 binary. Otherwise, any advice for how best to
do this would be welcome.
2.	What is the current time scale for the updated version of mzData
that is being discussed. If I produce parsers that convert to mzData v 1.05,
will I need to re-write them fairly soon for the next version?
3.	What are the current plans with respect to future versions of mzXML
and mzData. I have tried out the ProteomeSystems converter. It runs very
slowly over large files but it does produce valid mzData files, although I
don't know how to check if the peak list conversion is correct. Is this a
viable way of producing mzData if I can get mzXML files first? Does anyone
have any experience of using the converter in practice.

 

Any advice would be most appreciated, cheers,

Andy

[Psidev-ms-dev] Minutes from 8 Nov Teleconference and review of mzData 1.1 prototype

[Randy J. <rkj...@in...>]

The minutes from the 8 November 2005 Teleconference have been posted to 
the PSI Docstore:

http://psidev.sourceforge.net/docstore/browse.php?sess=0&parent=4&expand=1

Please review the notes and forward any corrections to questions to 
Randy Julian

Please note that there is a prototype version of mzData which can be 
reviewed at:

http://psidev.sourceforge.net/docstore/browse.php?sess=0&parent=7&expand=1 
<https://webmail1.cf.ac.uk/servlet/webacc?merge=linkurl&Url.linkText=http%3a%2f%2fpsidev%2esourceforge%2enet%2fdocstore%2fbrowse%2ephp%3fsess%3d0%26parent%3d7%26expand%3d1>

Download the file "mzData_110.tgz" which contains a version of the 
mzData schema with the following features:

1. Organized like analysisXML (uses container types for expansion)
2. Backward compatible with 1.05.  Current mzData files should validate 
with the mzDataMaster.xsd schema
3. Added (optional) chromatographic objects to store TIC, SRM and MRM 
experimental data
4. Added (option) "experiment" description section which can be used to 
store instrument parameters which are currently repeated in each scan

The schema is still a work-in-progress and not ready for production, but 
represents one method for unifying the extension methods of mzData and 
analysisXML without breaking the existing format.

Send any feedback on this schema approach (and to analysisXML: 
http://psidev.sourceforge.net/docstore/browse.php?sess=0&parent=6&expand=1) 
to Randy Julian.

Thanks!

[Psidev-ms-dev] [Fwd: [Psidev-gps-dev] Minutes from today's gelML call]

[Chris T. <chr...@eb...>]

Hi all.

Sorry for the cross-post for those who are affected. Just 
thought it wise to braid a couple of threads together...

Wrt the excellent minutes from the 2005-10-25 MS/SG call; we 
yesterday discussed MIAPE both for GE and in general (cf. point 
7 in the Randy's minutes). Editted summary below; a major driver 
for this was NP's comments on the MIAPE: GE document 
(http://sourceforge.net/mailarchive/message.php?msg_id=13709946). 
This is fundamental SG activity as defined previously (I'll kick 
it off as described below, but then it needs feedback from 
across the board)...

Incidentally I also like the examples thing, also below. This is 
potentially something to require as a subsidiary item in the 
four-membered list for each technical WG (format, CV, spec doc, 
reporting requirement); although I would prefer that the example 
come in document form in the first instance rather than trying 
to simultaneously demo a format and CV; this is just about scope 
and feasibility for fulfilling the MIAPE module's requirements 
-- to test the format and CV would be too complex (although that 
absolutely should be done _as well_...), both from a testing and 
from a getting-normal-people-to-do-it point of view.

Cheers, Chris.


-------- Original Message (heavily snipped) --------
Subject: [Psidev-gps-dev] Minutes from today's gelML call
(http://sourceforge.net/mailarchive/message.php?msg_id=13788142)


Attendees

Andy Jones
Frank Gibson
Chris Taylor
Christine Hoogland
Pierre-Alain Binz


Discussed

In General:
The relationship as to how the MIAPE documents in general (not 
just GE) relate back to the parent document, is unclear and not 
specific enough. We should probably reference sections of the 
parent document. This involves updating the parent document.

Action; Chris will work on an outline for all MIAPE modules, and 
create a MIAPE template document with a defined structure and 
details of how to complete a MIAPE document.


Example descriptions:
It was suggested by Norman that we should have examples of how 
the MIAPE.GE can be completed with real data as example 
descriptions. This should be done before the external review 
process, but may also be part of it.

Action; Chris will recruit some people to give example documents 
to try this out.

~~~~~~~~~~~~~~~~~~~~~~~~
  chr...@eb...
  http://psidev.sf.net/
~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Psidev-ms-dev] Time of Next Teleconference

[David C. <dc...@ma...>]

Are these times correct for the call today:

  8:00 am PST
11:00 am EST
  4:00 pm GMT / UTC
  5:00 pm CET (Geneva)

Perhaps we should always specify the time in UTC?

David


Ruth McNally wrote:
> Prior to the next teleconference,  a number of time zones, including EST, will
> be adopting daylight saving time. So we need to clarify the time of the next
> teleconference. Also, although a different opinion was expressed at the last
> Teleconference, I still think that previous Teleconferences have taken place at
> 1000 EST. Perhaps Kent, you could tell us what time it will be for you & the
> rest of us can work it out from there. 
> 
> Have a good weekend, Ruth
> 
> Dr Ruth McNally
> Senior Research Associate
> ESRC Centre for Economic and Social Aspects of Genomics (CESAGen)
> Cardiff University
> 6 Museum Place
> Cardiff CF10 3BG
> Tel: +44 (0)1234 296057
> Fax: +44 (0)1234 294157
> Mobile: +44 (0)7834489770
> Email: McN...@cf...
> http://www.cesagen.lancs.ac.uk/staff/mcnally2.htm
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev

-- 
David Creasy
Matrix Science
8 Wyndham Place
London W1H 1PP
Tel +44 (0)20 7723 2142
Fax +44 (0)20 7725 9360

dc...@ma...
http://www.matrixscience.com