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

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #55 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Um... in discussions with members of the mzML group it's always been agreed  
that this
is what we will be using. Last agreed and documented to use the id at a
teleconference (which Eric also attended) on 2nd October:
http://psidev.info/index.php?q=node/374

As you said above: "Really there's no nativeID for a merged spectrum, so  
anything we
come up with is a workaround." Am I missing something - are you you  
suggesting that
search engines should can not rely on the mzML id value and store this in  
output
files? The mzML schema documentation says, for the id:
<xs:documentation>A unique identifier for this spectrum. It should be  
expected that
external files may use this identifier together with the mzML filename or  
accession
to reference a particular spectrum.</xs:documentation>

Do you think that this is incorrect?

Also, to change the term from spectrumID -> nativeID would, I think be  
confusing. The
term makes perfect sense in the context of an mzML document, but for  
analysisXML it
could easily imply something native to the search engine rather than one of  
its input
files?

btw, the file format of all the input files (spectra, fasta, search engine  
outputs)
are all defined in the analysisXML documents (search on <pf:fileFormat>) so  
I'm not
sure what you mean. (Ah... I see that a couple of the examples seem to be  
missing
these - hopefully they will get corrected soon. Thanks for pointing this  
out.)

David

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #54 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Both a & b to emphasize the fact that the nativeID is defined no matter  
what the
format of the source file is. Also, just like mzML, you would define that  
format at
the top of the file, although it doesn't appear there is an analysisXML  
equivalent to
"fileContent/fileDescription" in mzML. The nativeID formats are defined in  
the mzML
CV and the terms map to that top header to define the nativeID format for  
every
spectrum in the file: see CV terms starting at MS:1000767
  in
http://psidev.cvs.sourceforge.net/*checkout*/psidev/psi/psi-ms/mzML/controlledVocabulary/psi-ms.obo

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #53 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Hi Matt,
The nativeID enforcement in mzML sounds good to me.

I'm very sorry, but I don't actually understand what you are proposing:
a) To change the name of the attribute from spectrumID -> nativeID
b) For mzML, to reference the nativeID rather than the id
c) Add a nativeID attribute as well as a spectrumID
d) ?

Or some combination of the above! Perhaps it's just getting too late for  
me ;)
David

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 26th November at 4:00pm UK time

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

Hi,

Nobody has disagreed with:
 > Maybe safest to stick with the original proposal of just CV...

We already have the CV (PI:00360 and PI:00361) and the validator accepts 
these so I've updated and committed the Mascot examples under svn.

David

