Re: [Psidev-ms-dev] Spectra from summed acquisitions in mzML 0.99.10

[Darren K. <Dar...@cs...>]

I think it's a bad idea to have a spectrumRef to a spectrum that isn't  
in the file.  We should be consistent in the use of internal  
references, all of which use IDREF so that dangling references can be  
caught during XML validation.

External references, including those to spectra that have been removed  
for space reasons, should be indicated specifically (e.g. with  
externalSpectrumID or externalNativeID) so that the reader (human or  
software) knows that they'll have to do some extra work to find the  
referent.


Darren



On May 2, 2008, at 6:17 AM, Matt Chambers wrote:

> Perhaps we should follow the same logic of the spectrum element  
> itself,
> where id is required but nativeID is optional. Thus, id is required  
> for
> a spectrum reference and a reference to the nativeID would be optional
> (but recommended!). We can't use the same attribute to point to either
> id or nativeID because then it won't be known which is being referred
> to, unless I'm missing something in Fredrik's proposal.
>
> To deal with IDs that aren't in the file, I agree with Fredrik. Any  
> time
> we have a reference that can be to a non-existent or external element,
> we can't use IDREF. We either need to switch to xlink (in which case
> IDREF would probably still be ok) or fall back to string. However,  
> since
> I think that acquisitions should be able to reference spectra in the
> current file, we shouldn't change it to externalSpectrumID. We should
> just document that all spectrumRef and spectrumNativeID(Ref?)  
> attributes
> may refer to a spectrum in the current file or in another one, and in
> the former case the spectrum might not actually be there (i.e. MSn
> spectra referencing precursor spectra that have been stripped out to
> conserve space).
>
> -Matt
>
>
> Rune Schjellerup Philosof wrote:
>> I think the format by which external file elements are reference  
>> should
>> be defined.
>> For instance, a reference to a Waters raw file, should that be
>> function1scan2, func1scan2, 1.2 or ....
>>
>> --
>> Rune
>>
>> Fredrik Levander wrote:
>>
>>> Hi All,
>>>
>>> There is an issue with the current mzML schema (0.99.10) when it  
>>> comes
>>> to referencing the origin of acquisitions in an acquistionList of
>>> summed spectra. In most cases the referenced spectra will not be in
>>> the current mzML file, and thus the spectrumRef cannot be of the  
>>> type
>>> xs:IDREF, but should be xs:string to also cover references to  
>>> spectrum
>>> IDs in other mzML files, or native IDs in vendor files.
>>>
>>> The following would cover both internal and external spectrum
>>> referencing:
>>>
>>>
>>> 	<xs:complexType name="AcquisitionType">
>>> 		<xs:annotation>
>>> 			<xs:documentation>Scan or acquisition from original raw file used
>>> to create this peak list, as specified in sourceFile.</ 
>>> xs:documentation>
>>> 		</xs:annotation>
>>> 		<xs:complexContent>
>>> 			<xs:extension base="dx:ParamGroupType">
>>> 				<xs:attribute name="number" type="xs:int" use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>A number for this acquisition.</
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="spectrumRef" type="xs:string"  
>>> use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum if found within an mzML  
>>> file, or
>>> the native spectrum identifier in a raw file in another format. </
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="sourceFileRef" type="xs:IDREF"  
>>> use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate sourceFile. It can also refer to the
>>> present mzML file.</xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 			</xs:extension>
>>> 		</xs:complexContent>
>>> 	</xs:complexType>
>>>
>>> However, I am not sure if there are any use cases when both the  
>>> summed
>>> spectrum and the original spectra are found in the same file. If  
>>> not,
>>> the spectrumRef attribute should maybe be renamed to
>>> 'externalSpectrumID' or something else, since 'spectrumRef' somehow
>>> indicates that the spectrum is in the present file.
>>>
>>> If there is a need to reference spectra within the file the  
>>> following
>>> may be an alternative (I think Darren proposed something similar):
>>>
>>> 	<xs:complexType name="AcquisitionType">
>>> 		<xs:annotation>
>>> 			<xs:documentation>Scan or acquisition from original file used to
>>> create this peak list. Either a spectrumRef or an externalSpectrumID
>>> plus sourceFileRef should be given .</xs:documentation>
>>> 		</xs:annotation>
>>> 		<xs:complexContent>
>>> 			<xs:extension base="dx:ParamGroupType">
>>> 				<xs:attribute name="number" type="xs:int" use="required">
>>> 					<xs:annotation>
>>> 						<xs:documentation>A number for this acquisition.</
>>> xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="spectrumRef" type="xs:IDREF" use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum. </xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 				<xs:attribute name="externalSpectrumID" type="xs:string"
>>> use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate spectrum if found within an external  
>>> mzML
>>> file, or the native spectrum identifier in a raw file in another
>>> format. </xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> <xs:attribute name="sourceFileRef" type="xs:IDREF" use="optional">
>>> 					<xs:annotation>
>>> 						<xs:documentation>This attribute must reference the 'id'
>>> attribute of the appropriate sourceFile. It can also refer to the
>>> present mzML file.</xs:documentation>
>>> 					</xs:annotation>
>>> 				</xs:attribute>
>>> 			</xs:extension>
>>> 		</xs:complexContent>
>>> 	</xs:complexType>
>>>
>>> So, main question: are there any use cases with the original scans  
>>> and
>>> the summed spectrum in the same file, and is there in this case a  
>>> need
>>> to distinguish clearly between external and internal referencing
>>> (second schema alternative)?
>>>
>>> A minor point is also that the documentation of the spectrum  
>>> attribute
>>> nativeID should be updated to something like:
>>>
>>> The native identifier for the spectrum, used by the acquisition
>>> software. If the spectrum is reconstructed from more than one
>>> spectrum, the native identifier of the first acquisition in time
>>> should be used.
>>>
>>> Regards
>>>
>>> Fredrik
>>>
>>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev