psidev-pi-dev — General Development List for Proteomics Informatics

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #23 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

That's a very good point. I don't recall that we've addressed the issue of  
synthetic
spectra in the mzML group yet. They may either be synthesized by the  
acquisition
software or by a spectral decoy/theoretical generation program. If the mzML  
is the
original file, then it seems to me that "spectrum=xsd:nonNegativeInteger"  
would be
all that was necessary, because concepts like period, cycle, controller,  
function,
etc. are all abstracted away.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #22 on issue 53 by eisenachM: Encoding spectrum identifiers for  
MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

In the future there might hopefully be no "original" file, because all  
instruments
produce directly mzML (in which case we need a "mzML native ID" term).

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #21 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

I think you misunderstood me. Again taking the WIFF example, if you read a  
spectrum
from a WIFF file into ProteinScape, do you keep track of the
sample/period/cycle/experiment, or do you lose that information by putting  
it in the
database?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #20 on issue 53 by eisenachM: Encoding spectrum identifiers for  
MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

In the MPC use case I cannot use the MGF "ID" because the mgf is "lost",  
once the
spectra data is imported into ProteinScape. (Proteinscape sends data to  
search
engines by creating temporary MGFs not visible to the user).

I agree, that we could use a generic database ID, as the ID itself is not  
accessible
to the users. I suggested the "specialised" ID as we have those specialised  
ID in the
file case also (Bruker BAF, Bruker YEP).

The main argument now should be, that we need a "release" of the example  
files.


--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #19 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Let me put it another way: the mzML file will have an id that, for a WIFF  
file, MUST
look like "sample=x period=x cycle=x experiment=x". What reason is there to  
call that
an "mzML" nativeID instead of a WIFF nativeID?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #18 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

In order to be able to delete an intermediate mzML and go straight from  
mzIdentML to
a native file, it would be nice to have sourceFile/dataProcessing info  
forwarded from
the mzML to the mzIdentML, but that might be overkill.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #17 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

No. File format is not transitive, nativeID is. Use the nativeID, we  
already had this
discussion. NativeID works for all input file types; "pigs_might_fly_02"  
used to work
for mzML but in 1.1 there is only nativeID.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #16 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Following this argument through would mean that we would then need to  
specify the
fileFormat as a .wiff file rather than the mzML file which seems crazy. We  
aren't
including much (any) information about how the peak list was produced from  
the raw
data, so you _have_ to go back to the mzML file for all that good stuff. We  
just want
an index into the mzML file. It could be pigs_might_fly_01,  
pigs_might_fly_02 etc.
for all we care!

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #15 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

The nativeID is transitive: transcoding through mzML does not change the  
nativeID
format. You should use the same nativeID format that the input document  
used because
that's the only reasonable way you're going to preserve the meaning  
of "sample=1
period=1 cycle=123 experiment=2".

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #14 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

I agree. So, we have 3 choices:
  1. use MS:1000767 (not especially intuitive)
  2. make a new term that is a child of MS:1000767
  3. make a new term that is a child of ???

Problem with #2 is that it is a bit recursive and could be confusing to the  
mzML people?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #13 on issue 53 by andrewrobertjones: Encoding spectrum identifiers  
for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

I think we should have a term specifically for mzML where the value is  
exactly
whatever is contained within the <spectrum id="[ ]" > attribute in mzML.  
mzIdentML
converters shouldn't need to worry about where the ID format came from  
further back
in the pipeline?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #12 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

One more thing to agree on...
If the input file is an mzML file, then the fileFormat is:
MS:1000584, name: mzML file

but should the new <spectrumIDFormat> be:
MS:1000767, name: native spectrum identifier format
or the child term specified in the actual mzML file, for example
MS:1000768, name: Thermo nativeID format



--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #11 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Someone else (Martin) may have comments about the database part. Maybe it  
should be
specific to ProteinScape rather than a generic database. However, I think I  
agree
with you because the use case here would typically be an export from  
ProteinScape to
someone who doesn't have that particular ProteinScape database, but may  
have the peak
list and/or raw data file.

