Re: [Psidev-ms-dev] Associating CV / ontology annotations

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Phil,

dataRDF, anyone?  ;-)

It was late here when I read your first message.  At this point there is
really only one mechanism whereby you could nest/chain params.  This
comes by virtue of the fact that one of the element types allowed in the
sequence under paramGroup is paramGroupRef, whose ref attribute holds
the id of the of the paramGroup being referred to.  You could also put
in a userParam with a name or whatever to give it semantic "labeling"
for your particular purpose.   Any combination of lists, trees, etc. of
linked param structure could be made, but as you imply, it can become a
semantic wild west, so to speak.

So we put in a structure that would be an improvement over the existing
userParam/cvParam scheme while not being a brick wall for more creative
uses.  I think the real answer will only come when we are able to
specify the computationally (i.e. implemented in software) mapping
between a semantic structure in OBO/OWL/RDF (conforming to restrictions
dictated by the standard's specifications/governance). I think this area
should be a focus in the upcoming spring meeting.

As always, good to hear from you Phil,  a voice of reason and
pragmatism.

Regards,

Kent

> -----Original Message-----
> From: Philip Jones [mailto:pj...@eb...]=20
> Sent: Wednesday, February 28, 2007 5:14 AM
> To: Kent Laursen; psi...@li...
> Subject: Re: [Psidev-ms-dev] Associating CV / ontology annotations
>=20
> Hi Kent,
>=20
> I have taken a closer look at the ParamGroup and=20
> ParamGroupList elements as you suggested.
>=20
> These elements work extremely well for defining common /=20
> default sets of params that will be repeated identically for=20
> multiple annotations and as I recall this was their original purpose.
>=20
> I do not think however that they solve the problem I=20
> described in my previous email, for two reasons.
>=20
> First of all, taking the instance document located at
> http://psidev.sourceforge.net/docstore/download.php?&id=3D121=20
> as an example, you can put any combination of cvParams into a=20
> ParamGroup element.  The semantics of their association in=20
> this element is not defined, so they could be grouped=20
> together simply because they are a set of default values, as=20
> in the example instance document, or they could be grouped=20
> together because one param is an annotation of the other,=20
> which is the use case I described in my email.  There is no=20
> attribute or other mechanism to indicate which of these two=20
> cases is being described.
>=20
> Secondly, take the situation that the file contains a=20
> thousand spectra. =20
> You wish to annotate each spectrum with different=20
> information, but in each case you wish to use two or more=20
> associated cvParams for the annotation.  If you use the=20
> ParamGroupList for this purpose, you would end up with a=20
> thousand isolated ParamGroup elements at the top of the file=20
> that would need to be cross referenced from the spectrum elements. =20
> This would create problems for parsers that would need to=20
> either hop backwards and forwards in the file or store the=20
> details of all of the ParamGroup elements before parsing the=20
> spectrum elements.
>=20
> Best regards,
>=20
> Phil.
>=20
> Kent Laursen wrote:
> > Hi Phil,
> >
> > Have a closer look at the ParamGoup and ParamGroupList types.  They=20
> > were designed with this sort of flexibility and=20
> aggregability in mind.
> >
> > Regards,
> >
> > Kent
> >
> >  =20
> >> -----Original Message-----
> >> From: psi...@li...
> >> [mailto:psi...@li...] On Behalf Of=20
> >> Philip Jones
> >> Sent: Tuesday, February 27, 2007 1:18 PM
> >> To: psi...@li...
> >> Subject: [Psidev-ms-dev] Associating CV / ontology annotations
> >>
> >> Hi,
> >>
> >> I would like to suggest that it may be useful to include a=20
> mechanism=20
> >> to associate cvParam elements together to allow more complex=20
> >> annotation of entities in dataXML.  Here is an artificial=20
> example to=20
> >> illustrate the
> >> problem:
> >>
> >> <activation>
> >>     <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044" =
name=3D"Method"=20
> >> value=3D"CID"/>
> >>     <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20
> >> name=3D"CollisionEnergy" value=3D"35.00"/>
> >>     <cvParam cvLabel=3D"UO" accession=3D"UO:0000112"=20
> >> name=3D"Joule"/> </activation>
> >>
> >> In this example, the third CV parameter is an annotation of the=20
> >> second, indicating the units of the value of collision energy from=20
> >> the OBO unit ontology. (I know that collision energy is normally=20
> >> measured in eV, but eV is not in the UO ontology ! .... Just an=20
> >> example.)
> >>
> >> So the question is, do we need this mechanism and if so, how do we=20
> >> implement it?
> >>
> >>  From my point of view, I think it is needed.  I have wanted to be=20
> >> able to do this on numerous occasions when creating PRIDE=20
> entries for=20
> >> submissions - PRIDE uses the existing mzData schema=20
> cvParam mechanism=20
> >> for annotation.
> >>
> >> I think this could / should be kept simple.  It would be easy to=20
> >> allow an arbitrarily complex hierarchy of terms to be=20
> created, but I=20
> >> think that might result in chaos.
> >>
> >> Two possible solutions:
> >>
> >> 1. Perhaps just add an optional attribute to allow associated=20
> >> cvParams to be linked, e.g. with a number or perhaps=20
> something more=20
> >> guaranteed to be unique, like an LSID?
> >>
> >> 2. Perhaps add a single additional layer to the hierarchy,=20
> something=20
> >> like this:
> >>
> >> <activation>
> >>     <annotation>
> >>         <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000044"=20
> name=3D"Method"=20
> >> value=3D"CID"/>
> >>     </annotation>
> >>     <annotation>
> >>         <cvParam cvLabel=3D"PSI" accession=3D"PSI:1000045"=20
> >> name=3D"CollisionEnergy" value=3D"35.00"/>
> >>         <cvParam cvLabel=3D"UO" accession=3D"UO:0000112" =
name=3D"Joule"/>
> >>     </annotation>
> >> </activation>
> >>
> >> Best regards,
> >>
> >> Phil.
> >>
> >> --
> >> _______________________________________
> >> Phil Jones
> >> Software Engineer
> >> PRIDE Project Team
> >> Sequence Database Group
> >> EMBL-EBI
> >> Wellcome Trust Genome Campus
> >> Hinxton
> >> Cambridge
> >> CB10 1SD
> >> UK
> >>
> >> Tel +44 (0)1223 492 610 (Direct Line) mailto:pj...@eb...
> >>
> >>
> >> --------------------------------------------------------------
> >> -----------
> >> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> >> SourceForge.net's Techsay panel and you'll get the chance to=20
> >> share your opinions on IT & business topics through brief=20
> >> surveys-and earn cash=20
> >> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
> >>    =20
> > &CID=3DDEVDEV
> >  =20
> >> _______________________________________________
> >> Psidev-ms-dev mailing list
> >> Psi...@li...
> >> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev
> >>
> >>    =20
>=20
>=20
> --=20
> _______________________________________
> Phil Jones
> Software Engineer
> BioSapiens / PRIDE Project Team
> Sequence Database Group
> EMBL-EBI
> Wellcome Trust Genome Campus
> Hinxton
> Cambridge
> CB10 1SD
> UK
>=20
> Tel +44 (0)1223 492 610 (Direct Line)
> mailto:pj...@eb...
>=20
>=20