psidev-ms-dev — Mass spectroscopy standard development

Re: [Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

[Matthew C. <mat...@va...>]

Ugh. I don't think there should be any reference to acquisitions in the 
index; there is no 1:1 mapping and mapping to the first of the 
acquisitions is counter-intuitive. The scanNumber attribute in the index 
offsets should be replaced by the 0-based index (now that there is an 
index attribute on the spectrum) and if you want to refer to a Thermo 
spectrum by its original scan number, that will somehow have to be 
parsed from the spectrum id attribute or you can generate the 
index->scan mapping when reading and/or generating the file index.

-Matt


Kessner, Darren E. wrote:
>
> Hi all,
>
>  
>
> Please correct me if I'm wrong, but I believe the consensus now is to 
> encode the Thermo scanNumber as the (first) acquisition number:
>
>  
>
>     <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">
>
>         ...
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="17" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>         </spectrumDescription>
>
>         ...
>
>     </spectrum>
>
>  
>
> However, when the mzML is indexed, we still have <offset> entries with 
> attribute 'scanNumber':
>
>  
>
>     <index>
>
>         <offset id="S17" scanNumber="17">4826</offset>
>
>     </index>
>
>  
>
> Shall we make this:
>
>         <offset id="S17" acquisitionNumber="17">4826</offset>
>
> and assume it refers to the *first* acquisition number in the 
> <acquisitionList> ?
>
>  
>
> The use case is the same -- for efficient random access by Thermo 
> scanNumber we need this in the <index>.
>
>  
>
> Previously I had also proposed including the 0-based index, which was 
> deemed unnecessary (and I agree), but someone may want it now for 
> consistency and/or validation?
>
>         <offset id="S17" index="0" acquisitionNumber="17">4826</offset>
>
>  
>
>  
>
> Darren
>
>  
>
>  
>
> Darren Kessner
>
> Scientific Programmer
>
> Dar...@cs... <mailto:Dar...@cs...>
>
> 310-423-9538
>
>  
>
> Spielberg Family Center for Applied Proteomics
>
> Cedars-Sinai Medical Center
>
> http://www.sfcap.cshs.org/
>
>  
>
>  
>
> 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
>   

[Psidev-ms-dev] indexedmzML: scanNumber / acquisition number

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

Please correct me if I'm wrong, but I believe the consensus now is to
encode the Thermo scanNumber as the (first) acquisition number:

 

    <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">

        ...
        <spectrumDescription>

            <acquisitionList count="1">

                <acquisition number="17" spectrumRef="?"
sourceFileRef="?"/>

            </acquisitionList>

            ...

        </spectrumDescription>

        ...

    </spectrum>

 

However, when the mzML is indexed, we still have <offset> entries with
attribute 'scanNumber':

 

    <index>

        <offset id="S17" scanNumber="17">4826</offset>

    </index> 

 

Shall we make this:

        <offset id="S17" acquisitionNumber="17">4826</offset>

and assume it refers to the *first* acquisition number in the
<acquisitionList> ?

 

The use case is the same -- for efficient random access by Thermo
scanNumber we need this in the <index>.

 

Previously I had also proposed including the 0-based index, which was
deemed unnecessary (and I agree), but someone may want it now for
consistency and/or validation?

        <offset id="S17" index="0" acquisitionNumber="17">4826</offset>

 

 

Darren

 

 

Darren Kessner

Scientific Programmer

Dar...@cs...

310-423-9538

 

Spielberg Family Center for Applied Proteomics

Cedars-Sinai Medical Center

http://www.sfcap.cshs.org/

 

 

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.

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

[Kessner, D. E. <Dar...@cs...>]

This could work for precursors as well:

If we have the precursor spectrum in the current file:
<precursor spectrumRef="S1">

If not, but we still know where the precursor can be found:
<precursor externalID="FUNC0_SCAN28" sourceFileRef="SF1">



Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Kessner, Darren E.
Sent: Friday, February 22, 2008 8:08 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

I think it's a bit confusing to have spectrumRef refer sometimes to an
internal element, and other times an external entity, depending on the
context.  It is much simpler to be able to count on an 'objectRef' to
refer always to the 'id' of an internal <object>.

Could we use another attribute naming system for outside references?  

Perhaps 'spectrumExternalID' or just 'externalID'?

<acquisition number="0" externalID="FUNC2_SCAN0" sourceFileRef="SF1"/>



Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Fredrik Levander
Sent: Friday, February 22, 2008 4:16 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

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

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

[Kessner, D. E. <Dar...@cs...>]

I think it's a bit confusing to have spectrumRef refer sometimes to an
internal element, and other times an external entity, depending on the
context.  It is much simpler to be able to count on an 'objectRef' to
refer always to the 'id' of an internal <object>.

Could we use another attribute naming system for outside references?  

Perhaps 'spectrumExternalID' or just 'externalID'?

<acquisition number="0" externalID="FUNC2_SCAN0" sourceFileRef="SF1"/>



Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Fredrik Levander
Sent: Friday, February 22, 2008 4:16 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

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.

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

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

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
>   

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

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

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
>   

Re: [Psidev-ms-dev] use case: FT transient data

[Kessner, D. E. <Dar...@cs...>]

Actually, I agree with Matt here -- allowing a <binaryDataArray> to
override the <spectrum> 'arrayLength' is a simple solution to allow
these auxilliary arrays to have a different length from the main
m/z-intensity arrays.

Another issue with using two <spectrum> elements for a single scan is
that it has to be decided whether to duplicate scan metadata.  If the
metadata is not to be duplicated, it is essential to have
cross-references between the <spectrum> elements.


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, February 21, 2008 11:15 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] use case: FT transient data

It's a neat use case and would like to see it supported, but am I the 
only one that thinks this would be better as an auxiliary 
binaryDataArray element inside the same spectrum element? This 
implementation seems much more complicated and verbose than an 
equivalent implementation supported by binaryDataArray elements with 
varying length.

-Matt


Kessner, Darren E. wrote:
>
> Hi all,
>
>  
>
> Here is a <spectrumList> fragment to illustrate the encoding of FT 
> transient data, as requested by Eric during the conference call.
>
>  
>
> Some notes:
>
>  
>
> The <spectrum> attribute 'index' indicates the 0-based index into the 
> <spectrumList>.  There are two scans (17 and 18), each with an 
> m/z-intensity <spectrum> followed by a transient intensity 
> <spectrum>.  The Thermo scan number is encoded as <acquisition> 
> attribute 'number' as suggested by Randy.
>
>  
>
> I'm not sure whether we would want an additional CV term for 
> "transient intensity array", which is a time-based intensity array.  
> We would need a CV term for "acquisition time" to describe how long 
> the signal is being observed in the FT cell.  There would be some 
> other terms for metadata values associated with the transient as 
> well.  Note that there is no array for time points -- it is assumed 
> that the time spacing is regular, and calculated by the array size and

> "acquisition time" (this may be encoded differently by different
vendors).
>
>  
>
> I don't immediately see a way to pair the m/z spectrum with the 
> transient spectrum -- it would be nice to have a general <spectrumRef>

> from one <spectrum> to another (not just to a precursor), so that you 
> can find e.g. the transient data associated with an m/z spectrum or 
> vice versa.
>
>  
>
>  
>
> <spectrumList count="4">
>
>  
>
>     <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">
>
>         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn 
> spectrum" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="17" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z 
> array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>         <binaryDataArray encodedLength="5000">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000515" 
> name="intensity array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S17_transient" index="1" msLevel="1"
arrayLength="1234">
>
>         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn 
> transient spectrum ?" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="17" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="acquisition time" value=".768" unitAccession="MS:1000039"
>
>                             unitName="second"/>
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="transient intensity array ?" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S18" index="2" msLevel="1" arrayLength="1400">
>
>         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn 
> spectrum" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="18" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z 
> array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>         <binaryDataArray encodedLength="5000">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000515" 
> name="intensity array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S18_transient" index="3" msLevel="1"
arrayLength="2345">
>
>         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn 
> transient spectrum ?" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="18" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="acquisition time" value=".768" unitAccession="MS:1000039"
>
>                             unitName="second"/>
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="transient intensity array ?" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
> </spectrumList>
>
>  
>
>  
>
> 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
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.

Re: [Psidev-ms-dev] Transient data.

[Kessner, D. E. <Dar...@cs...>]

I haven't played around with compressing transient data, but I would
guess that Matt's hunch is right that there is some compression strategy
that would work, at least enough to offset the Base64 bloat.

The hope (possibly naive) is that instrument vendors like Thermo would
be willing to write out the transient data directly into mzML, so that
we don't have thousands of these transient data files sitting around.

But Christopher has a good point that a 10GB mzML file may be too
unwieldy to deal with. 


Darren



-----Original Message-----
From: psi...@li...
[mailto:psi...@li...] On Behalf Of
Matthew Chambers
Sent: Thursday, February 21, 2008 11:18 AM
To: Mass spectrometry standard development
Subject: Re: [Psidev-ms-dev] Transient data.

It might not respond well to zlib compression, but wouldn't this kind of

data be well-suited to any other kind of compression designed to 
capitalize on the relatively small differences between sequential 
elements? The mzXML ruler style compression, perhaps?

-Matt


Christopher Mason wrote:
> Darren-
>
> I missed the phone call but I'm curious about your use of mzML with 
> Fourier instruments / transients.
>
> What instrument were you contemplating using this with?  With what
kind 
> of transient sizes?  On an Orbitrap or LTQ-FT with 1-2 Mword
transients, 
> aren't we talking around 2-4 mbytes per transient even before base64 
> encoding?  In my experience, the don't compress very well either.
>
> This is the use case I've always worried about with any xml data
format.
>
> Thanks,
>
> -c
>
>   

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

Re: [Psidev-ms-dev] Transient data.

[Matthew C. <mat...@va...>]

It might not respond well to zlib compression, but wouldn't this kind of 
data be well-suited to any other kind of compression designed to 
capitalize on the relatively small differences between sequential 
elements? The mzXML ruler style compression, perhaps?

-Matt


Christopher Mason wrote:
> Darren-
>
> I missed the phone call but I'm curious about your use of mzML with 
> Fourier instruments / transients.
>
> What instrument were you contemplating using this with?  With what kind 
> of transient sizes?  On an Orbitrap or LTQ-FT with 1-2 Mword transients, 
> aren't we talking around 2-4 mbytes per transient even before base64 
> encoding?  In my experience, the don't compress very well either.
>
> This is the use case I've always worried about with any xml data format.
>
> Thanks,
>
> -c
>
>   

