Menu
▾
▴
Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008
|
From: Fredrik L. <Fre...@im...> - 2008-02-22 12:18:15
|
Just have to take back my last post. Acquistion elements should always refer to scans outside the present mzML file (I think?), so the current format is fine. I would like to have the schema constraint that a sourceFileRef should always point to a file within the sourceFileList, and could thus be of type xs:IDREF, though. I guess the spectrumRef could be populated with something which makes it easy to locate the scan in the vendor file, if we're not lucky and have a proper mzML file to refer to, for example: <acquisition number="0" spectrumRef="FUNC2_SCAN0" sourceFileRef="SF1"/> Remaining question is if precursor spectrumRef is allowed to point out of the file. 'Raw' mzML files should normally contain the precursor spectrum, while peak lists probably don't. Maybe an optional sourceFileRef attribute at the precursor element could make up for the two cases, so that external referencing can be done as for acquisitions. If the id of the precusor scan is known in an external file, it could be interesting to keep that information, or do you think that one should leave out the precursor spectrumRef completely if the MS1 scan of the precursor is not found within the mzML file? I've updated the acquisition elements of the example file, to something which should make a bit more sense, and put an intermediate solution for the precursor spectrumRef at: http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/FF_070504_MSMS_5B_edited.mzML Also updated the experimental schema to use xs:ID for all ids (except for the mzML file id). The changes can be highlighted by clicking 'Last Change' in the upper right corner. Fredrik Fredrik Levander wrote: > Hi Darren, > > Yes, it should be enough with a spectrumRef for the acquisition element > (no real need for sourceFileRef). The spectrumRef could be either the > spectrum id if the spectrum is found within the file or the full URI (or > something like your example) of the spectrum in an external file. > > Also, I see that the precursor elements should not have any spectrumRef > in my example files, since the spectra are not found within the mzML > file. Maybe these spectrumRefs could be replaced by a full URI or > something indicating that they are external, but right now it's not > correct. With a change to xs:ID for spectrum id and xs:IDREF for > precursor spectrumRef this error would not have passed validation... > > Fredrik > > Kessner, Darren E. skrev: > >> Hi guys, >> >> The two example docs (Lennart, Fredrik) don't seem to agree on the use >> of 'id', 'index', and 'spectrumRef'. >> >> My understanding from previous discussions (which may be incorrect): >> id: unique string identifier for <spectrum> >> spectrumRef: refers to 'id' attribute of <spectrum> // previous >> index: 0-based index into <spectrumList> // Randy >> >> >> Lennart example: >> index == scanNumber >> spectrumRef -> refers to index >> >> <spectrum id="S19" index="19" msLevel="1" arrayLength="1313"> >> ... >> </spectrum >> <spectrum id="S20" index="20" msLevel="2" arrayLength="43"> >> <precursor spectrumRef="19"> >> ... >> </spectrum> >> >> >> Fredrik example: >> index == 0-based index in the <spectrumList> >> spectrumRef -> reference to something in another sourcefile >> >> <spectrum id="S1" index="0" msLevel="2" arrayLength="172"> >> ... >> <acquisition number="0" spectrumRef="0" sourceFileRef="4"> >> ... >> </acquisition> >> <acquisition number="1" spectrumRef="1" sourceFileRef="4"/> >> ... >> <precursor spectrumRef="0"> >> </spectrum> >> >> >> Does this mean that spectrumRef is internal unless there is a >> sourceFileRef, in which case the spectrumRef refers to something inside >> the external file? >> >> I would prefer to have external references made more explicit. >> >> Perhaps this calls for an html-anchor-like syntax, as Matt suggested in >> the conference call? >> <acquisition number="1" spectrumRef="external://4#1"/> >> i.e. >> 4 is the sourceFile id >> 1 refers to something in that external file >> >> >> Darren >> >> >> >> >> >> >> >> IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by >> applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is STRICTLY PROHIBITED. >> >> If you have received this message in error, please notify us immediately >> by calling (310) 423-6428 and destroy the related message. Thank You for your cooperation. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Psidev-ms-dev mailing list >> Psi...@li... >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Psidev-ms-dev mailing list > Psi...@li... > https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev > |
