Dear Matt and Eric,
For me is fine the Eric's proposal (inlet properties inside the source
properties), as far as we keep in mind that the inlet can or cannot be
part of the source: that's why I proposed an alternate way of organizing
this. My only concern was having some property for an inlet incompatible
with the source but, after looking for examples, I must admit that were
somewhat bizarre...
Matt's argument about both being under the same XML element makes sense
to me. If nobody finds a reason to not doing this, I'll list this update
(hopefully tomorrow) in the new additions proposal.
Best,
David
On 01/06/2011 15:51, Eric Deutsch wrote:
> It would seem to me that often the inlet is a component of a source, and
> if an attribute is clearly an attribute of an inlet, then it would be tidy
> to classify it as such. However, from a practical use in mzML, it doesn't
> matter. So I would lean to the side of keeping them separate where it
> makes sense if David is willing to organize this. However, I don't feel
> very strongly either way.
>
> David, I am fine with your proposal if that's the way you'd like to
> organize it.
>
> We should remember that this will likely require a change to the mzML
> mapping file.
>
> Thanks,
> Eric
>
>
>> -----Original Message-----
>> From: Matthew Chambers [mailto:matt.chambers42@...]
>> Sent: Tuesday, May 31, 2011 12:25 PM
>> To: psidev-ms-dev@...
>> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 !
>> source
>>
>> Is there a good reason to separate "inlet attributes" from "source
>> attributes?" After all, they are
>> going under the same XML element (source).
>>
>> -Matt
>>
>>
>> On 5/31/2011 12:19 PM, David Ovelleiro wrote:
>>> Dear Steffen and Eric,
>>>
>>> At this moment I'm working in the "source" members.
>>> The problem here, as discussed in the PSI meeting in Heidelberg, is
>> that
>>> the distinction between a source and and inlet is not very clear in
>> some
>>> cases.
>>> Let's have one example:
>>> MS:1000055: continuous flow fast atom bombardment (defined as an
>> inlet)
>>> -> "Fast atom bombardment ionization in which the analyte in
>> solution is
>>> entrained in a flowing liquid matrix."
>>> MS:1000074: fast atom bombardment ionization (defined as a ionization
>>> type) -> "The ionization of any species by the interaction of a
>> focused
>>> beam of neutral atoms having a translational energy of several
>> thousand
>>> eV with a sample that is typically dissolved in a solvent matrix. See
>>> also secondary ionization."
>>>
>>> We found this kind of ambiguities. The problem is that depending on
>> the
>>> instrument design, in some cases, inlet and source are the same, or
>>> share components.
>>>
>>> Taking this into account, I'd propose an slightly different approach:
>>>
>>> [Term]
>>> id: MS:1000XXX
>>> name: inlet attribute
>>> def: "Property of an inlet device that needs a value." [PSI:MS]
>>> is_a: MS:1000458 ! source
>>>
>>> Here, the inlet attribute is son to source, at the same level than
>>> "source attribute". Doing this, in the cases that the inlet is
>> something
>>> completely different from the source, using an "inlet attribute"
>> outside
>>> the "source attribute" seems more correct to me....
>>>
>>> What do you think?
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> On 28/05/2011 13:09, Neumann, Steffen wrote:
>>>> Hi,
>>>>
>>>> yes, that's fine with me.
>>>>
>>>> Yours,
>>>> Steffen
>>>>
>>>> ________________________________________
>>>> From: Eric Deutsch [edeutsch@...]
>>>> Sent: 28 May 2011 08:05
>>>> To: Mass spectrometry standard development
>>>> Cc: Eric Deutsch
>>>> Subject: Re: [Psidev-ms-dev] ontology hierarchy below MS:1000458 !
>> source
>>>> Hi Steffen, this is a pretty messy situation. Maybe David would like
>> to
>>>> take this on sometime. For now, I think what you propose is fine,
>> except I
>>>> don't think the second relationship is useful, so just:
>>>>
>>>> [Term]
>>>> id: MS:1000XXX
>>>> name: inlet attribute
>>>> def: "Property of an inlet device that needs a value." [PSI:MS]
>>>> is_a: MS:1000482 ! source attribute
>>>>
>>>> Regards,
>>>> Eric
>>>>
>>>>
>>>> --------------------------------------------------------------------
>> ----------
>>>> vRanger cuts backup time in half-while increasing security.
>>>> With the market-leading solution for virtual backup and recovery,
>>>> you get blazing-fast, flexible, and affordable data protection.
>>>> Download your free trial now.
>>>> http://p.sf.net/sfu/quest-d2dcopy1
>>>> _______________________________________________
>>>> Psidev-ms-dev mailing list
>>>> Psidev-ms-dev@...
>>>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
>>>
>> -----------------------------------------------------------------------
>> -------
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is
>> safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> _______________________________________________
>> Psidev-ms-dev mailing list
>> Psidev-ms-dev@...
>> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psidev-ms-dev@...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
--
David Ovelleiro
Bioinformatician
PRIDE Group
Proteomics Services Team, PANDA Group
EMBL European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge, UK
CB10 1SD
|