Re: [Psidev-ms-dev] use case: FT transient data

[Matthew C. <mat...@va...>]

It's a neat use case and would like to see it supported, but am I the 
only one that thinks this would be better as an auxiliary 
binaryDataArray element inside the same spectrum element? This 
implementation seems much more complicated and verbose than an 
equivalent implementation supported by binaryDataArray elements with 
varying length.

-Matt


Kessner, Darren E. wrote:
>
> Hi all,
>
>  
>
> Here is a <spectrumList> fragment to illustrate the encoding of FT 
> transient data, as requested by Eric during the conference call.
>
>  
>
> Some notes:
>
>  
>
> The <spectrum> attribute 'index' indicates the 0-based index into the 
> <spectrumList>.  There are two scans (17 and 18), each with an 
> m/z-intensity <spectrum> followed by a transient intensity 
> <spectrum>.  The Thermo scan number is encoded as <acquisition> 
> attribute 'number' as suggested by Randy.
>
>  
>
> I'm not sure whether we would want an additional CV term for 
> "transient intensity array", which is a time-based intensity array.  
> We would need a CV term for "acquisition time" to describe how long 
> the signal is being observed in the FT cell.  There would be some 
> other terms for metadata values associated with the transient as 
> well.  Note that there is no array for time points -- it is assumed 
> that the time spacing is regular, and calculated by the array size and 
> "acquisition time" (this may be encoded differently by different vendors).
>
>  
>
> I don't immediately see a way to pair the m/z spectrum with the 
> transient spectrum -- it would be nice to have a general <spectrumRef> 
> from one <spectrum> to another (not just to a precursor), so that you 
> can find e.g. the transient data associated with an m/z spectrum or 
> vice versa.
>
>  
>
>  
>
> <spectrumList count="4">
>
>  
>
>     <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">
>
>         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn 
> spectrum" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="17" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z 
> array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>         <binaryDataArray encodedLength="5000">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000515" 
> name="intensity array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S17_transient" index="1" msLevel="1" arrayLength="1234">
>
>         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn 
> transient spectrum ?" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="17" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="acquisition time" value=".768" unitAccession="MS:1000039"
>
>                             unitName="second"/>
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="transient intensity array ?" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S18" index="2" msLevel="1" arrayLength="1400">
>
>         <cvParam cvLabel="MS" accession="MS:1000580" name="MSn 
> spectrum" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="18" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000514" name="m/z 
> array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>         <binaryDataArray encodedLength="5000">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000515" 
> name="intensity array" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
>     <spectrum id="S18_transient" index="3" msLevel="1" arrayLength="2345">
>
>         <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn 
> transient spectrum ?" value=""/>
>
>         <spectrumDescription>
>
>             <acquisitionList count="1">
>
>                 <acquisition number="18" spectrumRef="?" 
> sourceFileRef="?"/>
>
>             </acquisitionList>
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="acquisition time" value=".768" unitAccession="MS:1000039"
>
>                             unitName="second"/>
>
>         </spectrumDescription>
>
>         <binaryDataArray encodedLength="5000" 
> dataProcessingRef="Xcalibur Processing">
>
>             ...
>
>             <cvParam cvLabel="MS" accession="MS:1000xxx" 
> name="transient intensity array ?" value=""/>
>
>             <binary>...</binary>
>
>         </binaryDataArray>
>
>     </spectrum>
>
>  
>
> </spectrumList>
>
>  
>
>  
>
> 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
>   

[Psidev-ms-dev] Transient data.

[Christopher M. <Mas...@ma...>]

Darren-

I missed the phone call but I'm curious about your use of mzML with
Fourier instruments / transients.

What instrument were you contemplating using this with?  With what kind
of transient sizes?  On an Orbitrap or LTQ-FT with 1-2 Mword transients,
aren't we talking around 2-4 mbytes per transient even before base64
encoding?  In my experience, the don't compress very well either.

This is the use case I've always worried about with any xml data format.

Thanks,

-c

[Psidev-ms-dev] Transient data.

[Christopher M. <cm...@cm...>]

Darren-

I missed the phone call but I'm curious about your use of mzML with 
Fourier instruments / transients.

What instrument were you contemplating using this with?  With what kind 
of transient sizes?  On an Orbitrap or LTQ-FT with 1-2 Mword transients, 
aren't we talking around 2-4 mbytes per transient even before base64 
encoding?  In my experience, the don't compress very well either.

This is the use case I've always worried about with any xml data format.

Thanks,

-c

[Psidev-ms-dev] use case: FT transient data

[Kessner, D. E. <Dar...@cs...>]

Hi all,

 

Here is a <spectrumList> fragment to illustrate the encoding of FT
transient data, as requested by Eric during the conference call.

 

Some notes:

 

The <spectrum> attribute 'index' indicates the 0-based index into the
<spectrumList>.  There are two scans (17 and 18), each with an
m/z-intensity <spectrum> followed by a transient intensity <spectrum>.
The Thermo scan number is encoded as <acquisition> attribute 'number' as
suggested by Randy.

 

I'm not sure whether we would want an additional CV term for "transient
intensity array", which is a time-based intensity array.  We would need
a CV term for "acquisition time" to describe how long the signal is
being observed in the FT cell.  There would be some other terms for
metadata values associated with the transient as well.  Note that there
is no array for time points -- it is assumed that the time spacing is
regular, and calculated by the array size and "acquisition time" (this
may be encoded differently by different vendors).

 

I don't immediately see a way to pair the m/z spectrum with the
transient spectrum -- it would be nice to have a general <spectrumRef>
from one <spectrum> to another (not just to a precursor), so that you
can find e.g. the transient data associated with an m/z spectrum or vice
versa.

 

 

<spectrumList count="4">

 

    <spectrum id="S17" index="0" msLevel="1" arrayLength="1313">

        <cvParam cvLabel="MS" accession="MS:1000580" name="MSn spectrum"
value=""/>

        <spectrumDescription>

            <acquisitionList count="1">

                <acquisition number="17" spectrumRef="?"
sourceFileRef="?"/>

            </acquisitionList>

            ...

        </spectrumDescription>

        <binaryDataArray encodedLength="5000"
dataProcessingRef="Xcalibur Processing">

            ...

            <cvParam cvLabel="MS" accession="MS:1000514" name="m/z
array" value=""/>

            <binary>...</binary>

        </binaryDataArray>

        <binaryDataArray encodedLength="5000">

            ...

            <cvParam cvLabel="MS" accession="MS:1000515" name="intensity
array" value=""/>

            <binary>...</binary>

        </binaryDataArray>

    </spectrum>

 

    <spectrum id="S17_transient" index="1" msLevel="1"
arrayLength="1234">

        <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn transient
spectrum ?" value=""/>

        <spectrumDescription>

            <acquisitionList count="1">

                <acquisition number="17" spectrumRef="?"
sourceFileRef="?"/>

            </acquisitionList>

            ...

            <cvParam cvLabel="MS" accession="MS:1000xxx"
name="acquisition time" value=".768" unitAccession="MS:1000039"

                            unitName="second"/>

        </spectrumDescription>

        <binaryDataArray encodedLength="5000"
dataProcessingRef="Xcalibur Processing">

            ...

            <cvParam cvLabel="MS" accession="MS:1000xxx" name="transient
intensity array ?" value=""/>

            <binary>...</binary>

        </binaryDataArray>

    </spectrum>

 

    <spectrum id="S18" index="2" msLevel="1" arrayLength="1400">

        <cvParam cvLabel="MS" accession="MS:1000580" name="MSn spectrum"
value=""/>

        <spectrumDescription>

            <acquisitionList count="1">

                <acquisition number="18" spectrumRef="?"
sourceFileRef="?"/>

            </acquisitionList>

            ...

        </spectrumDescription>

        <binaryDataArray encodedLength="5000"
dataProcessingRef="Xcalibur Processing">

            ...

            <cvParam cvLabel="MS" accession="MS:1000514" name="m/z
array" value=""/>

            <binary>...</binary>

        </binaryDataArray>

        <binaryDataArray encodedLength="5000">

            ...

            <cvParam cvLabel="MS" accession="MS:1000515" name="intensity
array" value=""/>

            <binary>...</binary>

        </binaryDataArray>

    </spectrum>

 

    <spectrum id="S18_transient" index="3" msLevel="1"
arrayLength="2345">

        <cvParam cvLabel="MS" accession="MS:1000xxx" name="MSn transient
spectrum ?" value=""/>

        <spectrumDescription>

            <acquisitionList count="1">

                <acquisition number="18" spectrumRef="?"
sourceFileRef="?"/>

            </acquisitionList>

            ...

            <cvParam cvLabel="MS" accession="MS:1000xxx"
name="acquisition time" value=".768" unitAccession="MS:1000039"

                            unitName="second"/>

        </spectrumDescription>

        <binaryDataArray encodedLength="5000"
dataProcessingRef="Xcalibur Processing">

            ...

            <cvParam cvLabel="MS" accession="MS:1000xxx" name="transient
intensity array ?" value=""/>

            <binary>...</binary>

        </binaryDataArray>

    </spectrum>

 

</spectrumList>

 

 

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.

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

[Kessner, D. E. <Dar...@cs...>]

My summary should have included the <acquisition> attribute 'number':

  id:  unique string identifier for <spectrum>
  spectrumRef:  refers to 'id' attribute of <spectrum>  // previous
  index:  0-based index into <spectrumList> // Randy
  acquisition::number:  vendor-specific identifier (e.g. Thermo scan
number) 


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.