For the query number, I partially agree that the file format for the  
<SpectraData>
should be .DAT file.
For an mgf file, there is of course a way to get back to the spectrum in  
the raw data
file because, in this case, we save the title, scans, retention time etc.  
as separate
cv items in the mzIdentML file. However, as you say, the index itself  
doesn't help
you get back in one go.
The typical use case will be that the consumer of the mzIdentML file may  
also have
the mgf/pkl/dta file and/or the raw data, but not the .dat file.
One problem with using the .dat file as the filename is that you lose the  
information
about the filename of the mgf/pkl/dta file. Maybe that filename just has to  
be a user
param? Also, we already have the name of the .dat file a few lines above as:
   <DataCollection>
     <Inputs>
       <SourceFile location="file:///../data/F001350.dat" id="SF_1" >
         <fileFormat>
           <cvParam accession="MS:1001199" name="Mascot DAT file"  
cvRef="PSI-MS" />

So, I don't have too strong a feeling either way about what the fileFormat  
of the
<SpectraData> should be.

However, the description for "multiple peak list nativeID format" would be  
rather
misleading:
   Index is the spectrum number in the file, starting from 0
So I still think that there should be a new CV term for the query number  
even if we
change the 'i.e.' to 'e.g.'


--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #10 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Do these non-native databases really not store the necessary information to  
get back
to the native spectrum? That would be surprising. If they do, I think the  
thing to do
is use the original nativeID. If not, then some other term should be  
appropriate. A
generic "database nativeID" term is silly. For one thing, certainly not all  
databases
will use xsd:long as a primary key! The nativeID string would make a  
sensible
nativeID as well (albeit slower, but still reasonable). So for a database  
format that
uses a single integer identifier, maybe mzData's term "spectrum identifier"  
with
"spectrum=xsd:nonNegativeInteger" would be appropriate.

For the query number, what would the file format term be? It wouldn't seem  
right for
it to be MGF if you can't map the query number back to the MGF index.  
Instead,
perhaps DAT should be a valid term for file format and that could easily  
indicate
that the id has been rendered useless for getting back to the raw spectrum  
because
it's been disconnected from the nativeID?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #9 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

If we use the same "multiple peak list nativeID format", then an importer  
can't tell
whether the index is for the query number or an index into the original  
mgf/pkl/dta file?
The comment says 'i.e.' and not 'e.g.' so strictly speaking it's just  
restricted to
those three file types.

The database term isn't for a 4000/5000 series database. It's intended for
ProteinScape or any 'generic' rdb where spectra are stored. The format for  
MS:1001480
is pretty specific to the tof-tofs.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #8 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

To clarify, I think in retrospect some of the vendor nativeIDs that have  
the same
"scan=xxx" definition should probably have been made as synonyms of "scan  
number
only" instead of making separate terms. The same would apply to "index=xxx"  
terms.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #7 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Can you just reuse "multiple peak list nativeID format" instead of making a  
new term?
It's the same index=xsd:nonNegativeInteger.

Also, the database nativeIDs deserve more discussion. Are those databases  
actual
native sources, like the Oracle database used by ABI's 4000 and 5000 series  
TOF-TOFs?
Or are they importing native spectra into the database?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #6 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Following the telecon yesterday, we've agreed that rather than adding  
a "native
spectrum identifier format" CV item to the <fileFormat> element, we should  
use a new
<spectrumIDFormat> element. For example:

   <SpectraData location="file:///est_coding_test.mgf" id="SD_1">
     <fileFormat>
       <cvParam accession="MS:1001062" name="Mascot MGF file" cvRef="PSI-MS"  
/>
     </fileFormat>
     <spectrumIDFormat>
       <cvParam accession="MS:1000774" name="multiple peak list nativeID  
format"
cvRef="PSI-MS" />
     </spectrumIDFormat>
   </SpectraData>

This requires the following addition to the mapping file:

CvMappingRule id="SpectraDataSpectrumIDFormat_rule"
cvElementPath="/mzIdentML/DataCollection/Inputs/SpectraData/spectrumIDFormat/cvParam/@accession"
requirementLevel="MUST" scopePath="" cvTermsCombinationLogic="OR">
<CvTerm termAccession="MS:1000767" useTermName="false" useTerm="false"
termName="native spectrum identifier format"
isRepeatable="false" allowChildren="true" cvIdentifierRef="MS" />
</CvMappingRule>

And the the following additional CV items:

[Term]
id: MS:1001526
name: spectrum from database nativeID format
def: "databasekey=xsd:Long" [PSI:MS]
comment: A unique identifier of a spectrum stored in a database (e.g. a  
PRIMARY KEY
identifier).
is_a: MS:1000767 ! native spectrum identifier format