David Creasy wrote:
> Hi,
> 
> Jones, Andy wrote:
>> Ah I missed this proposal. Are these are the only two mechanisms we 
>> need/want?
> One day, someone may well want to do something more involved...
> 
>> If so, we could just build the whole thing into the schema:
>>
>>     <AmbiguousResidue Code="B" SubstituteResidues="D N"/>
>>   
>>    <AmbiguousResidue Code="Z">
>>       <AlternateResidue Mass="129.042593"/>
>>       <AlternateResidue Mass="128.058578"/>
>>     </AmbiguousResidue>
>>
>> The downsides are if someone decides another mechanism is needed we 
>> cannot
>> extend this. Also, I'm not sure we can validate that only one 
>> mechanism or the
>> other is used (but this issue is the same whichever way we solve the 
>> problem).
>>
>> In fact, do we need to allow it to be done both ways... Couldn't we 
>> just enforce
>> that it is done in the latter way, 
> Could do, but not so nice because:
>  - It would be quite verbose - most search engines will use 'X' to mean
>    all other residues.
>  - It's a little harder to understand with just numbers.
>    <SequenceCollection>
>      <DBSequence id="A">
>        <seq>MAXXPAVK...
>      <Peptide
>        <peptideSequence>MAKAPAVK
>    ...
>    <PeptideEvidence start="1" end="8" DBSequence_Ref="A" .....
> 
> Maybe safest to stick with the original proposal of just CV and accept 
> that the list of chars is not properly validated?
> 
> David
>>
>> Cheers
>> Andy
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: David Creasy [mailto:dc...@ma...]
>>> Sent: 27 November 2008 15:58
>>> To: Jones, Andy
>>> Cc: psi...@li...
>>> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on 
>>> Wednesday
>>> 26th November at 4:00pm UK time
>>>
>>> Hi Andy
>>>
>>> Jones, Andy wrote:
>>>> I have a query about something in the minutes:
>>>>
>>>> <MassTable is="MT1">
>>>>  <Residue Code="A" Mass="71.037114"/>
>>>>  ...
>>>>  <Residue Code="Y" Mass="163.063329"/>
>>>>
>>>>  <AmbiguousResidue Code="B">
>>>>    <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
>>>> cvRef="PSI-PI" value="DN"/>
>>>>  </AmbiguousResidue>
>>>>  <AmbiguousResidue Code="Z">
>>>>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>>> value="129.042593"/>
>>>>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>>> value="128.058578"/>
>>>>  </AmbiguousResidue>
>>>>  . . .
>>>> </MassTable>
>>>>
>>>>
>>>> I think we agreed that the value attribute above for "Alternate single
>> letter
>>>> codes" should be "D N" i.e. space separated chars, is this correct?
>>> Yes, this is what we agreed.
>>>
>>>> If so, I'm not sure if I was supposed to add this as documentation 
>>>> to the
>> XSD or
>>>> if we want to add this documentation to the CV term (the latter 
>>>> seems better
>> to
>>>> me).
>>> Adding it to the CV term seems better. However, Martin proposed a
>>> different approach in an email a little earlier today:
>>>
>>>
>>>  > What do you think about:?
>>> ...
>>>     <AmbiguousResidue Code="B" ResidueRef="D N"/>
>>>     <AmbiguousResidue Code="Z">
>>>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" 
>>> cvRef="PSI-PI"
>>>   value="129.042593"/>
>>>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" 
>>> cvRef="PSI-PI"
>>>   value="128.058578"/>
>>>     </AmbiguousResidue>
>>>
>>> ResidueRef can be type listOfChar.
>>>
>>> Disadvantage is the mix of schema and CVParam mechanisms...
>>> ------------------
>>>
>>> I don't have a preference either way. Any thoughts Andy?
>>>
>>> David
>>>
>>>> Cheers, Andy
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: David Creasy [mailto:dc...@ma...]
>>>>> Sent: 27 November 2008 13:35
>>>>> To: psi...@li...
>>>>> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on
>>> Wednesday
>>>>> 26th November at 4:00pm UK time
>>>>>
>>>>> Minutes are here:
>>>>>
>>>>> http://psidev.info/index.php?q=node/395
>>>>>
>>>>> Most action items already done...
>>>>>
>>>>>
>>>>>
>>>>> David Creasy wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> There will be an AnalysisXML working group conference call on 
>>>>>> WEDNESDAY
>>>>>> (instead of Thursday, because it is Thanksgiving in the US) at:
>>>>>>
>>> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2 
>>>
>>>>> 008&hour=16&min=0&sec=0&p1=136
>>>>>> Minutes, including action items ;) from last meeting at:
>>>>>> http://psidev.info/index.php?q=node/392
>>>>>>
>>>>>> Agenda:
>>>>>> 1. Review of minutes of last meeting
>>>>>>
>>>>>> 2. Internal fragment ions
>>>>>>
>>>>>> 3. Ambiguous residues
>>>>>>
>>>>>> 4. Status of mapping document, CV and examples.
>>>>>>
>>>>>> 5. Please review the latest documentation:
>>>>>>
>>>>>> http://psi-
>>> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr 
>>>
>>>>> aft.doc
>>>>>>
>>>>>> Dial in details:
>>>>>>
>>>>>> + Germany: 08001012079
>>>>>> + Switzerland: 0800000860
>>>>>> + UK: 08081095644
>>>>>> + USA: 1-866-314-3683
>>>>>> + Generic international: +44 2083222500 (UK number)
>>>>>>
>>>>>> access code: 297427
>>>>>>
>>>>> -- 
>>>>> David Creasy
>>>>> Matrix Science
>>>>> 64 Baker Street
>>>>> London W1U 7GB, UK
>>>>> Tel: +44 (0)20 7486 1050
>>>>> Fax: +44 (0)20 7224 1344
>>>>>
>>>>> dc...@ma...
>>>>> http://www.matrixscience.com
>>>>>
>>>>> Matrix Science Ltd. is registered in England and Wales
>>>>> Company number 3533898
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>>>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>>>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>>>> the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Psidev-pi-dev mailing list
>>>>> Psi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>>> -- 
>>> David Creasy
>>> Matrix Science
>>> 64 Baker Street
>>> London W1U 7GB, UK
>>> Tel: +44 (0)20 7486 1050
>>> Fax: +44 (0)20 7224 1344
>>>
>>> dc...@ma...
>>> http://www.matrixscience.com
>>>
>>> Matrix Science Ltd. is registered in England and Wales
>>> Company number 3533898
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the 
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Psidev-pi-dev mailing list
>>> Psi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> 

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

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

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #52 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

I meant nativeID instead of spectrumID to facilitate analysisXML output  
from non-mzML
input. I still agree with scan time (my preference is not duplicating terms  
between
CVs), and mgf title/scans/rawscans.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #51 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

We didn't have any XSD gurus in the mzML group or they didn't chime in so  
the
uniqueness of nativeID is not XSD-derived, it's in the specification docs  
and the
semantic validators enforce it (actually they are much more than just  
unique, their
format is strictly defined depending on the source file). I presume this is  
the
related XSD uniqueness code, what does it mean in plain english? :)
   <xsd:element name="SpectrumIdentificationList"
type="psi-pi:PSI-PI.analysis.search.SpectrumIdentificationListType"  
abstract="false"
substitutionGroup="psi-pi:AnalysisResultList">
     <xsd:unique name="PK_COMPOSITE_SpecRef">
        <xsd:selector xpath="./*"/>
         <xsd:field xpath="@spectrumID"/>
         <xsd:field xpath="@SpectraData_ref"/>
      </xsd:unique>
   </xsd:element>

I don't understand the hesitation to use nativeID which already has the "if  
mzML it
means this, if mzData it means this, if mzXML it means this, if MGF it  
means this,
etc." logic defined. That way implementers can use the same nativeID  
parsing code for
both standards.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #50 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Um. I can't find the relevant minutes that describe why we aren't importing  
the MS
CV... I recollect that part of the discussion was along the lines that the  
structure
would be different between the two and this could become a logistical  
nightmare.
Also, that the mzML CV is not yet stable and trying to get the two to work  
together
in a timely manner wasn't considered to be feasible. I'm no expert with CV,  
so am
probably not the best person to answer this. Guess we (both groups) may  
have to
defend this decision.

btw, there's no constraint for nativeID being unique in the mzML schema so  
I assumed
it didn't have to be unique.

I think this is starting to get a little beyond the scope of  
analysisXML. 'All' we
want is to be able to say which spectrum a result relates to, and we can
realistically only report back whatever is fed into the search engine.

Is the following 'good enough' for all cases (even if we aren't 100% happy  
with it?):

The spectrumID attribute in analysisXML instance documents must be unique.

spectrumID: for mzML   files must be the <spectrum id> and is enforced as  
unique in
mzML schema
             for mzData files, <spectrum id> value, should be unique, but  