Re: [Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

[Kessner, D. E. <Dar...@cs...>]

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.

Re: [Psidev-ms-dev] Content of location attribute in sourceFile element

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

Yes, at least it works in Java with three slashes but not with two. New 
java.io.File(URI) is happy and finds the file as

file:///F:/data/Exp01/tiny1.RAW


Fredrik


Rune Schjellerup Philosof wrote:
> I'm not certain. But don't you need one more slash file:/// to denote an 
> absolute path.
>
> --
> Rune
>
> Randy Julian wrote:
>   
>> In the example files sourceFile has the following content:
>>
>> <sourceFile id="1" name="tiny1.RAW" location="file://F:/data/Exp01">
>>
>> We noticed that standard “file open” type method calls fail when you 
>> include the protocol (“file://”). Has anyone else seen this behavior?
>>
>> Randy
>>
>> Randall K Julian, Jr. Ph.D.
>> President
>> Indigo BioSystems, Inc.
>> (317) 536-2736 x101
>> (317) 306-5447 mobile
>>
>> www.indigobio.com <http://www.indigobio.com/>
>>
>> NOTICE: This message may contain confidential or privileged 
>> information that is for the sole use of the intended recipient. Any 
>> unauthorized review, use, disclosure, copying or distribution is 
>> strictly prohibited. If you are not the intended recipient, please 
>> contact the sender by reply e-mail and destroy all copies of the 
>> original message.
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>   

Re: [Psidev-ms-dev] Content of location attribute in sourceFile element

[Rune S. P. <ru...@ph...>]

I'm not certain. But don't you need one more slash file:/// to denote an 
absolute path.

--
Rune

Randy Julian wrote:
>
> In the example files sourceFile has the following content:
>
> <sourceFile id="1" name="tiny1.RAW" location="file://F:/data/Exp01">
>
> We noticed that standard “file open” type method calls fail when you 
> include the protocol (“file://”). Has anyone else seen this behavior?
>
> Randy
>
> Randall K Julian, Jr. Ph.D.
> President
> Indigo BioSystems, Inc.
> (317) 536-2736 x101
> (317) 306-5447 mobile
>
> www.indigobio.com <http://www.indigobio.com/>
>
> NOTICE: This message may contain confidential or privileged 
> information that is for the sole use of the intended recipient. Any 
> unauthorized review, use, disclosure, copying or distribution is 
> strictly prohibited. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the 
> original message.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

[Psidev-ms-dev] Content of location attribute in sourceFile element

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

In the example files sourceFile has the following content:

 

<sourceFile id="1" name="tiny1.RAW" location="file://F:/data/Exp01">

 

We noticed that standard "file open" type method calls fail when you
include the protocol ("file://").  Has anyone else seen this behavior?

 

Randy

 

Randall K Julian, Jr. Ph.D.
President
Indigo BioSystems,  Inc.
(317) 536-2736 x101
(317) 306-5447 mobile

www.indigobio.com <http://www.indigobio.com/> 

NOTICE: This message may contain confidential or privileged information
that is for the sole use of the intended recipient. Any unauthorized
review, use, disclosure, copying or distribution is strictly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.

 

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

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

Hi, I just tried this out, and it is no problem to have multiple 
attributes named 'id' for different elements which all are of type 
xs:ID. However, the content of all xs:ID type attributes need to be 
unique within the file, regardless of the name of the attributes. I 
changed the data type of the id attributes to xs:ID in a test schema, 
and changed the dataProcessingRef, sourceFileRef and some more to be of 
type xs:IDREF, where referencing should be within the file. The standard 
java schema validation really does check that the referenced ids are 
there and that the ids are unique etc.

I agree that it would be good to change the data types of the ids of the 
referenceable elements, so that validation and referencing between files 
becomes easier. It is not a problem to assign unique IDs to files, 
samples and spectra. A simple solution is to have sourceFiles with ids 
SF1, SF2 etc and spectra as S1,S2...But anything can be used as the ids 
are unique.
I've uploaded a new schema and the modified example file, in case anyone 
else wants to play with it.
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/Edited_mzML0.99.9_SNAPSHOT.xsd
http://trac.thep.lu.se/trac/fp6-prodac/browser/trunk/mzML/FF_070504_MSMS_5B_edited.mzML
I will remove the schema within  a day or two to avoid mixing up with 
the real schema snapshots that Lennart are providing

Some fields which I wonder about are the acquisition spectrumRef and 
sourceFileRefs. I guess referencing to external URIs could be allowed 
there. In that case: should the spectrumRef be put to the complete URI 
of the spectrum, or just the spectrum ID / scan number if raw data file? 
Maybe specrumRef should be type xs:String and sourceFileRef xs:anyURI.

/Fredrik

Matthew Chambers wrote:
> Very good point Angel. This is a problem with the use of the id 
> attribute everywhere. Can Xlink specify the attribute name as something 
> other than "id" if, for example, we renamed the id attribute for each 
> type to something unique to that type? E.g. <spectrum 
> spectrumId="foo.1.1.1.dta" />
> I know it's not pretty and it would go against the shift away from 
> redundant strings in attribute names, but it may be necessary in this case.
>
> -Matt
>
> Angel Pizarro wrote:
>   
>> also note the the ID attribute instances must be unique across all 
>> attributes that are of type ID, regardless of containign element. In 
>> other words <foo id="1" /> and <bar id="1" /> would violate this if 
>> both attributes named "id" were of type xsd:ID
>>
>> -angel
>>
>>
>> On Wed, Feb 20, 2008 at 9:40 AM, Angel Pizarro 
>> <an...@ma... <mailto:an...@ma...>> wrote:
>>
>>     As I understand it:
>>
>>     ID & IDREF are used for internal references in single documents.
>>
>>     XLinks are used to reference within and across documents.
>>
>>     analysisXML can use XLink  to reference a spectra pretty easily if
>>     you use ID as the document-unique identifier type.
>>
>>     -angel
>>
>>
>>     On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers
>>     <mat...@va...
>>     <mailto:mat...@va...>> wrote:
>>
>>         Yes, xs:ID definitely works as a fragment identifier, it's
>>         what XHTML
>>         and XML use for the core "id" attribute. :)
>>
>>         A cross-file reference is composed of a document identifier
>>         (not sure
>>         what form this can take, so I assume anyURI) and an optional
>>         fragment
>>         identifier:
>>         "file://foo.mzML#foo.1.1.1.dta" would reference the element with
>>         id="foo.1.1.1.dta" in foo.mzML
>>
>>         -Matt
>>
>>
>>         Angel Pizarro wrote:
>>         > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian
>>         <rkj...@in... <mailto:rkj...@in...>
>>         > <mailto:rkj...@in...
>>         <mailto:rkj...@in...>>> wrote:
>>         >
>>         >     Does the xs:ID constraint solve this problem?
>>         >
>>         >
>>         > maybe since  I think we had agreed that mzML REFs are
>>         within-file only ?
>>         >
>>         >
>>         >     -----Original Message-----
>>         >     From: psi...@li...
>>         <mailto:psi...@li...>
>>         >     <mailto:psi...@li...
>>         <mailto:psi...@li...>>
>>         >     [mailto:psi...@li...
>>         <mailto:psi...@li...>
>>         >     <mailto:psi...@li...
>>         <mailto:psi...@li...>>] On
>>         Behalf Of
>>         >     Matt
>>         >     Chambers
>>         >     Sent: Tuesday, February 19, 2008 10:34 PM
>>         >     To: Mass spectrometry standard development
>>         >     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>>         >
>>         >     After a little more thought, absolute instances of
>>         xs:anyURI will not
>>         >     always work as a fragment identifier. If a spectrum's id
>>         attribute was
>>         >     xs:anyURI in file "foo.mzML":
>>         >     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a
>>         valid (absolute)
>>         >     xs:anyURI -->
>>         >
>>         >     And in something like pepXML or analysisXML:
>>         >     <spectrumQuery
>>         spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" />
>>         >     <!-- not a valid xs:anyURI! -->
>>         >
>>         >     Unless I'm missing something, using xs:anyURI for
>>         fragment identifiers
>>         >     would actually make the schema less safe. Valid mzML ids
>>         would be
>>         >     potentially unusable in an external URI unless
>>         URL-encoded, which
>>         >     would
>>         >     defeat the point of using xs:anyURI in the first place.
>>         >
>>         >     -Matt
>>         >
>>         >
>>         >     Randy Julian wrote:
>>         >     > All we are trying to achieve with the anyURI is safety
>>         for use
>>         >     within
>>         >     a
>>         >     > URI.  Any xlink-safe way of doing this will work.  So
>>         if xs:ID is
>>         >     > supported better by the validating parsers, it would
>>         do what we
>>         >     want.
>>         >     >
>>         >     > -----Original Message-----
>>         >     > From: psi...@li...
>>         <mailto:psi...@li...>
>>         >     <mailto:psi...@li...
>>         <mailto:psi...@li...>>
>>         >     > [mailto:psi...@li...
>>         <mailto:psi...@li...>
>>         >     <mailto:psi...@li...
>>         <mailto:psi...@li...>>] On
>>         Behalf Of
>>         >     > Matthew Chambers
>>         >     > Sent: Tuesday, February 19, 2008 4:25 PM
>>         >     > To: Mass spectrometry standard development
>>         >     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>>         >     >
>>         >     > You are right Randy, we were forgetting about relative
>>         URIs
>>         >     which can
>>         >     > simply refer to a resource's name with no path at all
>>         ("1" is
>>         >     certainly
>>         >     > a valid resource name). However, I think anyURI is
>>         still a bad idea
>>         >     for
>>         >     > any attribute which is not intended to be able to
>>         refer to something
>>         >     in
>>         >     > a remote location (e.g. not in the current file). The
>>         "id" attribute
>>         >     in
>>         >     > the XML namespace has type "xs:ID" which has semantics
>>         more
>>         >     along the
>>         >     > lines of what I think you want. If I understand the
>>         use case
>>         >     correctly,
>>         >     > it is desirable to be able to link to certain mzML
>>         elements from
>>         >     > external documents with a URI, like:
>>         >     > file://data_source.mzML#s555
>>         >     > This is an example absolute URI reference to a
>>         spectrum in a file at
>>         >     > "data_source.mzML" where the spectrum's id attribute
>>         is "s555". It
>>         >     > wouldn't make sense for the id itself to be a URI,
>>         although the
>>         >     > reference to it can (and should) be.
>>         >     >
>>         >     > So:
>>         >     > 1) for id attributes which can be referred to
>>         externally or
>>         >     internally,
>>         >     > use the type "xs:ID"
>>         >     > 2) for references to external or internal resources by
>>         their id
>>         >     > attribute, use the type "xs:anyURI"
>>         >     >
>>         >     > This would have the problem of the Xerxes C parser not
>>         validating
>>         >     > relative URIs correctly, but that seems to be wrong on
>>         their
>>         >     part. :/
>>         >     > Anyway, users of Xerxes C can turn off the validation
>>         feature to
>>         >     work
>>         >     > around it.
>>         >     >
>>         >     > Also, Ref attributes in mzML could use anyURI for
>>         consistency
>>         >     reasons
>>         >     > even though we don't currently know of a use case
>>         where such
>>         >     references
>>         >     > would be made to an external file.
>>         >     >
>>         >     > -Matt
>>         >     >
>>         >     >
>>         >     > Randy Julian wrote:
>>         >     >
>>         >     >> Per our conversation today, the relevant
>>         specification is RFC-2396:
>>         >     >>
>>         >     >> http://www.ietf.org/rfc/rfc2396.txt
>>         >     >>
>>         >     >> Section 5 talks about relative URIs. They do not need to
>>         >     include the
>>         >     >> protocol and their syntax would include all integers:
>>         >     >>
>>         >     >> The syntax for relative URI takes advantage of the
>>         <hier_part>
>>         >     syntax
>>         >     >>    of <absoluteURI> (Section 3) in order to express a
>>         reference
>>         >     that
>>         >     >>
>>         >     > is
>>         >     >
>>         >     >>    relative to the namespace of another hierarchical URI.
>>         >     >>
>>         >     >>       relativeURI   = ( net_path | abs_path |
>>         rel_path ) [ "?"
>>         >     query
>>         >     ]
>>         >     >>
>>         >     >>    A relative reference beginning with two slash
>>         characters is
>>         >     termed
>>         >     >>
>>         >     > a
>>         >     >
>>         >     >>    network-path reference, as defined by <net_path>
>>         in Section 3.
>>         >     >>
>>         >     > Such
>>         >     >
>>         >     >>    references are rarely used.
>>         >     >>
>>         >     >>    A relative reference beginning with a single slash
>>         character is
>>         >     >>    termed an absolute-path reference, as defined by
>>         <abs_path> in
>>         >     >>    Section 3.
>>         >     >>
>>         >     >>    A relative reference that does not begin with a
>>         scheme name or a
>>         >     >>    slash character is termed a relative-path reference.
>>         >     >>
>>         >     >>       rel_path      = rel_segment [ abs_path ]
>>         >     >>
>>         >     >>       rel_segment   = 1*( unreserved | escaped | ";"
>>         | "@" | "&" |
>>         >     "="
>>         >     >>
>>         >     > | "+" | "$" | "," )
>>         >     >
>>         >     >> That means that you don't need the net_path part or the
>>         >     abs_path part
>>         >
>>         >     >> but can use the rel_path part alone. The rel_path
>>         part can have
>>         >     only
>>         >     >> the rel_segment part which is required to have one or
>>         more
>>         >     unreserved
>>         >
>>         >     >> characters (includes all the integers) and/or any of
>>         the above
>>         >     special
>>         >     >>
>>         >     >
>>         >     >
>>         >     >> characters or escaped characters.
>>         >     >>
>>         >     >> The point of using it in mzML for IDs is that you can
>>         be assured of
>>         >     it
>>         >     >>
>>         >     >
>>         >     >
>>         >     >> being a valid relative path when extended by all the
>>         other
>>         >     components
>>         >
>>         >     >> needed to navigate to a referenced document
>>         (protocol, absolute
>>         >     path,
>>         >
>>         >     >> etc.).
>>         >     >>
>>         >     >> We can achieve this by convention by saying in the
>>         mzML spec
>>         >     doc (and
>>         >
>>         >     >> possibly putting the required pattern in the schema),
>>         that the
>>         >     string
>>         >
>>         >     >> for ID must conform to RFC-2396.
>>         >     >>
>>         >     >> Randy
>>         >     >>
>>         >     >> Randall K Julian, Jr. Ph.D.
>>         >     >> President
>>         >     >> Indigo BioSystems, Inc.
>>         >     >> (317) 536-2736 x101
>>         >     >> (317) 306-5447 mobile
>>         >     >>
>>         >     >> www.indigobio.com <http://www.indigobio.com>
>>         <http://www.indigobio.com>
>>         >     <http://www.indigobio.com/>
>>         >     >>
>>         >     >
>>         >
>>         > v
>>         >
>>
>>
>>         -------------------------------------------------------------------------
>>         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...
>>         <mailto:Psi...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>
>>
>>
>>
>>     -- 
>>     Angel Pizarro
>>     Director, ITMAT Bioinformatics Facility
>>     806 Biological Research Building
>>     421 Curie Blvd.
>>     Philadelphia, PA 19104-6160
>>     215-573-3736
>>
>>
>>
>>
>> -- 
>> Angel Pizarro
>> Director, ITMAT Bioinformatics Facility
>> 806 Biological Research Building
>> 421 Curie Blvd.
>> Philadelphia, PA 19104-6160
>> 215-573-3736
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>   