[Term]
id: MS:1001527
name: Proteinscape spectra
def: "Spectra from Bruker/Protagen Proteinscape database." [PSI:MS]
is_a: MS:1000560 ! mass spectrometer file format

[Term]
id: MS:100xxxxx
name: Mascot query number
def: "index=xsd:nonNegativeInteger" [PSI:MS]
comment: The spectrum (query) number in a Mascot results file, starting  
from 1.
is_a: MS:1000767 ! native spectrum identifier format
is_a: MS:1001405 ! spectrum identification result details

(Should this be 2 separate CV items?)

and add an is_a to
id: MS:1001114
name: retention time(s)
...
is_a: MS:1001405 ! spectrum identification result details

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #5 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

> Or are you more concerned with trying to map back from the mzIdentML to  
> the DAT
> query?
No, that wasn't something we'd really considered, but I guess it could be  
useful,  so
thanks for mentioning it. The assumption is that you'd need the mzIdentML  
file *or*
the .DAT file, not both.


> Is it not possible for the DAT converter to access the input MGF and  
> translate from
> query number to MGF index automagically? Somebody or something must have  
> access to
> the MGF or else an identifier for the spectrum is rather useless.
Yes, (maybe!) but not in a general way. We want a script that can run on  
all Mascot
servers (including our public web site) and for searches that were possibly  
done
years ago. The mgf file is normally on a different computer and may have  
been lost.
If there's no longer an MGF file, the index is of course useless but you  
may still
want an mzIdentML file. For a pkl or merged dta file, there is no reliable  
way to get
back to generating an index.
In the next version of Mascot, we intend to save the index into the  
mgf/pkl/dta file,
so it shouldn't be an issue for new searches.

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #4 on issue 53 by cha...@alum.rpi.edu: Encoding spectrum  
identifiers for MGF, PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

To pick at an old scab, I'll quote the other issue:

> Using a zero based index into the MGF isn't an option for the general  
> purpose program
> that takes a Mascot (.dat) results file and converts it to an analysisXML  
> file
> because it doesn't have the mgf file and doesn't know what the offset is.

> A common use case might be that someone has an anlysisXML document  
> originating from
> an mgf search and thinks a result looks 'interesting'. They then want to  
> go back to
> the original 'raw' data to look at it. Ideally, this should take as few  
> steps as
> possible. The only safe spectrumID value for the Mascot converter is the  
> Mascot query
> number (this is not what the examples use at the moment). So, the user  
> needs the
> Mascot (.dat) results file to then find the title/scan/rtinseconds and  
> from that can
> determine the scan number in the raw data. Seems like a long way round to  
> me and
> requires that they also have the .dat file.

Is it not possible for the DAT converter to access the input MGF and  
translate from
query number to MGF index automagically? Somebody or something must have  
access to
the MGF or else an identifier for the spectrum is rather useless.

Or are you more concerned with trying to map back from the mzIdentML to the  
DAT
query? I can understand in that case that once you've done the automagic  
conversion
from query # to MGF index, it would be tricky to get back to the query  
number. This
seems analogous to WIFF->mzXML conversion losing the critical cycle and  
experiment
numbers which is why we gave mzXML the "scan number only" nativeID format.  
I'm not
sure it makes sense to do that for identifiers which don't store the raw  
spectral
data; how would it apply to other intermediate result formats, e.g. SRF, X!  
Tandem,
SQT, OUT, pepXML? I don't know about SRF, but all the others suffer the  
same problem
as DAT without the aforementioned automagic conversion (usually by parsing  
the
filename/attribute/TITLE a certain way).

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #3 on issue 53 by eisenachM: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

I fully agree reg. the "bloat"!

We could allow more cvParams (maxOccurs="unbounded") under  
SpectraData/fileFormat,
that would be a schema change in FuGElight...

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Comment #2 on issue 53 by dcreasy: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

Too much bloat to have to repeat it for each spectrum?
If there are multiple files, there needs to be multiple <SpectraData> items  
and
therefore multiple <fileFormats>.
I can't see a justification for using different indexes within the same  
file?

--
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

[Psidev-pi-dev] Issue 53 in psi-pi: Encoding spectrum identifiers for MGF, PKL and DTA files