not enforced
in mzData schema
             for mzXML  scan attribute, should be unique, but not enforced  
in mzXML
schema?
             Other files, any unique value, possibly generated by the search  
engine.

Add the following optional CV terms:

   scan time  (maxOccurs="unbounded" for merged spectra)
   nativeID   (maxOccurs="unbounded" for merged spectra)
   mgf title
   mgf scans
   mgf rawscans

So MyriMatch would presumably report the nativeID.

Does this sound reasonable?

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #49 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Can you point me to the discussion about (not) sharing CV? That seems a bit  
crazy to
me (and contrary to the PSI CV guidelines?). I'm sure there are reasons  
though, I
just want to see them. :)

All of these terms are also things that would potentially be in an mzML  
file created
from MGF (just like the Thermo filter line may be included from Thermo  
files), so
that's why I suggested they all go in the MS CV. MGF is after all a generic  
MS
format, not necessarily specific to proteomics even. :)

NativeIDs in mzML must be unique. You just had to bring up merged spectra  
didn't you?
;) It gets pretty painful and hazy when the original acquisitions and their  
merged
forms are kept in the same file. There's 2 issues there:
1) support representing both the merged spectra and the separate  
acquisitions as
independent spectra? or only support one or the other
2) if yes to 1, and nativeID must be unique, there are several possible  
solutions:
   a) just taking the first acquisition's nativeID won't be unique, so we  
extend the
nativeID syntax to support either ranges (Thermo: "controller=0  
scan=[2,10]") or
lists of nativeIDs ("controller=0 scan=2,controller=0 scan=15,controller=0  
scan=50")
or perhaps a combination of both
   b) use a special convention for nativeIDs of merged spectra that  
indicates to a
semantic validator that the nativeID is irrelevant and only the  
acquisitionList is
important; e.g. nativeID="merged" (since nativeID is string and not xsd:ID,  
it won't
be invalid syntax)

Really there's no nativeID for a merged spectrum, so anything we come up  
with is a
workaround.

Finally, several vendor formats allow peak picking straight out of their  
API, namely
Thermo, ABI, and Bruker. So for these formats MyriMatch works straight off  
by just
asking for the centroids. For other formats, we don't have an external peak  
picker
yet (in ProteoWizard) but we will "Real Soon Now." And no, when reading  
straight from
the vendor file we don't merge, so nativeIDs are direct.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #48 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

OK, I assume that we can now agree on adding:
   mgf title
   mgf scans
   mgf rawscans
(The rawscans will be in the next release of Mascot, so isn't documented  
yet)

Yes, I totally agree that the retention time (possibly multiple times as  
you say)
should be a generic term.
For better or worse, we decided after much discussion not to share CV with  
mzML, so
we'd need to have our own term for retention time. In fact, it looks as  
though we
already have PI:00114 (although this can't currently be used because it's  
not in the
mapping file). Even though we aren't sharing CV, we should at least use the  
same name
and description as in mzML:

[Term]
id: MS:1000016
name: scan time
def: "The time that an analyzer started a scan, relative to the start of  
the run."
[PSI:MS]
xref: value-type:xsd\:float "The allowed value-type for this CV term."
is_a: MS:1000503 ! scan attribute
relationship: has_units UO:0000003 ! time unit

Any objections?

We'd not considered the use case of of running a search straight from a  
native
format... However, are you doing some sort of peak detection? Are you  
merging
together any spectra - i.e. will there be multiple nativeIDs for each  
spectrum? Might
the same nativeID be used for multiple spectra. (I notice that nativeIDs  
don't have
to be unique in mzML.)

-David

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #47 on issue 42 by eisenachM: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

MPC_example.axml is an example using a protein decoy approach.
It lists ALL proteins of a ProteinDetectionAnalysis and reports the "local  
FDR" for
each protein in the score-sorted list.
[BTW: In the CV we have also "local FDR" for peptides and "pep:global FDR"  
and
"prot:global FDR", all as result values of an analysis.]

We need an INPUT parameter "prot:FDR threshold" or "pep:FDR threshold"  
(probably in
the branch "search input details"/"quality estimation method"), if we want  
to report
only the proteins below a specified FDR.


-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 44 in psi-pi: Issues with all instance docs

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

Comment #2 on issue 44 by dcreasy: Issues with all instance docs
http://code.google.com/p/psi-pi/issues/detail?id=44

(I've put this response to:
http://code.google.com/p/psi-pi/issues/detail?id=42#c44
into issue 44 because it's more of an instance doc issue.)

Looking at the instance doc:
http://code.google.com/p/psi-pi/source/browse/trunk/examples/MPC_example.axml
It's not really clear what :
<SourceFile id="SF1" location="proteinscape://....

is pointing to because there is no <pf:fileFormat>. I presume that this is  
some sort
of relational database? Maybe you do want to add a description for the  
format under
   PI:00040 ! source file format

I guess that we used the term SourceFile because in most cases the "thing"  
that is
used to create the analysisXML instance document will be another file. Maybe
SourceData would be a more generic name.

<SpectraData id="LCMALDI_spectra"
location="proteinscape://www.medizinisches-proteom-center.de/PSServer/Project/Sample/Separation_1D_LC/Fraction_X"/>

What does this point to? From the example under svn, looks as though this  
in an mgf
file (even though that may be stored in a RDB).


-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #46 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

MS2 is essentially concatenated DTAs with added metadata to avoid the  
problem you
mentioned about concatenated DTAs and PKLs. :) MS1 is equivalent for MS1  
data.
mzXML's scan attribute (xsd:nonZeroInteger) is required to be unique but  
obviously it
can't always be used to track down the original nativeID easily. There is a
nativeScanOrigin element meant to be able to do that, but it's not used  
frequently.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #45 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

OK, I can see the argument of skipping the MGF and going straight to the  
native
spectrum or spectra in a controlled manner, but I'll make a slightly more  
generic
proposal. For example, many input formats may provide retention time  
information as
an alternative way of identifying a scan, so that should be a generic  
concept. We
already have it in the PSI-MS CV of course: the "scan time" term.

So...now we are back to the original discussion about including mzML  
attributes in
analysisXML (the other MGF attributes also probably belong in the MS CV,  
perhaps
under an "alternative identifier" category). I'm not sure if your use case  
came up at
the time though - I seem to recall it was mainly considered as a way of  
forwarding
commonly-used attributes and not as an alternative identifier. So I would  
support the
alternative identifier approach for TITLE, SCANS, and RAWSCANS (I could not  
find any
documentation on the last one?), but not the retention time(s). That should  
re-use
the existing term, multiple times if necessary.

Also consider the use case of running a search straight from a native  
format. In such
a case, the nativeID is well defined (and can be adopted now, without using  
mzML as
an intermediate if that is not yet desired), the spectrumID is not. I think  
this use
case is perfectly legitimate too, we do it often with MyriMatch which can  
read
whatever formats pwiz can (currently Thermo RAW w/ Xcalibur, Waters RAW w/  
MassLynx,
Bruker/Agilent YEP, Bruker BAF/FID). And when we need to go back and view a  
spectrum
in either the raw data or in an associated mzML, the best bet is to use the  
nativeID
because it's well defined in either case.

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #44 on issue 42 by eisenachM: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

We specify the source file, from which the AnalysisXML file was created and
the Spectra_Data location.

For our MPC use case both are URIs to database locations which I created  
like this:
<SourceFile id="SF1"
location="proteinscape://www.medizinisches-proteom-center.de/PSServer/Project/Sample/Separation_1D_LC/Fraction_X/SpectraData/Results1"/>
<SpectraData id="LCMALDI_spectra"
location="proteinscape://www.medizinisches-proteom-center.de/PSServer/Project/Sample/Separation_1D_LC/Fraction_X"/>

1.) Was it intended like that?
2.) I suggest to rename <SourceFile> to <SourceData> (in obo, too).