[Psidev-ms-dev] Schema SNAPSHOT update Thursday 21 Feb 2008

[Lennart M. <len...@eb...>]

Dear PSI-MS Enthousiasts,


A new snapshot version that should incorporate the most recent things 
disussed on the mailing list.

Changelog:
http://www.ebi.ac.uk/~lmartens/mzML/20080221_changelog.txt

Schema link:
http://www.ebi.ac.uk/~lmartens/mzML/20080221_mzML0.99.9_SNAPSHOT.xsd

Example instance doc:
http://www.ebi.ac.uk/~lmartens/mzML/20080221_example_mzML0.99.9_SNAPSHOT.mzML

Fredrik's example doc, somewhat updated (binaryArrayLength moved to 
spectrum, acquisitionNumber to number) and bound to the latest schema:
http://www.ebi.ac.uk/~lmartens/mzML/20080221_FF_070504_MSMS_5B_edited.mzML


Enjoy :).


Cheers,

lnnrt.

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

[Angel P. <an...@ma...>]

On Wed, Feb 20, 2008 at 10:33 AM, Matthew Chambers <
mat...@va...> wrote:

> Very good point Angel. This is a problem with the use of the id
> attribute everywhere. Can Xlink specify the attribute name as something
> other than "id" if, for example, we renamed the id attribute for each
> type to something unique to that type? E.g. <spectrum
> spectrumId="foo.1.1.1.dta" />
>

to clarify when I say XLink I mean XLink + XPointer. These have a short-hand
URI reference to an element with an attribute named "id"  and is of the form
of "<URL or URI base>#id_value". Also note that (i believe but have not dug
too deeply into this) the data type of said attribute is not important, only
the name of "id" for the shorthand syntax to work.

The full Xpointer reference just piggy backs off of XPath expressions to
navigate the DOM model. So for your suggestion the XLink/XPointer ref value
would look like this from analysisXML:

<analysisXML>
...
<spectrum_reference xmllink:type="simple" xlink:href="
http://sbeams.org/exp/1/mzml/3.xml#pointer(spectrumId('foo.1.1.dta'))" />
...

or something like that. I don't have time to provide a proper working
example. Also to note that I could use xpointer +xpath to get any element
regardless of it having an id attribute.

<spectrum_reference xmllink:type="simple" xlink:href="
http://sbeams.org/exp/1/mzml/3.xml#pointer(../spectrumId[3])" />

Again not a rigourous example, as the result of this XPATH is actually a
set, but the point is that analysisXML will adapt to mzML and we should not
worry about that aspect.

-angel