[<cod...@go...>]

Updates:
	Labels: Milestone-Release1.0

Comment #1 on issue 53 by eisenachM: Encoding spectrum identifiers for MGF,  
PKL and DTA files
http://code.google.com/p/psi-pi/issues/detail?id=53

It doesn't work like that, because only one CVParam is allowed under  
<fileFormat>.

Isn't the spectrumID type CV term better placed as CVParam of
SpectrumIdentificationResult?
(That would also allow a mix of several spectrum file types).

Then only the mapping file had to be changed ;-)

--
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

Re: [Psidev-pi-dev] Schema update

[Jones, A. <And...@li...>]

Minutes from today’s call can be found here: http://www.psidev.info/index.php?q=node/436
Cheers
Andy


From: Jones, Andy [mailto:And...@li...]
Sent: 12 August 2009 10:21
To: 'psi...@li...'
Subject: [Psidev-pi-dev] Schema update

Hi all,

I’ve uploaded candidate v1.0.0 versions of the XSDs to the SVN. Can everyone check that their examples validate okay against this version and that there’s nothing I’ve missed moving this from “release candidate 1” to v1.0.0.

Before I upload the final spec document, a minor issue has come up about how we encode spectrum identifiers for MGF files (and possibly other input formats to search engines). It is difficult for some implementations (e.g. Mascot) to encode spectrumID as “index=1”, since Mascot dat files do not store the index of the spectrum within the MGF file. This should not hold up v1 at all though, since I expect encoding policy things will come up as we go along. One option may be to discuss a mechanism for putting these minor policy updates on a webpage?

We will have a quick call to discuss this at 4pm tomorrow (13th Aug) UK time (http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=8&year=2009&hour=16&min=0&sec=0&p1=136)

Call agenda:


1.       Discuss encoding spectrumID

2.       Discuss status of implementations

3.       AOB (please send me agenda items)

Dial in details:

+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)

access code: 297427

cheers
Andy



Schema Commit message:
**********************

Uploading candidate version 1.0.0 releases.

Changed the version number and mzIdentML element version regex.

Also deleted an empty <xsd:sequence/>

Added a minor documentation point to the MassTable (masses given are base masses not including fixed mods)

[Psidev-pi-dev] Schema update

[Martin E. <mar...@ru...>]

Hi!
 
Minor change to schema in svn: in comment line I changed "release candidate 1" to "version 1.0.0"
 
 Bye
  Martin
 
 
 
Von: Jones, Andy [mailto:And...@li...] 
Gesendet: Wednesday, August 12, 2009 11:21 AM
An: 'psi...@li...'
Betreff: [Psidev-pi-dev] Schema update
 
Hi all,
 
I've uploaded candidate v1.0.0 versions of the XSDs to the SVN. Can everyone check that their examples validate okay
against this version and that there's nothing I've missed moving this from "release candidate 1" to v1.0.0.
 
Before I upload the final spec document, a minor issue has come up about how we encode spectrum identifiers for MGF
files (and possibly other input formats to search engines). It is difficult for some implementations (e.g. Mascot) to
encode spectrumID as "index=1", since Mascot dat files do not store the index of the spectrum within the MGF file. This
should not hold up v1 at all though, since I expect encoding policy things will come up as we go along. One option may
be to discuss a mechanism for putting these minor policy updates on a webpage?
 
We will have a quick call to discuss this at 4pm tomorrow (13th Aug) UK time
(http://www.timeanddate.com/worldclock/fixedtime.html?day=13
<http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=8&year=2009&hour=16&min=0&sec=0&p1=136>
&month=8&year=2009&hour=16&min=0&sec=0&p1=136)
 
Call agenda:
 
1.       Discuss encoding spectrumID
2.       Discuss status of implementations
3.       AOB (please send me agenda items)
 
Dial in details:
 
+ Germany: 08001012079
+ Switzerland: 0800000860
+ UK: 08081095644
+ USA: 1-866-314-3683
+ Generic international: +44 2083222500 (UK number)
 
access code: 297427
 
cheers
Andy
 
 
 
Schema Commit message:
**********************
 
Uploading candidate version 1.0.0 releases. 
 
Changed the version number and mzIdentML element version regex.
 
Also deleted an empty <xsd:sequence/>
 
Added a minor documentation point to the MassTable (masses given are base masses not including fixed mods)