Re: [Psidev-ms-dev] Difference between purgatory / obsolete

[Eric D. <ede...@sy...>]

This is indeed correct. Many terms in purgatory are perfectly reasonable
terms sometimes with good definitions, but are just unneeded by mzML. As
we move forward in tidying up our CV, all terms in purgatory should either
be moved to a correct location in the hierarchy and updated as appropriate
OR obsoleted. There are a number of terms in purgatory that should be
obsoleted, but some are good. What we lack is someone with the time to go
through and clean this all up. The ASMS folks might help us out with this.
Other volunteers are most welcome.

Regards,
Eric


> -----Original Message-----
> From: Matthew Chambers [mailto:mat...@va...]
> Sent: Thursday, April 08, 2010 7:45 AM
> To: psi...@li...
> Subject: Re: [Psidev-ms-dev] Difference between purgatory / obsolete
>
> We used purgatory as a development limbo. We may be at a sufficient
> stage of release where we can delete the purgatory terms entirely
> (which
> we will never do to properly obsoleted terms). I don't think purgatory
> and obsoletion should be considered overlapping concepts. I don't
> recall
> that there should be any mzML documents at or after 1.0 which use terms
> that are now in purgatory. I'd say a term that was NOT in purgatory in
> the 1.0 mapping file may be obsolete now, but it shouldn't be in
> purgatory.
>
> I think of supporting obsoletion like deprecation in a programming API.
> At some point in the future, support for those documents may be
> stopped.
> Perhaps we should have at least one converter which could upgrade the
> documents to replace the obsolete terms if the term has an official
> "replaced by" comment (or tag) and to delete the ones that were
> eliminated entirely. Or possibly handle those on a case by case basis
> (like when isolation window semantics changed from "lower bound/upper
> bound" to "target m/z/lower offset/upper offset").
>
> -Matt
>
>
> On 4/8/2010 3:32 AM, Steffen Neumann wrote:
> > Hi,
> >
> > I didn't come across a halfway formal definition / distinction
> between
> > OBSOLETE'ing stuff, and moving it to purgatory, although we had
> > a thread on this here last year ("Marking CV terms obsolete")
> >
> > Also I'd expect some process to make sure that stuff
> > shoved into purgatory really should be obsoleted at some stage.
> >
> > This has also implications on the validity of instance documents,
> > because files which have some cvParam which IS_A "something"
> > (where "something" is a MUST) are invalid once the cvParam
> > is moved from "something" to "purgatory", *unless it also retains*
> > the original IS_A "something".
> >
> > I found (grep -B 1 -A 1 "MS:1000479 ! purgatory" psi-ms.obo)
> > that there are Terms with a mix of:
> >
> > 	relationship: part_of MS:1000479 ! purgatory
> > 	is_obsolete: true
> >
> > 	relationship: part_of MS:1000479 ! purgatory
> > 	without is_obsolete
> >
> > 	is_a: MS:1000479 ! purgatory
> > 	without is_obsolete
> >
> > So:
> >
> > 1) Why do we use purgatory in first place ?
> >
> > 2) Do we want a policy whether and how the CV is cleansed
> >     and purgatory stuff marked OBSOLETE ?
> >
> > 3) How do we handle documents which become invalid
> >     with these changes ?
> >
> > 4) Should these definitions/processes
> >     become part of the spec documents ?
> >
> > Yours,
> > Steffen
> >
> >
>
> -----------------------------------------------------------------------
> -------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Psidev-ms-dev mailing list
> Psi...@li...
> https://lists.sourceforge.net/lists/listinfo/psidev-ms-dev