I know it's not pretty and it would go against the shift away from
> redundant strings in attribute names, but it may be necessary in this
> case.
>
> -Matt
>
> Angel Pizarro wrote:
> > also note the the ID attribute instances must be unique across all
> > attributes that are of type ID, regardless of containign element. In
> > other words <foo id="1" /> and <bar id="1" /> would violate this if
> > both attributes named "id" were of type xsd:ID
> >
> > -angel
> >
> >
> > On Wed, Feb 20, 2008 at 9:40 AM, Angel Pizarro
> > <an...@ma... <mailto:an...@ma...>> wrote:
> >
> >     As I understand it:
> >
> >     ID & IDREF are used for internal references in single documents.
> >
> >     XLinks are used to reference within and across documents.
> >
> >     analysisXML can use XLink  to reference a spectra pretty easily if
> >     you use ID as the document-unique identifier type.
> >
> >     -angel
> >
> >
> >     On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers
> >     <mat...@va...
> >     <mailto:mat...@va...>> wrote:
> >
> >         Yes, xs:ID definitely works as a fragment identifier, it's
> >         what XHTML
> >         and XML use for the core "id" attribute. :)
> >
> >         A cross-file reference is composed of a document identifier
> >         (not sure
> >         what form this can take, so I assume anyURI) and an optional
> >         fragment
> >         identifier:
> >         "file://foo.mzML#foo.1.1.1.dta" would reference the element with
> >         id="foo.1.1.1.dta" in foo.mzML
> >
> >         -Matt
> >
> >
> >         Angel Pizarro wrote:
> >         > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian
> >         <rkj...@in... <mailto:rkj...@in...>
> >         > <mailto:rkj...@in...
> >         <mailto:rkj...@in...>>> wrote:
> >         >
> >         >     Does the xs:ID constraint solve this problem?
> >         >
> >         >
> >         > maybe since  I think we had agreed that mzML REFs are
> >         within-file only ?
> >         >
> >         >
> >         >     -----Original Message-----
> >         >     From: psi...@li...
> >         <mailto:psi...@li...>
> >         >     <mailto:psi...@li...
> >         <mailto:psi...@li...>>
> >         >     [mailto:psi...@li...
> >         <mailto:psi...@li...>
> >         >     <mailto:psi...@li...
> >         <mailto:psi...@li...>>] On
> >         Behalf Of
> >         >     Matt
> >         >     Chambers
> >         >     Sent: Tuesday, February 19, 2008 10:34 PM
> >         >     To: Mass spectrometry standard development
> >         >     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> >         >
> >         >     After a little more thought, absolute instances of
> >         xs:anyURI will not
> >         >     always work as a fragment identifier. If a spectrum's id
> >         attribute was
> >         >     xs:anyURI in file "foo.mzML":
> >         >     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a
> >         valid (absolute)
> >         >     xs:anyURI -->
> >         >
> >         >     And in something like pepXML or analysisXML:
> >         >     <spectrumQuery
> >         spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" />
> >         >     <!-- not a valid xs:anyURI! -->
> >         >
> >         >     Unless I'm missing something, using xs:anyURI for
> >         fragment identifiers
> >         >     would actually make the schema less safe. Valid mzML ids
> >         would be
> >         >     potentially unusable in an external URI unless
> >         URL-encoded, which
> >         >     would
> >         >     defeat the point of using xs:anyURI in the first place.
> >         >
> >         >     -Matt
> >         >
> >         >
> >         >     Randy Julian wrote:
> >         >     > All we are trying to achieve with the anyURI is safety
> >         for use
> >         >     within
> >         >     a
> >         >     > URI.  Any xlink-safe way of doing this will work.  So
> >         if xs:ID is
> >         >     > supported better by the validating parsers, it would
> >         do what we
> >         >     want.
> >         >     >
> >         >     > -----Original Message-----
> >         >     > From: psi...@li...
> >         <mailto:psi...@li...>
> >         >     <mailto:psi...@li...
> >         <mailto:psi...@li...>>
> >         >     > [mailto:psi...@li...
> >         <mailto:psi...@li...>
> >         >     <mailto:psi...@li...
> >         <mailto:psi...@li...>>] On
> >         Behalf Of
> >         >     > Matthew Chambers
> >         >     > Sent: Tuesday, February 19, 2008 4:25 PM
> >         >     > To: Mass spectrometry standard development
> >         >     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> >         >     >
> >         >     > You are right Randy, we were forgetting about relative
> >         URIs
> >         >     which can
> >         >     > simply refer to a resource's name with no path at all
> >         ("1" is
> >         >     certainly
> >         >     > a valid resource name). However, I think anyURI is
> >         still a bad idea
> >         >     for
> >         >     > any attribute which is not intended to be able to
> >         refer to something
> >         >     in
> >         >     > a remote location (e.g. not in the current file). The
> >         "id" attribute
> >         >     in
> >         >     > the XML namespace has type "xs:ID" which has semantics
> >         more
> >         >     along the
> >         >     > lines of what I think you want. If I understand the
> >         use case
> >         >     correctly,
> >         >     > it is desirable to be able to link to certain mzML
> >         elements from
> >         >     > external documents with a URI, like:
> >         >     > file://data_source.mzML#s555
> >         >     > This is an example absolute URI reference to a
> >         spectrum in a file at
> >         >     > "data_source.mzML" where the spectrum's id attribute
> >         is "s555". It
> >         >     > wouldn't make sense for the id itself to be a URI,
> >         although the
> >         >     > reference to it can (and should) be.
> >         >     >
> >         >     > So:
> >         >     > 1) for id attributes which can be referred to
> >         externally or
> >         >     internally,
> >         >     > use the type "xs:ID"
> >         >     > 2) for references to external or internal resources by
> >         their id
> >         >     > attribute, use the type "xs:anyURI"
> >         >     >
> >         >     > This would have the problem of the Xerxes C parser not
> >         validating
> >         >     > relative URIs correctly, but that seems to be wrong on
> >         their
> >         >     part. :/
> >         >     > Anyway, users of Xerxes C can turn off the validation
> >         feature to
> >         >     work
> >         >     > around it.
> >         >     >
> >         >     > Also, Ref attributes in mzML could use anyURI for
> >         consistency
> >         >     reasons
> >         >     > even though we don't currently know of a use case
> >         where such
> >         >     references
> >         >     > would be made to an external file.
> >         >     >
> >         >     > -Matt
> >         >     >
> >         >     >
> >         >     > Randy Julian wrote:
> >         >     >
> >         >     >> Per our conversation today, the relevant
> >         specification is RFC-2396:
> >         >     >>
> >         >     >> http://www.ietf.org/rfc/rfc2396.txt
> >         >     >>
> >         >     >> Section 5 talks about relative URIs. They do not need
> to
> >         >     include the
> >         >     >> protocol and their syntax would include all integers:
> >         >     >>
> >         >     >> The syntax for relative URI takes advantage of the
> >         <hier_part>
> >         >     syntax
> >         >     >>    of <absoluteURI> (Section 3) in order to express a
> >         reference
> >         >     that
> >         >     >>
> >         >     > is
> >         >     >
> >         >     >>    relative to the namespace of another hierarchical
> URI.
> >         >     >>
> >         >     >>       relativeURI   = ( net_path | abs_path |
> >         rel_path ) [ "?"
> >         >     query
> >         >     ]
> >         >     >>
> >         >     >>    A relative reference beginning with two slash
> >         characters is
> >         >     termed
> >         >     >>
> >         >     > a
> >         >     >
> >         >     >>    network-path reference, as defined by <net_path>
> >         in Section 3.
> >         >     >>
> >         >     > Such
> >         >     >
> >         >     >>    references are rarely used.
> >         >     >>
> >         >     >>    A relative reference beginning with a single slash
> >         character is
> >         >     >>    termed an absolute-path reference, as defined by
> >         <abs_path> in
> >         >     >>    Section 3.
> >         >     >>
> >         >     >>    A relative reference that does not begin with a
> >         scheme name or a
> >         >     >>    slash character is termed a relative-path reference.
> >         >     >>
> >         >     >>       rel_path      = rel_segment [ abs_path ]
> >         >     >>
> >         >     >>       rel_segment   = 1*( unreserved | escaped | ";"
> >         | "@" | "&" |
> >         >     "="
> >         >     >>
> >         >     > | "+" | "$" | "," )
> >         >     >
> >         >     >> That means that you don't need the net_path part or the
> >         >     abs_path part
> >         >
> >         >     >> but can use the rel_path part alone. The rel_path
> >         part can have
> >         >     only
> >         >     >> the rel_segment part which is required to have one or
> >         more
> >         >     unreserved
> >         >
> >         >     >> characters (includes all the integers) and/or any of
> >         the above
> >         >     special
> >         >     >>
> >         >     >
> >         >     >
> >         >     >> characters or escaped characters.
> >         >     >>
> >         >     >> The point of using it in mzML for IDs is that you can
> >         be assured of
> >         >     it
> >         >     >>
> >         >     >
> >         >     >
> >         >     >> being a valid relative path when extended by all the
> >         other
> >         >     components
> >         >
> >         >     >> needed to navigate to a referenced document
> >         (protocol, absolute
> >         >     path,
> >         >
> >         >     >> etc.).
> >         >     >>
> >         >     >> We can achieve this by convention by saying in the
> >         mzML spec
> >         >     doc (and
> >         >
> >         >     >> possibly putting the required pattern in the schema),
> >         that the
> >         >     string
> >         >
> >         >     >> for ID must conform to RFC-2396.
> >         >     >>
> >         >     >> Randy
> >         >     >>
> >         >     >> Randall K Julian, Jr. Ph.D.
> >         >     >> President
> >         >     >> Indigo BioSystems, Inc.
> >         >     >> (317) 536-2736 x101
> >         >     >> (317) 306-5447 mobile
> >         >     >>
> >         >     >> www.indigobio.com <http://www.indigobio.com>
> >         <http://www.indigobio.com>
> >         >     <http://www.indigobio.com/>
> >         >     >>
> >         >     >
> >         >
> >         > v
> >         >
> >
> >
> >
> -------------------------------------------------------------------------
> >         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...
> >         <mailto:Psi...@li...>
> >         https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >
> >
> >
> >
> >     --
> >     Angel Pizarro
> >     Director, ITMAT Bioinformatics Facility
> >     806 Biological Research Building
> >     421 Curie Blvd.
> >     Philadelphia, PA 19104-6160
> >     215-573-3736
> >
> >
> >
> >
> > --
> > Angel Pizarro
> > Director, ITMAT Bioinformatics Facility
> > 806 Biological Research Building
> > 421 Curie Blvd.
> > Philadelphia, PA 19104-6160
> > 215-573-3736
> > ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > 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
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

[Matthew C. <mat...@va...>]

Very good point Angel. This is a problem with the use of the id 
attribute everywhere. Can Xlink specify the attribute name as something 
other than "id" if, for example, we renamed the id attribute for each 
type to something unique to that type? E.g. <spectrum 
spectrumId="foo.1.1.1.dta" />
I know it's not pretty and it would go against the shift away from 
redundant strings in attribute names, but it may be necessary in this case.

-Matt