-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #43 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Hi Matt,

Surprised to get any reply from you at all yesterday ;)
You are right, we kind of side stepped the issue of non mzML/mzData input  
formats at
the time, so it's important to hammer it out now. And yes, you are quite  
right, we
should try and support things as generally as possible. Incidentally, my  
proposal for
the CV wasn't quite as narrow as you suggest: MGF->DAT->analysisXML, it  
could be any
engine or format (or no intermediate file) in the middle.

I actually had a slightly different use case in mind - it wasn't for a  
generic
automated pipeline (which as you say is impossible to do reliably), but  
more for
'manual' inspection. So, if someone sees something 'interesting' they stand  
a chance
of finding the original data manually with as few intermediate files as  
possible.
However, you've got me thinking... suppose someone was writing a pipeline.  
They had
MGF files consistently generated by software 'X' and they were using 3  
different
search engines that output analysisXML files. They would surely rather that  
the
identifiers in the analysisXML files were of a consistent format using CV  
rather than
differing format using user params?

I guess I'm not keen on the nativeID idea for the MGF because I couldn't  
see how it
could be implemented retrospectively without the MGF files. Requiring that  
people
re-search their data seems a little harsh. Also, there's bound to be a time  
period
before mzML is widely supported.
For .pkl and concatenated .dta files, there is no option, so I've not  
proposed any
CV. For single dta files, there is no need for CV because it's multiple  
files and we
have the filename. Excuse my ignorance, but what's MS[12]? Is there a  
guaranteed
unique ID for mzXML?

David

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #42 on issue 42 by matthew....@vanderbilt.edu: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Hi David, sorry for the long reply to follow...

RE: spectrumID reference
I'm aware of the decision to use mzML's id as the spectrumID but I'm  
bringing the
point back up because the issue of non-mzML inputs was not discussed at the  
time
(AFAIK). I do not see the justification for using the id instead of the  
nativeID when
the latter must always exist for any input format whereas the former only  
makes sense
from an actual mzML file.


