Re: [Psidev-pi-dev] Fragmentation Ions

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

> Well, notice I use "values" instead of "value" (but that wasn't
> intentional, hehe). We could either use the value attribute we get from
> subclassing, or add a new attribute that is more specific (like
> "seriesIndexList" or something).

Y I think either of these options would be fine. I would marginally favour adding, say, seriesIndex = "" then we can add a list datatype and specific documentation for the attribute in the XSD.


> > I don't even know what an immonium ion is so I don't want to have to sign off on
> a perfect list of all ion types in the analysisXML documentation! By using ontology
> terms we can leave flexibility in there so that implementers can report whatever ion
> types they like. IMO being as compact as possible is not really a big deal?
> >
> Yes, those ion types are troublesome to represent in a label. How will
> that be done in the CV? In other words, the same question applies to the
> cvParam approach. :) But your point about having to have universal
> agreement up front is a good one. Yet, if we DON'T have agreement up
> front about ion types, will that mean we start getting requests for
> obscure, vendor-specific ion types as CV terms? Or will we see
> userParams used there instead? It's not clear to me exactly how the CV
> approach solves the up front agreement issue either (at least, not
> without creating its own issues).

I think the PSI cv should contain the main ion types (b / y, neutral losses etc) with definitions. For the rest, I was thinking obscure vendor specific terms was the way to go i.e. not my problem :-) I just want to focus on getting the XSD over the line into version 1 state. CV terms can evolve as and when they are needed but once the spec doc is fixed at version 1 we don't want to have to touch it again!

Cheers
Andy





> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: 01 August 2008 16:21
> To: Jones, Andy
> Cc: psi...@li...
> Subject: Re: [Psidev-pi-dev] Fragmentation Ions
> 
> Hi Andy,
> 
> 
> Jones, Andy wrote:
> > Hi Matt,
> >
> >
> >> I'm (still) not sure what the use case is for all the "extra"
> >> measurements that seem to me to be redundant with the label, but if
> >> reporting those is the decision of the implementor, I'm happy with
> >> having that capability.
> >>
> > On the call, it was discussed that some implementers may wish to report
> additional scores associated with particular peaks e.g. why a particular peak was
> identified as a particular ion (for example related to the abundance of an adjacent
> peak). I think this is a niche use case but this proposal would allow it to be done.
> Also see the other values in comment 5 of issue 28 e.g. product ion m/z error
> >
> I can see the use of being able to report additional scores on a per
> peak basis, although I don't personally know how to use that information. :)
> 
> 
> >> My modified proposal (with some extra compactness possible by opting to
> >> leave out the extra measurements):
> >>
> >>> <Fragmentation>
> >>>     <IonType cvLabel="Waters" accession="PLGS:00035" name="y ion"
> >>> values="1 2 3"/>
> >>>     <IonType cvLabel="Waters" accession="PLGS:00032" name="b ion"
> >>> values="4 5 6"/>
> >>> </Fragmentation>
> >>>
> > We can definitely do it this way in the XSD. The only minor advantage of doing it
> the other way is that the format (xsd:list) can be verified by an XML parser rather
> than relying on the validator software, either is fine though.
> >
> Well, notice I use "values" instead of "value" (but that wasn't
> intentional, hehe). We could either use the value attribute we get from
> subclassing, or add a new attribute that is more specific (like
> "seriesIndexList" or something). Even if we reuse CVParam's value, I
> would expect there to be some way of overriding the type of the
> inherited attribute? In any case, xsd:list isn't enough to semantically
> validate the series, because a list like "100 99999 2939439" is a valid
> xsd:list but obviously semantically crazy. :)
> 
> 
> >> Although even then, it's about 10 times less compact than the formatted
> >> attribute proposal, but which would only work by explicitly denying the
> >> storage of extra measurements. For reference, using the same conditions
> >> for my approximate calculations above, MyriMatch's output by the
> >> formatted attribute method would have about 1.5mb of fragmentation info.
> >>
> >>> fragmentEvidence="y1 y2 y3 b4 b5 b6"
> >>>
> >
> > Although initially I was in favour of this approach, it suffers from the problem that
> we have to decide now (in the schema documentation) on all ion types and
> definitions. I'm not even sure if there is universal agreement on what constitutes
> each ion type, see comment from David:
> >
> >
> >> "What about internal fragments, immonium ions, side chain cleavages?"
> >>
> >
> > I don't even know what an immonium ion is so I don't want to have to sign off on
> a perfect list of all ion types in the analysisXML documentation! By using ontology
> terms we can leave flexibility in there so that implementers can report whatever ion
> types they like. IMO being as compact as possible is not really a big deal?
> >
> Yes, those ion types are troublesome to represent in a label. How will
> that be done in the CV? In other words, the same question applies to the
> cvParam approach. :) But your point about having to have universal
> agreement up front is a good one. Yet, if we DON'T have agreement up
> front about ion types, will that mean we start getting requests for
> obscure, vendor-specific ion types as CV terms? Or will we see
> userParams used there instead? It's not clear to me exactly how the CV
> approach solves the up front agreement issue either (at least, not
> without creating its own issues).
> 
> -Matt