Angel Pizarro wrote:
> also note the the ID attribute instances must be unique across all 
> attributes that are of type ID, regardless of containign element. In 
> other words <foo id="1" /> and <bar id="1" /> would violate this if 
> both attributes named "id" were of type xsd:ID
>
> -angel
>
>
> On Wed, Feb 20, 2008 at 9:40 AM, Angel Pizarro 
> <an...@ma... <mailto:an...@ma...>> wrote:
>
>     As I understand it:
>
>     ID & IDREF are used for internal references in single documents.
>
>     XLinks are used to reference within and across documents.
>
>     analysisXML can use XLink  to reference a spectra pretty easily if
>     you use ID as the document-unique identifier type.
>
>     -angel
>
>
>     On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers
>     <mat...@va...
>     <mailto:mat...@va...>> wrote:
>
>         Yes, xs:ID definitely works as a fragment identifier, it's
>         what XHTML
>         and XML use for the core "id" attribute. :)
>
>         A cross-file reference is composed of a document identifier
>         (not sure
>         what form this can take, so I assume anyURI) and an optional
>         fragment
>         identifier:
>         "file://foo.mzML#foo.1.1.1.dta" would reference the element with
>         id="foo.1.1.1.dta" in foo.mzML
>
>         -Matt
>
>
>         Angel Pizarro wrote:
>         > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian
>         <rkj...@in... <mailto:rkj...@in...>
>         > <mailto:rkj...@in...
>         <mailto:rkj...@in...>>> wrote:
>         >
>         >     Does the xs:ID constraint solve this problem?
>         >
>         >
>         > maybe since  I think we had agreed that mzML REFs are
>         within-file only ?
>         >
>         >
>         >     -----Original Message-----
>         >     From: psi...@li...
>         <mailto:psi...@li...>
>         >     <mailto:psi...@li...
>         <mailto:psi...@li...>>
>         >     [mailto:psi...@li...
>         <mailto:psi...@li...>
>         >     <mailto:psi...@li...
>         <mailto:psi...@li...>>] On
>         Behalf Of
>         >     Matt
>         >     Chambers
>         >     Sent: Tuesday, February 19, 2008 10:34 PM
>         >     To: Mass spectrometry standard development
>         >     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>         >
>         >     After a little more thought, absolute instances of
>         xs:anyURI will not
>         >     always work as a fragment identifier. If a spectrum's id
>         attribute was
>         >     xs:anyURI in file "foo.mzML":
>         >     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a
>         valid (absolute)
>         >     xs:anyURI -->
>         >
>         >     And in something like pepXML or analysisXML:
>         >     <spectrumQuery
>         spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" />
>         >     <!-- not a valid xs:anyURI! -->
>         >
>         >     Unless I'm missing something, using xs:anyURI for
>         fragment identifiers
>         >     would actually make the schema less safe. Valid mzML ids
>         would be
>         >     potentially unusable in an external URI unless
>         URL-encoded, which
>         >     would
>         >     defeat the point of using xs:anyURI in the first place.
>         >
>         >     -Matt
>         >
>         >
>         >     Randy Julian wrote:
>         >     > All we are trying to achieve with the anyURI is safety
>         for use
>         >     within
>         >     a
>         >     > URI.  Any xlink-safe way of doing this will work.  So
>         if xs:ID is
>         >     > supported better by the validating parsers, it would
>         do what we
>         >     want.
>         >     >
>         >     > -----Original Message-----
>         >     > From: psi...@li...
>         <mailto:psi...@li...>
>         >     <mailto:psi...@li...
>         <mailto:psi...@li...>>
>         >     > [mailto:psi...@li...
>         <mailto:psi...@li...>
>         >     <mailto:psi...@li...
>         <mailto:psi...@li...>>] On
>         Behalf Of
>         >     > Matthew Chambers
>         >     > Sent: Tuesday, February 19, 2008 4:25 PM
>         >     > To: Mass spectrometry standard development
>         >     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>         >     >
>         >     > You are right Randy, we were forgetting about relative
>         URIs
>         >     which can
>         >     > simply refer to a resource's name with no path at all
>         ("1" is
>         >     certainly
>         >     > a valid resource name). However, I think anyURI is
>         still a bad idea
>         >     for
>         >     > any attribute which is not intended to be able to
>         refer to something
>         >     in
>         >     > a remote location (e.g. not in the current file). The
>         "id" attribute
>         >     in
>         >     > the XML namespace has type "xs:ID" which has semantics
>         more
>         >     along the
>         >     > lines of what I think you want. If I understand the
>         use case
>         >     correctly,
>         >     > it is desirable to be able to link to certain mzML
>         elements from
>         >     > external documents with a URI, like:
>         >     > file://data_source.mzML#s555
>         >     > This is an example absolute URI reference to a
>         spectrum in a file at
>         >     > "data_source.mzML" where the spectrum's id attribute
>         is "s555". It
>         >     > wouldn't make sense for the id itself to be a URI,
>         although the
>         >     > reference to it can (and should) be.
>         >     >
>         >     > So:
>         >     > 1) for id attributes which can be referred to
>         externally or
>         >     internally,
>         >     > use the type "xs:ID"
>         >     > 2) for references to external or internal resources by
>         their id
>         >     > attribute, use the type "xs:anyURI"
>         >     >
>         >     > This would have the problem of the Xerxes C parser not
>         validating
>         >     > relative URIs correctly, but that seems to be wrong on
>         their
>         >     part. :/
>         >     > Anyway, users of Xerxes C can turn off the validation
>         feature to
>         >     work
>         >     > around it.
>         >     >
>         >     > Also, Ref attributes in mzML could use anyURI for
>         consistency
>         >     reasons
>         >     > even though we don't currently know of a use case
>         where such
>         >     references
>         >     > would be made to an external file.
>         >     >
>         >     > -Matt
>         >     >
>         >     >
>         >     > Randy Julian wrote:
>         >     >
>         >     >> Per our conversation today, the relevant
>         specification is RFC-2396:
>         >     >>
>         >     >> http://www.ietf.org/rfc/rfc2396.txt
>         >     >>
>         >     >> Section 5 talks about relative URIs. They do not need to
>         >     include the
>         >     >> protocol and their syntax would include all integers:
>         >     >>
>         >     >> The syntax for relative URI takes advantage of the
>         <hier_part>
>         >     syntax
>         >     >>    of <absoluteURI> (Section 3) in order to express a
>         reference
>         >     that
>         >     >>
>         >     > is
>         >     >
>         >     >>    relative to the namespace of another hierarchical URI.
>         >     >>
>         >     >>       relativeURI   = ( net_path | abs_path |
>         rel_path ) [ "?"
>         >     query
>         >     ]
>         >     >>
>         >     >>    A relative reference beginning with two slash
>         characters is
>         >     termed
>         >     >>
>         >     > a
>         >     >
>         >     >>    network-path reference, as defined by <net_path>
>         in Section 3.
>         >     >>
>         >     > Such
>         >     >
>         >     >>    references are rarely used.
>         >     >>
>         >     >>    A relative reference beginning with a single slash
>         character is
>         >     >>    termed an absolute-path reference, as defined by
>         <abs_path> in
>         >     >>    Section 3.
>         >     >>
>         >     >>    A relative reference that does not begin with a
>         scheme name or a
>         >     >>    slash character is termed a relative-path reference.
>         >     >>
>         >     >>       rel_path      = rel_segment [ abs_path ]
>         >     >>
>         >     >>       rel_segment   = 1*( unreserved | escaped | ";"
>         | "@" | "&" |
>         >     "="
>         >     >>
>         >     > | "+" | "$" | "," )
>         >     >
>         >     >> That means that you don't need the net_path part or the
>         >     abs_path part
>         >
>         >     >> but can use the rel_path part alone. The rel_path
>         part can have
>         >     only
>         >     >> the rel_segment part which is required to have one or
>         more
>         >     unreserved
>         >
>         >     >> characters (includes all the integers) and/or any of
>         the above
>         >     special
>         >     >>
>         >     >
>         >     >
>         >     >> characters or escaped characters.
>         >     >>
>         >     >> The point of using it in mzML for IDs is that you can
>         be assured of
>         >     it
>         >     >>
>         >     >
>         >     >
>         >     >> being a valid relative path when extended by all the
>         other
>         >     components
>         >
>         >     >> needed to navigate to a referenced document
>         (protocol, absolute
>         >     path,
>         >
>         >     >> etc.).
>         >     >>
>         >     >> We can achieve this by convention by saying in the
>         mzML spec
>         >     doc (and
>         >
>         >     >> possibly putting the required pattern in the schema),
>         that the
>         >     string
>         >
>         >     >> for ID must conform to RFC-2396.
>         >     >>
>         >     >> Randy
>         >     >>
>         >     >> Randall K Julian, Jr. Ph.D.
>         >     >> President
>         >     >> Indigo BioSystems, Inc.
>         >     >> (317) 536-2736 x101
>         >     >> (317) 306-5447 mobile
>         >     >>
>         >     >> www.indigobio.com <http://www.indigobio.com>
>         <http://www.indigobio.com>
>         >     <http://www.indigobio.com/>
>         >     >>
>         >     >
>         >
>         > v
>         >
>
>
>         -------------------------------------------------------------------------
>         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...
>         <mailto:Psi...@li...>
>         https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>
>
>
>
>     -- 
>     Angel Pizarro
>     Director, ITMAT Bioinformatics Facility
>     806 Biological Research Building
>     421 Curie Blvd.
>     Philadelphia, PA 19104-6160
>     215-573-3736
>
>
>
>
> -- 
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
> 806 Biological Research Building
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
> 215-573-3736
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

[Angel P. <an...@ma...>]

also note the the ID attribute instances must be unique across all
attributes that are of type ID, regardless of containign element. In other
words <foo id="1" /> and <bar id="1" /> would violate this if both
attributes named "id" were of type xsd:ID

-angel


On Wed, Feb 20, 2008 at 9:40 AM, Angel Pizarro <an...@ma...>
wrote:

> As I understand it:
>
> ID & IDREF are used for internal references in single documents.
>
> XLinks are used to reference within and across documents.
>
> analysisXML can use XLink  to reference a spectra pretty easily if you use
> ID as the document-unique identifier type.
>
> -angel
>
>
> On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers <
> mat...@va...> wrote:
>
> > Yes, xs:ID definitely works as a fragment identifier, it's what XHTML
> > and XML use for the core "id" attribute. :)
> >
> > A cross-file reference is composed of a document identifier (not sure
> > what form this can take, so I assume anyURI) and an optional fragment
> > identifier:
> > "file://foo.mzML#foo.1.1.1.dta" would reference the element with
> > id="foo.1.1.1.dta" in foo.mzML
> >
> > -Matt
> >
> >
> > Angel Pizarro wrote:
> > > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian <rkj...@in...
> > > <mailto:rkj...@in...>> wrote:
> > >
> > >     Does the xs:ID constraint solve this problem?
> > >
> > >
> > > maybe since  I think we had agreed that mzML REFs are within-file only
> > ?
> > >
> > >
> > >     -----Original Message-----
> > >     From: psi...@li...
> > >     <mailto:psi...@li...>
> > >     [mailto:psi...@li...
> > >     <mailto:psi...@li...>] On Behalf Of
> > >     Matt
> > >     Chambers
> > >     Sent: Tuesday, February 19, 2008 10:34 PM
> > >     To: Mass spectrometry standard development
> > >     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> > >
> > >     After a little more thought, absolute instances of xs:anyURI will
> > not
> > >     always work as a fragment identifier. If a spectrum's id attribute
> > was
> > >     xs:anyURI in file "foo.mzML":
> > >     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a valid
> > (absolute)
> > >     xs:anyURI -->
> > >
> > >     And in something like pepXML or analysisXML:
> > >     <spectrumQuery spectrumRef="file://foo.mzML#file://foo.1.1.1.dta"
> > />
> > >     <!-- not a valid xs:anyURI! -->
> > >
> > >     Unless I'm missing something, using xs:anyURI for fragment
> > identifiers
> > >     would actually make the schema less safe. Valid mzML ids would be
> > >     potentially unusable in an external URI unless URL-encoded, which
> > >     would
> > >     defeat the point of using xs:anyURI in the first place.
> > >
> > >     -Matt
> > >
> > >
> > >     Randy Julian wrote:
> > >     > All we are trying to achieve with the anyURI is safety for use
> > >     within
> > >     a
> > >     > URI.  Any xlink-safe way of doing this will work.  So if xs:ID
> > is
> > >     > supported better by the validating parsers, it would do what we
> > >     want.
> > >     >
> > >     > -----Original Message-----
> > >     > From: psi...@li...
> > >     <mailto:psi...@li...>
> > >     > [mailto:psi...@li...
> > >     <mailto:psi...@li...>] On Behalf Of
> > >     > Matthew Chambers
> > >     > Sent: Tuesday, February 19, 2008 4:25 PM
> > >     > To: Mass spectrometry standard development
> > >     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> > >     >
> > >     > You are right Randy, we were forgetting about relative URIs
> > >     which can
> > >     > simply refer to a resource's name with no path at all ("1" is
> > >     certainly
> > >     > a valid resource name). However, I think anyURI is still a bad
> > idea
> > >     for
> > >     > any attribute which is not intended to be able to refer to
> > something
> > >     in
> > >     > a remote location (e.g. not in the current file). The "id"
> > attribute
> > >     in
> > >     > the XML namespace has type "xs:ID" which has semantics more
> > >     along the
> > >     > lines of what I think you want. If I understand the use case
> > >     correctly,
> > >     > it is desirable to be able to link to certain mzML elements from
> > >     > external documents with a URI, like:
> > >     > file://data_source.mzML#s555
> > >     > This is an example absolute URI reference to a spectrum in a
> > file at
> > >     > "data_source.mzML" where the spectrum's id attribute is "s555".
> > It
> > >     > wouldn't make sense for the id itself to be a URI, although the
> > >     > reference to it can (and should) be.
> > >     >
> > >     > So:
> > >     > 1) for id attributes which can be referred to externally or
> > >     internally,
> > >     > use the type "xs:ID"
> > >     > 2) for references to external or internal resources by their id
> > >     > attribute, use the type "xs:anyURI"
> > >     >
> > >     > This would have the problem of the Xerxes C parser not
> > validating
> > >     > relative URIs correctly, but that seems to be wrong on their
> > >     part. :/
> > >     > Anyway, users of Xerxes C can turn off the validation feature to
> > >     work
> > >     > around it.
> > >     >
> > >     > Also, Ref attributes in mzML could use anyURI for consistency
> > >     reasons
> > >     > even though we don't currently know of a use case where such
> > >     references
> > >     > would be made to an external file.
> > >     >
> > >     > -Matt
> > >     >
> > >     >
> > >     > Randy Julian wrote:
> > >     >
> > >     >> Per our conversation today, the relevant specification is
> > RFC-2396:
> > >     >>
> > >     >> http://www.ietf.org/rfc/rfc2396.txt
> > >     >>
> > >     >> Section 5 talks about relative URIs. They do not need to
> > >     include the
> > >     >> protocol and their syntax would include all integers:
> > >     >>
> > >     >> The syntax for relative URI takes advantage of the <hier_part>
> > >     syntax
> > >     >>    of <absoluteURI> (Section 3) in order to express a reference
> > >     that
> > >     >>
> > >     > is
> > >     >
> > >     >>    relative to the namespace of another hierarchical URI.
> > >     >>
> > >     >>       relativeURI   = ( net_path | abs_path | rel_path ) [ "?"
> > >     query
> > >     ]
> > >     >>
> > >     >>    A relative reference beginning with two slash characters is
> > >     termed
> > >     >>
> > >     > a
> > >     >
> > >     >>    network-path reference, as defined by <net_path> in Section
> > 3.
> > >     >>
> > >     > Such
> > >     >
> > >     >>    references are rarely used.
> > >     >>
> > >     >>    A relative reference beginning with a single slash character
> > is
> > >     >>    termed an absolute-path reference, as defined by <abs_path>
> > in
> > >     >>    Section 3.
> > >     >>
> > >     >>    A relative reference that does not begin with a scheme name
> > or a
> > >     >>    slash character is termed a relative-path reference.
> > >     >>
> > >     >>       rel_path      = rel_segment [ abs_path ]
> > >     >>
> > >     >>       rel_segment   = 1*( unreserved | escaped | ";" | "@" |
> > "&" |
> > >     "="
> > >     >>
> > >     > | "+" | "$" | "," )
> > >     >
> > >     >> That means that you don't need the net_path part or the
> > >     abs_path part
> > >
> > >     >> but can use the rel_path part alone. The rel_path part can have
> > >     only
> > >     >> the rel_segment part which is required to have one or more
> > >     unreserved
> > >
> > >     >> characters (includes all the integers) and/or any of the above
> > >     special
> > >     >>
> > >     >
> > >     >
> > >     >> characters or escaped characters.
> > >     >>
> > >     >> The point of using it in mzML for IDs is that you can be
> > assured of
> > >     it
> > >     >>
> > >     >
> > >     >
> > >     >> being a valid relative path when extended by all the other
> > >     components
> > >
> > >     >> needed to navigate to a referenced document (protocol, absolute
> > >     path,
> > >
> > >     >> etc.).
> > >     >>
> > >     >> We can achieve this by convention by saying in the mzML spec
> > >     doc (and
> > >
> > >     >> possibly putting the required pattern in the schema), that the
> > >     string
> > >
> > >     >> for ID must conform to RFC-2396.
> > >     >>
> > >     >> Randy
> > >     >>
> > >     >> Randall K Julian, Jr. Ph.D.
> > >     >> President
> > >     >> Indigo BioSystems, Inc.
> > >     >> (317) 536-2736 x101
> > >     >> (317) 306-5447 mobile
> > >     >>
> > >     >> www.indigobio.com <http://www.indigobio.com>
> > >     <http://www.indigobio.com/>
> > >     >>
> > >     >
> > >
> > > v
> > >
> >
> >
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
>
>
> --
> Angel Pizarro
> Director, ITMAT Bioinformatics Facility
> 806 Biological Research Building
> 421 Curie Blvd.
> Philadelphia, PA 19104-6160
> 215-573-3736
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

[Angel P. <an...@ma...>]

As I understand it:

ID & IDREF are used for internal references in single documents.

XLinks are used to reference within and across documents.

analysisXML can use XLink  to reference a spectra pretty easily if you use
ID as the document-unique identifier type.

-angel

On Wed, Feb 20, 2008 at 9:21 AM, Matt Chambers <
mat...@va...> wrote:

> Yes, xs:ID definitely works as a fragment identifier, it's what XHTML
> and XML use for the core "id" attribute. :)
>
> A cross-file reference is composed of a document identifier (not sure
> what form this can take, so I assume anyURI) and an optional fragment
> identifier:
> "file://foo.mzML#foo.1.1.1.dta" would reference the element with
> id="foo.1.1.1.dta" in foo.mzML
>
> -Matt
>
>
> Angel Pizarro wrote:
> > On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian <rkj...@in...
> > <mailto:rkj...@in...>> wrote:
> >
> >     Does the xs:ID constraint solve this problem?
> >
> >
> > maybe since  I think we had agreed that mzML REFs are within-file only ?
> >
> >
> >     -----Original Message-----
> >     From: psi...@li...
> >     <mailto:psi...@li...>
> >     [mailto:psi...@li...
> >     <mailto:psi...@li...>] On Behalf Of
> >     Matt
> >     Chambers
> >     Sent: Tuesday, February 19, 2008 10:34 PM
> >     To: Mass spectrometry standard development
> >     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> >
> >     After a little more thought, absolute instances of xs:anyURI will
> not
> >     always work as a fragment identifier. If a spectrum's id attribute
> was
> >     xs:anyURI in file "foo.mzML":
> >     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a valid
> (absolute)
> >     xs:anyURI -->
> >
> >     And in something like pepXML or analysisXML:
> >     <spectrumQuery spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" />
> >     <!-- not a valid xs:anyURI! -->
> >
> >     Unless I'm missing something, using xs:anyURI for fragment
> identifiers
> >     would actually make the schema less safe. Valid mzML ids would be
> >     potentially unusable in an external URI unless URL-encoded, which
> >     would
> >     defeat the point of using xs:anyURI in the first place.
> >
> >     -Matt
> >
> >
> >     Randy Julian wrote:
> >     > All we are trying to achieve with the anyURI is safety for use
> >     within
> >     a
> >     > URI.  Any xlink-safe way of doing this will work.  So if xs:ID is
> >     > supported better by the validating parsers, it would do what we
> >     want.
> >     >
> >     > -----Original Message-----
> >     > From: psi...@li...
> >     <mailto:psi...@li...>
> >     > [mailto:psi...@li...
> >     <mailto:psi...@li...>] On Behalf Of
> >     > Matthew Chambers
> >     > Sent: Tuesday, February 19, 2008 4:25 PM
> >     > To: Mass spectrometry standard development
> >     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
> >     >
> >     > You are right Randy, we were forgetting about relative URIs
> >     which can
> >     > simply refer to a resource's name with no path at all ("1" is
> >     certainly
> >     > a valid resource name). However, I think anyURI is still a bad
> idea
> >     for
> >     > any attribute which is not intended to be able to refer to
> something
> >     in
> >     > a remote location (e.g. not in the current file). The "id"
> attribute
> >     in
> >     > the XML namespace has type "xs:ID" which has semantics more
> >     along the
> >     > lines of what I think you want. If I understand the use case
> >     correctly,
> >     > it is desirable to be able to link to certain mzML elements from
> >     > external documents with a URI, like:
> >     > file://data_source.mzML#s555
> >     > This is an example absolute URI reference to a spectrum in a file
> at
> >     > "data_source.mzML" where the spectrum's id attribute is "s555". It
> >     > wouldn't make sense for the id itself to be a URI, although the
> >     > reference to it can (and should) be.
> >     >
> >     > So:
> >     > 1) for id attributes which can be referred to externally or
> >     internally,
> >     > use the type "xs:ID"
> >     > 2) for references to external or internal resources by their id
> >     > attribute, use the type "xs:anyURI"
> >     >
> >     > This would have the problem of the Xerxes C parser not validating
> >     > relative URIs correctly, but that seems to be wrong on their
> >     part. :/
> >     > Anyway, users of Xerxes C can turn off the validation feature to
> >     work
> >     > around it.
> >     >
> >     > Also, Ref attributes in mzML could use anyURI for consistency
> >     reasons
> >     > even though we don't currently know of a use case where such
> >     references
> >     > would be made to an external file.
> >     >
> >     > -Matt
> >     >
> >     >
> >     > Randy Julian wrote:
> >     >
> >     >> Per our conversation today, the relevant specification is
> RFC-2396:
> >     >>
> >     >> http://www.ietf.org/rfc/rfc2396.txt
> >     >>
> >     >> Section 5 talks about relative URIs. They do not need to
> >     include the
> >     >> protocol and their syntax would include all integers:
> >     >>
> >     >> The syntax for relative URI takes advantage of the <hier_part>
> >     syntax
> >     >>    of <absoluteURI> (Section 3) in order to express a reference
> >     that
> >     >>
> >     > is
> >     >
> >     >>    relative to the namespace of another hierarchical URI.
> >     >>
> >     >>       relativeURI   = ( net_path | abs_path | rel_path ) [ "?"
> >     query
> >     ]
> >     >>
> >     >>    A relative reference beginning with two slash characters is
> >     termed
> >     >>
> >     > a
> >     >
> >     >>    network-path reference, as defined by <net_path> in Section 3.
> >     >>
> >     > Such
> >     >
> >     >>    references are rarely used.
> >     >>
> >     >>    A relative reference beginning with a single slash character
> is
> >     >>    termed an absolute-path reference, as defined by <abs_path> in
> >     >>    Section 3.
> >     >>
> >     >>    A relative reference that does not begin with a scheme name or
> a
> >     >>    slash character is termed a relative-path reference.
> >     >>
> >     >>       rel_path      = rel_segment [ abs_path ]
> >     >>
> >     >>       rel_segment   = 1*( unreserved | escaped | ";" | "@" | "&"
> |
> >     "="
> >     >>
> >     > | "+" | "$" | "," )
> >     >
> >     >> That means that you don't need the net_path part or the
> >     abs_path part
> >
> >     >> but can use the rel_path part alone. The rel_path part can have
> >     only
> >     >> the rel_segment part which is required to have one or more
> >     unreserved
> >
> >     >> characters (includes all the integers) and/or any of the above
> >     special
> >     >>
> >     >
> >     >
> >     >> characters or escaped characters.
> >     >>
> >     >> The point of using it in mzML for IDs is that you can be assured
> of
> >     it
> >     >>
> >     >
> >     >
> >     >> being a valid relative path when extended by all the other
> >     components
> >
> >     >> needed to navigate to a referenced document (protocol, absolute
> >     path,
> >
> >     >> etc.).
> >     >>
> >     >> We can achieve this by convention by saying in the mzML spec
> >     doc (and
> >
> >     >> possibly putting the required pattern in the schema), that the
> >     string
> >
> >     >> for ID must conform to RFC-2396.
> >     >>
> >     >> Randy
> >     >>
> >     >> Randall K Julian, Jr. Ph.D.
> >     >> President
> >     >> Indigo BioSystems, Inc.
> >     >> (317) 536-2736 x101
> >     >> (317) 306-5447 mobile
> >     >>
> >     >> www.indigobio.com <http://www.indigobio.com>
> >     <http://www.indigobio.com/>
> >     >>
> >     >
> >
> > v
> >
>
>
> -------------------------------------------------------------------------
> 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
>