RE: MGF ids
Having CV terms for various format attributes is not a terrible thing, but  
I worry
because the scope is potentially much bigger than MGF->DAT->analysisXML.  
All of the
non-mzML input formats that could potentially be used to generate an  
intermediate
search result format and then converted to analysisXML will more often than  
not have
this problem. Trying to account for the various transformations of the  
identifiers
that could happen from this translation seems like a lost cause to me. The  
exception
would be very specific pipelines where the inputs and outputs are tightly  
controlled
and in those cases, userParams seem more appropriate than cvParams. Even in  
the case
of MGF->DAT->analysisXML, some of your MGF inputs may be completely lacking  
in title,
rt, and scan attributes, because they're all optional, so without an index  
it's all
screwed! :(

Just think of the combinations:
modern vendor formats: Thermo RAW, Waters RAW, WIFF, YEP, BAF, FID,  
MassHunter, Shimadzu
open formats: mzML, mzXML, mzData, MGF, DTA, MS[12], PKL,
search result formats: pepXML, SQT, OUT, SRF, DAT, X! Tandem

As I understand it, your specific use case is: take existing DAT files that  
were
searched from MGFs with (unique?) title/RT/scan attributes and convert to  
analysisXML
in a way that a generic reader can directly go back to the MGF data.

The generic version of that use case is: take existing search results in  
any format
that were searched from any spectra format and convert to analysisXML in a  
way that a
generic reader can directly go back to the data in the input spectra format.

Supporting the specific use case and not the generic one makes me cringe a  
bit, which
is why I chimed in on the issue. Can't users just re-search their data and  
output
directly to analysisXML with the index attribute intact? :P


-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Vacancy: secretary required for the Proteomics Informatics group

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

Hi all,

Phil Jones from the EBI has been the very capable secretary for PSI-PI 
group for quite some time. Sadly, he is no longer able to be involved 
with analysisXML and needs to step down as the secretary. There is 
therefore a need a replacement. Obvious duties involve taking minutes at 
the weekly telephone conference calls and updating the PSI-PI web pages etc.

If you would like to be considered for the role, please contact
me off list by the end of Wednesday 3rd December.

General PSI Org chart is here:
http://psidev.info/index.php?q=node/202

Thanks,

David Creasy
(dc...@ma...)

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 26th November at 4:00pm UK time

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

Hi,

Jones, Andy wrote:
> Ah I missed this proposal. Are these are the only two mechanisms we need/want?
One day, someone may well want to do something more involved...

> If so, we could just build the whole thing into the schema:
> 
>     <AmbiguousResidue Code="B" SubstituteResidues="D N"/>
>    
> 
>    <AmbiguousResidue Code="Z">
>       <AlternateResidue Mass="129.042593"/>
>       <AlternateResidue Mass="128.058578"/>
>     </AmbiguousResidue>
> 
> The downsides are if someone decides another mechanism is needed we cannot
> extend this. Also, I'm not sure we can validate that only one mechanism or the
> other is used (but this issue is the same whichever way we solve the problem).
> 
> In fact, do we need to allow it to be done both ways... Couldn't we just enforce
> that it is done in the latter way, 
Could do, but not so nice because:
  - It would be quite verbose - most search engines will use 'X' to mean
    all other residues.
  - It's a little harder to understand with just numbers.
    <SequenceCollection>
      <DBSequence id="A">
        <seq>MAXXPAVK...
      <Peptide
        <peptideSequence>MAKAPAVK
    ...
    <PeptideEvidence start="1" end="8" DBSequence_Ref="A" .....

Maybe safest to stick with the original proposal of just CV and accept 
that the list of chars is not properly validated?

David
> 
> Cheers
> Andy
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: David Creasy [mailto:dc...@ma...]
>> Sent: 27 November 2008 15:58
>> To: Jones, Andy
>> Cc: psi...@li...
>> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday
>> 26th November at 4:00pm UK time
>>
>> Hi Andy
>>
>> Jones, Andy wrote:
>>> I have a query about something in the minutes:
>>>
>>> <MassTable is="MT1">
>>>  <Residue Code="A" Mass="71.037114"/>
>>>  ...
>>>  <Residue Code="Y" Mass="163.063329"/>
>>>
>>>  <AmbiguousResidue Code="B">
>>>    <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
>>> cvRef="PSI-PI" value="DN"/>
>>>  </AmbiguousResidue>
>>>  <AmbiguousResidue Code="Z">
>>>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>> value="129.042593"/>
>>>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>> value="128.058578"/>
>>>  </AmbiguousResidue>
>>>  . . .
>>> </MassTable>
>>>
>>>
>>> I think we agreed that the value attribute above for "Alternate single
> letter
>>> codes" should be "D N" i.e. space separated chars, is this correct?
>> Yes, this is what we agreed.
>>
>>> If so, I'm not sure if I was supposed to add this as documentation to the
> XSD or
>>> if we want to add this documentation to the CV term (the latter seems better
> to
>>> me).
>> Adding it to the CV term seems better. However, Martin proposed a
>> different approach in an email a little earlier today:
>>
>>
>>  > What do you think about:?
>> ...
>>     <AmbiguousResidue Code="B" ResidueRef="D N"/>
>>     <AmbiguousResidue Code="Z">
>>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>   value="129.042593"/>
>>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>>   value="128.058578"/>
>>     </AmbiguousResidue>
>>
>> ResidueRef can be type listOfChar.
>>
>> Disadvantage is the mix of schema and CVParam mechanisms...
>> ------------------
>>
>> I don't have a preference either way. Any thoughts Andy?
>>
>> David
>>
>>> Cheers, Andy
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Creasy [mailto:dc...@ma...]
>>>> Sent: 27 November 2008 13:35
>>>> To: psi...@li...
>>>> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on
>> Wednesday
>>>> 26th November at 4:00pm UK time
>>>>
>>>> Minutes are here:
>>>>
>>>> http://psidev.info/index.php?q=node/395
>>>>
>>>> Most action items already done...
>>>>
>>>>
>>>>
>>>> David Creasy wrote:
>>>>> Hi everyone,
>>>>>
>>>>> There will be an AnalysisXML working group conference call on WEDNESDAY
>>>>> (instead of Thursday, because it is Thanksgiving in the US) at:
>>>>>
>> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2
>>>> 008&hour=16&min=0&sec=0&p1=136
>>>>> Minutes, including action items ;) from last meeting at:
>>>>> http://psidev.info/index.php?q=node/392
>>>>>
>>>>> Agenda:
>>>>> 1. Review of minutes of last meeting
>>>>>
>>>>> 2. Internal fragment ions
>>>>>
>>>>> 3. Ambiguous residues
>>>>>
>>>>> 4. Status of mapping document, CV and examples.
>>>>>
>>>>> 5. Please review the latest documentation:
>>>>>
>>>>> http://psi-
>> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr
>>>> aft.doc
>>>>>
>>>>> Dial in details:
>>>>>
>>>>> + Germany: 08001012079
>>>>> + Switzerland: 0800000860
>>>>> + UK: 08081095644
>>>>> + USA: 1-866-314-3683
>>>>> + Generic international: +44 2083222500 (UK number)
>>>>>
>>>>> access code: 297427
>>>>>
>>>> --
>>>> David Creasy
>>>> Matrix Science
>>>> 64 Baker Street
>>>> London W1U 7GB, UK
>>>> Tel: +44 (0)20 7486 1050
>>>> Fax: +44 (0)20 7224 1344
>>>>
>>>> dc...@ma...
>>>> http://www.matrixscience.com
>>>>
>>>> Matrix Science Ltd. is registered in England and Wales
>>>> Company number 3533898
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Psidev-pi-dev mailing list
>>>> Psi...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
>> --
>> David Creasy
>> Matrix Science
>> 64 Baker Street
>> London W1U 7GB, UK
>> Tel: +44 (0)20 7486 1050
>> Fax: +44 (0)20 7224 1344
>>
>> dc...@ma...
>> http://www.matrixscience.com
>>
>> Matrix Science Ltd. is registered in England and Wales
>> Company number 3533898
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Psidev-pi-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

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

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 26th November at 4:00pm UK time

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