-- 
Angel Pizarro
Director, ITMAT Bioinformatics Facility
806 Biological Research Building
421 Curie Blvd.
Philadelphia, PA 19104-6160
215-573-3736

Re: [Psidev-ms-dev] Relative URIs and RFC-2396

[Matt C. <mat...@va...>]

Yes, xs:ID definitely works as a fragment identifier, it's what XHTML 
and XML use for the core "id" attribute. :)

A cross-file reference is composed of a document identifier (not sure 
what form this can take, so I assume anyURI) and an optional fragment 
identifier:
"file://foo.mzML#foo.1.1.1.dta" would reference the element with 
id="foo.1.1.1.dta" in foo.mzML

-Matt


Angel Pizarro wrote:
> On Wed, Feb 20, 2008 at 6:42 AM, Randy Julian <rkj...@in... 
> <mailto:rkj...@in...>> wrote:
>
>     Does the xs:ID constraint solve this problem?
>
>
> maybe since  I think we had agreed that mzML REFs are within-file only ?
>
>
>     -----Original Message-----
>     From: psi...@li...
>     <mailto:psi...@li...>
>     [mailto:psi...@li...
>     <mailto:psi...@li...>] On Behalf Of
>     Matt
>     Chambers
>     Sent: Tuesday, February 19, 2008 10:34 PM
>     To: Mass spectrometry standard development
>     Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>
>     After a little more thought, absolute instances of xs:anyURI will not
>     always work as a fragment identifier. If a spectrum's id attribute was
>     xs:anyURI in file "foo.mzML":
>     <spectrum id="file://foo.1.1.1.dta" /> <!-- this is a valid (absolute)
>     xs:anyURI -->
>
>     And in something like pepXML or analysisXML:
>     <spectrumQuery spectrumRef="file://foo.mzML#file://foo.1.1.1.dta" />
>     <!-- not a valid xs:anyURI! -->
>
>     Unless I'm missing something, using xs:anyURI for fragment identifiers
>     would actually make the schema less safe. Valid mzML ids would be
>     potentially unusable in an external URI unless URL-encoded, which
>     would
>     defeat the point of using xs:anyURI in the first place.
>
>     -Matt
>
>
>     Randy Julian wrote:
>     > All we are trying to achieve with the anyURI is safety for use
>     within
>     a
>     > URI.  Any xlink-safe way of doing this will work.  So if xs:ID is
>     > supported better by the validating parsers, it would do what we
>     want.
>     >
>     > -----Original Message-----
>     > From: psi...@li...
>     <mailto:psi...@li...>
>     > [mailto:psi...@li...
>     <mailto:psi...@li...>] On Behalf Of
>     > Matthew Chambers
>     > Sent: Tuesday, February 19, 2008 4:25 PM
>     > To: Mass spectrometry standard development
>     > Subject: Re: [Psidev-ms-dev] Relative URIs and RFC-2396
>     >
>     > You are right Randy, we were forgetting about relative URIs
>     which can
>     > simply refer to a resource's name with no path at all ("1" is
>     certainly
>     > a valid resource name). However, I think anyURI is still a bad idea
>     for
>     > any attribute which is not intended to be able to refer to something
>     in
>     > a remote location (e.g. not in the current file). The "id" attribute
>     in
>     > the XML namespace has type "xs:ID" which has semantics more
>     along the
>     > lines of what I think you want. If I understand the use case
>     correctly,
>     > it is desirable to be able to link to certain mzML elements from
>     > external documents with a URI, like:
>     > file://data_source.mzML#s555
>     > This is an example absolute URI reference to a spectrum in a file at
>     > "data_source.mzML" where the spectrum's id attribute is "s555". It
>     > wouldn't make sense for the id itself to be a URI, although the
>     > reference to it can (and should) be.
>     >
>     > So:
>     > 1) for id attributes which can be referred to externally or
>     internally,
>     > use the type "xs:ID"
>     > 2) for references to external or internal resources by their id
>     > attribute, use the type "xs:anyURI"
>     >
>     > This would have the problem of the Xerxes C parser not validating
>     > relative URIs correctly, but that seems to be wrong on their
>     part. :/
>     > Anyway, users of Xerxes C can turn off the validation feature to
>     work
>     > around it.
>     >
>     > Also, Ref attributes in mzML could use anyURI for consistency
>     reasons
>     > even though we don't currently know of a use case where such
>     references
>     > would be made to an external file.
>     >
>     > -Matt
>     >
>     >
>     > Randy Julian wrote:
>     >
>     >> Per our conversation today, the relevant specification is RFC-2396:
>     >>
>     >> http://www.ietf.org/rfc/rfc2396.txt
>     >>
>     >> Section 5 talks about relative URIs. They do not need to
>     include the
>     >> protocol and their syntax would include all integers:
>     >>
>     >> The syntax for relative URI takes advantage of the <hier_part>
>     syntax
>     >>    of <absoluteURI> (Section 3) in order to express a reference
>     that
>     >>
>     > is
>     >
>     >>    relative to the namespace of another hierarchical URI.
>     >>
>     >>       relativeURI   = ( net_path | abs_path | rel_path ) [ "?"
>     query
>     ]
>     >>
>     >>    A relative reference beginning with two slash characters is
>     termed
>     >>
>     > a
>     >
>     >>    network-path reference, as defined by <net_path> in Section 3.
>     >>
>     > Such
>     >
>     >>    references are rarely used.
>     >>
>     >>    A relative reference beginning with a single slash character is
>     >>    termed an absolute-path reference, as defined by <abs_path> in
>     >>    Section 3.
>     >>
>     >>    A relative reference that does not begin with a scheme name or a
>     >>    slash character is termed a relative-path reference.
>     >>
>     >>       rel_path      = rel_segment [ abs_path ]
>     >>
>     >>       rel_segment   = 1*( unreserved | escaped | ";" | "@" | "&" |
>     "="
>     >>
>     > | "+" | "$" | "," )
>     >
>     >> That means that you don't need the net_path part or the
>     abs_path part
>
>     >> but can use the rel_path part alone. The rel_path part can have
>     only
>     >> the rel_segment part which is required to have one or more
>     unreserved
>
>     >> characters (includes all the integers) and/or any of the above
>     special
>     >>
>     >
>     >
>     >> characters or escaped characters.
>     >>
>     >> The point of using it in mzML for IDs is that you can be assured of
>     it
>     >>
>     >
>     >
>     >> being a valid relative path when extended by all the other
>     components
>
>     >> needed to navigate to a referenced document (protocol, absolute
>     path,
>
>     >> etc.).
>     >>
>     >> We can achieve this by convention by saying in the mzML spec
>     doc (and
>
>     >> possibly putting the required pattern in the schema), that the
>     string
>
>     >> for ID must conform to RFC-2396.
>     >>
>     >> Randy
>     >>
>     >> Randall K Julian, Jr. Ph.D.
>     >> President
>     >> Indigo BioSystems, Inc.
>     >> (317) 536-2736 x101
>     >> (317) 306-5447 mobile
>     >>
>     >> www.indigobio.com <http://www.indigobio.com>
>     <http://www.indigobio.com/>
>     >>
>     >
>
> v
>