Ah I missed this proposal. Are these are the only two mechanisms we need/want?
If so, we could just build the whole thing into the schema:

    <AmbiguousResidue Code="B" SubstituteResidues="D N"/>
   

   <AmbiguousResidue Code="Z">
      <AlternateResidue Mass="129.042593"/>
      <AlternateResidue Mass="128.058578"/>
    </AmbiguousResidue>

The downsides are if someone decides another mechanism is needed we cannot
extend this. Also, I'm not sure we can validate that only one mechanism or the
other is used (but this issue is the same whichever way we solve the problem).

In fact, do we need to allow it to be done both ways... Couldn't we just enforce
that it is done in the latter way, 

Cheers
Andy






> -----Original Message-----
> From: David Creasy [mailto:dc...@ma...]
> Sent: 27 November 2008 15:58
> To: Jones, Andy
> Cc: psi...@li...
> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday
> 26th November at 4:00pm UK time
> 
> Hi Andy
> 
> Jones, Andy wrote:
> > I have a query about something in the minutes:
> >
> > <MassTable is="MT1">
> >  <Residue Code="A" Mass="71.037114"/>
> >  ...
> >  <Residue Code="Y" Mass="163.063329"/>
> >
> >  <AmbiguousResidue Code="B">
> >    <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
> > cvRef="PSI-PI" value="DN"/>
> >  </AmbiguousResidue>
> >  <AmbiguousResidue Code="Z">
> >    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> > value="129.042593"/>
> >    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> > value="128.058578"/>
> >  </AmbiguousResidue>
> >  . . .
> > </MassTable>
> >
> >
> > I think we agreed that the value attribute above for "Alternate single
letter
> > codes" should be "D N" i.e. space separated chars, is this correct?
> Yes, this is what we agreed.
> 
> >
> > If so, I'm not sure if I was supposed to add this as documentation to the
XSD or
> > if we want to add this documentation to the CV term (the latter seems better
to
> > me).
> Adding it to the CV term seems better. However, Martin proposed a
> different approach in an email a little earlier today:
> 
> 
>  > What do you think about:?
> ...
>     <AmbiguousResidue Code="B" ResidueRef="D N"/>
>     <AmbiguousResidue Code="Z">
>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>   value="129.042593"/>
>       <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
>   value="128.058578"/>
>     </AmbiguousResidue>
> 
> ResidueRef can be type listOfChar.
> 
> Disadvantage is the mix of schema and CVParam mechanisms...
> ------------------
> 
> I don't have a preference either way. Any thoughts Andy?
> 
> David
> 
> >
> > Cheers, Andy
> >
> >
> >
> >> -----Original Message-----
> >> From: David Creasy [mailto:dc...@ma...]
> >> Sent: 27 November 2008 13:35
> >> To: psi...@li...
> >> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on
> Wednesday
> >> 26th November at 4:00pm UK time
> >>
> >> Minutes are here:
> >>
> >> http://psidev.info/index.php?q=node/395
> >>
> >> Most action items already done...
> >>
> >>
> >>
> >> David Creasy wrote:
> >>> Hi everyone,
> >>>
> >>> There will be an AnalysisXML working group conference call on WEDNESDAY
> >>> (instead of Thursday, because it is Thanksgiving in the US) at:
> >>>
> >>
> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2
> >> 008&hour=16&min=0&sec=0&p1=136
> >>>
> >>> Minutes, including action items ;) from last meeting at:
> >>> http://psidev.info/index.php?q=node/392
> >>>
> >>> Agenda:
> >>> 1. Review of minutes of last meeting
> >>>
> >>> 2. Internal fragment ions
> >>>
> >>> 3. Ambiguous residues
> >>>
> >>> 4. Status of mapping document, CV and examples.
> >>>
> >>> 5. Please review the latest documentation:
> >>>
> >>> http://psi-
> >>
> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr
> >> aft.doc
> >>>
> >>>
> >>> Dial in details:
> >>>
> >>> + Germany: 08001012079
> >>> + Switzerland: 0800000860
> >>> + UK: 08081095644
> >>> + USA: 1-866-314-3683
> >>> + Generic international: +44 2083222500 (UK number)
> >>>
> >>> access code: 297427
> >>>
> >> --
> >> David Creasy
> >> Matrix Science
> >> 64 Baker Street
> >> London W1U 7GB, UK
> >> Tel: +44 (0)20 7486 1050
> >> Fax: +44 (0)20 7224 1344
> >>
> >> dc...@ma...
> >> http://www.matrixscience.com
> >>
> >> Matrix Science Ltd. is registered in England and Wales
> >> Company number 3533898
> >>
> >> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Psidev-pi-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> 
> --
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
> 
> dc...@ma...
> http://www.matrixscience.com
> 
> Matrix Science Ltd. is registered in England and Wales
> Company number 3533898
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 26th November at 4:00pm UK time

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

Hi Andy

Jones, Andy wrote:
> I have a query about something in the minutes:
> 
> <MassTable is="MT1">
>  <Residue Code="A" Mass="71.037114"/>
>  ...
>  <Residue Code="Y" Mass="163.063329"/>
> 
>  <AmbiguousResidue Code="B">
>    <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
> cvRef="PSI-PI" value="DN"/>
>  </AmbiguousResidue>
>  <AmbiguousResidue Code="Z">
>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> value="129.042593"/>
>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> value="128.058578"/>
>  </AmbiguousResidue>
>  . . .
> </MassTable>
> 
> 
> I think we agreed that the value attribute above for "Alternate single letter
> codes" should be "D N" i.e. space separated chars, is this correct?
Yes, this is what we agreed.

> 
> If so, I'm not sure if I was supposed to add this as documentation to the XSD or
> if we want to add this documentation to the CV term (the latter seems better to
> me).
Adding it to the CV term seems better. However, Martin proposed a 
different approach in an email a little earlier today:


 > What do you think about:?
...
    <AmbiguousResidue Code="B" ResidueRef="D N"/>
    <AmbiguousResidue Code="Z">
      <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
  value="129.042593"/>
      <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
  value="128.058578"/>
    </AmbiguousResidue>

ResidueRef can be type listOfChar.

Disadvantage is the mix of schema and CVParam mechanisms...
------------------

I don't have a preference either way. Any thoughts Andy?

David

> 
> Cheers, Andy
> 
> 
> 
>> -----Original Message-----
>> From: David Creasy [mailto:dc...@ma...]
>> Sent: 27 November 2008 13:35
>> To: psi...@li...
>> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday
>> 26th November at 4:00pm UK time
>>
>> Minutes are here:
>>
>> http://psidev.info/index.php?q=node/395
>>
>> Most action items already done...
>>
>>
>>
>> David Creasy wrote:
>>> Hi everyone,
>>>
>>> There will be an AnalysisXML working group conference call on WEDNESDAY
>>> (instead of Thursday, because it is Thanksgiving in the US) at:
>>>
>> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2
>> 008&hour=16&min=0&sec=0&p1=136
>>>
>>> Minutes, including action items ;) from last meeting at:
>>> http://psidev.info/index.php?q=node/392
>>>
>>> Agenda:
>>> 1. Review of minutes of last meeting
>>>
>>> 2. Internal fragment ions
>>>
>>> 3. Ambiguous residues
>>>
>>> 4. Status of mapping document, CV and examples.
>>>
>>> 5. Please review the latest documentation:
>>>
>>> http://psi-
>> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr
>> aft.doc
>>>
>>>
>>> Dial in details:
>>>
>>> + Germany: 08001012079
>>> + Switzerland: 0800000860
>>> + UK: 08081095644
>>> + USA: 1-866-314-3683
>>> + Generic international: +44 2083222500 (UK number)
>>>
>>> access code: 297427
>>>
>> --
>> David Creasy
>> Matrix Science
>> 64 Baker Street
>> London W1U 7GB, UK
>> Tel: +44 (0)20 7486 1050
>> Fax: +44 (0)20 7224 1344
>>
>> dc...@ma...
>> http://www.matrixscience.com
>>
>> Matrix Science Ltd. is registered in England and Wales
>> Company number 3533898
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Psidev-pi-dev mailing list
>> Psi...@li...
>> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

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

Matrix Science Ltd. is registered in England and Wales
Company number 3533898

Re: [Psidev-pi-dev] PSI-PI Working group conference call onWednesday 26th November at 4:00pm UK time

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

Minor schema update:

Changed datatype on "code" attribute of
AmbiguityGroup to psi-pi:chars (only
single letter code allowed now), previously was xsd:string.

Should not require any changes to instance
docs

> -----Original Message-----
> From: Jones, Andy [mailto:And...@li...]
> Sent: 27 November 2008 15:33
> To: David Creasy; psi...@li...
> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call onWednesday
> 26th November at 4:00pm UK time
> 
> I have a query about something in the minutes:
> 
> <MassTable is="MT1">
>  <Residue Code="A" Mass="71.037114"/>
>  ...
>  <Residue Code="Y" Mass="163.063329"/>
> 
>  <AmbiguousResidue Code="B">
>    <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
> cvRef="PSI-PI" value="DN"/>
>  </AmbiguousResidue>
>  <AmbiguousResidue Code="Z">
>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> value="129.042593"/>
>    <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
> value="128.058578"/>
>  </AmbiguousResidue>
>  . . .
> </MassTable>
> 
> 
> I think we agreed that the value attribute above for "Alternate single letter
> codes" should be "D N" i.e. space separated chars, is this correct?
> 
> If so, I'm not sure if I was supposed to add this as documentation to the XSD
or
> if we want to add this documentation to the CV term (the latter seems better
to
> me).
> 
> Cheers, Andy
> 
> 
> 
> > -----Original Message-----
> > From: David Creasy [mailto:dc...@ma...]
> > Sent: 27 November 2008 13:35
> > To: psi...@li...
> > Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on
> Wednesday
> > 26th November at 4:00pm UK time
> >
> > Minutes are here:
> >
> > http://psidev.info/index.php?q=node/395
> >
> > Most action items already done...
> >
> >
> >
> > David Creasy wrote:
> > > Hi everyone,
> > >
> > > There will be an AnalysisXML working group conference call on WEDNESDAY
> > > (instead of Thursday, because it is Thanksgiving in the US) at:
> > >
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2
> > 008&hour=16&min=0&sec=0&p1=136
> > >
> > >
> > > Minutes, including action items ;) from last meeting at:
> > > http://psidev.info/index.php?q=node/392
> > >
> > > Agenda:
> > > 1. Review of minutes of last meeting
> > >
> > > 2. Internal fragment ions
> > >
> > > 3. Ambiguous residues
> > >
> > > 4. Status of mapping document, CV and examples.
> > >
> > > 5. Please review the latest documentation:
> > >
> > > http://psi-
> >
> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr
> > aft.doc
> > >
> > >
> > >
> > > Dial in details:
> > >
> > > + Germany: 08001012079
> > > + Switzerland: 0800000860
> > > + UK: 08081095644
> > > + USA: 1-866-314-3683
> > > + Generic international: +44 2083222500 (UK number)
> > >
> > > access code: 297427
> > >
> >
> > --
> > David Creasy
> > Matrix Science
> > 64 Baker Street
> > London W1U 7GB, UK
> > Tel: +44 (0)20 7486 1050
> > Fax: +44 (0)20 7224 1344
> >
> > dc...@ma...
> > http://www.matrixscience.com
> >
> > Matrix Science Ltd. is registered in England and Wales
> > Company number 3533898
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Psidev-pi-dev mailing list
> > Psi...@li...
> > https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday 26th November at 4:00pm UK time

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

I have a query about something in the minutes:

<MassTable is="MT1">
 <Residue Code="A" Mass="71.037114"/>
 ...
 <Residue Code="Y" Mass="163.063329"/>

 <AmbiguousResidue Code="B">
   <pf:cvParam accession="PI:xxxx" name="Alternate single letter codes"
cvRef="PSI-PI" value="DN"/>
 </AmbiguousResidue>
 <AmbiguousResidue Code="Z">
   <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
value="129.042593"/>
   <pf:cvParam accession="PI:yyyy" name="Alternate mass" cvRef="PSI-PI"
value="128.058578"/>
 </AmbiguousResidue>
 . . .
</MassTable>


I think we agreed that the value attribute above for "Alternate single letter
codes" should be "D N" i.e. space separated chars, is this correct?

If so, I'm not sure if I was supposed to add this as documentation to the XSD or
if we want to add this documentation to the CV term (the latter seems better to
me).

Cheers, Andy



> -----Original Message-----
> From: David Creasy [mailto:dc...@ma...]
> Sent: 27 November 2008 13:35
> To: psi...@li...
> Subject: Re: [Psidev-pi-dev] PSI-PI Working group conference call on Wednesday
> 26th November at 4:00pm UK time
> 
> Minutes are here:
> 
> http://psidev.info/index.php?q=node/395
> 
> Most action items already done...
> 
> 
> 
> David Creasy wrote:
> > Hi everyone,
> >
> > There will be an AnalysisXML working group conference call on WEDNESDAY
> > (instead of Thursday, because it is Thanksgiving in the US) at:
> >
> http://www.timeanddate.com/worldclock/fixedtime.html?day=26&month=11&year=2
> 008&hour=16&min=0&sec=0&p1=136
> >
> >
> > Minutes, including action items ;) from last meeting at:
> > http://psidev.info/index.php?q=node/392
> >
> > Agenda:
> > 1. Review of minutes of last meeting
> >
> > 2. Internal fragment ions
> >
> > 3. Ambiguous residues
> >
> > 4. Status of mapping document, CV and examples.
> >
> > 5. Please review the latest documentation:
> >
> > http://psi-
> pi.googlecode.com/svn/trunk/specification_document/analysisXML_SpecificationDr
> aft.doc
> >
> >
> >
> > Dial in details:
> >
> > + Germany: 08001012079
> > + Switzerland: 0800000860
> > + UK: 08081095644
> > + USA: 1-866-314-3683
> > + Generic international: +44 2083222500 (UK number)
> >
> > access code: 297427
> >
> 
> --
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
> 
> dc...@ma...
> http://www.matrixscience.com
> 
> Matrix Science Ltd. is registered in England and Wales
> Company number 3533898
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Psidev-pi-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-pi-dev

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #41 on issue 42 by eisenachM: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

With OBOEdit 1.101 I cannot edit the obo file (OBOEdit does not show its  
GUI but the
process is there and locks the file).

Reason are the two
relationship: has_units: UO:0000XXX ! name
lines added in revision 273

I had to delete them in a text editor, edit with OBOEdit, then add them  
again with a
text editor :-(


-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #40 on issue 42 by eisenachM: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

changed obo according to comments 32-35
(for comment 33 I removed the " if a significant and fragment includes  
RKNQ." etc.
from the defline)
(for comment 27b I added a term "number of unmacthed peaks")

TODOs left:
- Newt.obo
- add 2nd parent for Paragon scores (Sean)
- decide comments 37 / 38


-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[Psidev-pi-dev] Issue 42 in psi-pi: Issues with the CV

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

Comment #39 on issue 42 by dcreasy: Issues with the CV
http://code.google.com/p/psi-pi/issues/detail?id=42

Interesting points Matt, and useful to have feedback from your mzML  
experience.
When the input to the search is an mzML file, our spectrumID attribute is  
the mzML
spectrum 'id'. This is 'easy' and a majority of people agreed at an earlier  
meeting
that if you want further information like retention time, you need to go  
back to the
mzML file.

When the input to the search engine is an mgf file, things are not so easy,  
because
different people use the title, scans and rtinseconds fields in different  
ways. Also,
as you say, there is no guarantee that any of these are unique. In a case  
where
someone has provided say the rtinseconds, but not a title, it would be  
useful to
report this and to make it clear which of the possible values is being  
reported.

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

btw, in case it's not clear, we don't currently have a nativeID attribute  
for the
<SpectrumIdentificationResult>

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

We are trying to not use userParams too much in analysisXML because we are  
keen to
make the most of the cv validation tools.

So, I realise it's far from ideal, but I think what I'm proposing makes the  
best of a
far from ideal situation. Or maybe I'm missing something?

-- 
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings