|
From: Mike C. <tu...@gm...> - 2007-08-08 16:24:34
|
On 8/8/07, Matt Chambers <mat...@va...> wrote:
> > This does require a CV class and some methods:
> > cv.loadFromFile()
> > cv.isChildOf()
> > cv.getName()
> >
> > but this is not really complicated.
>
> But it is really relatively complicated. It is more conceptually and
> computationally complicated than simple string comparison (with the
> OPTION of checking the CV to see if the value is a controlled one). And
> worse, it's a complication I don't see a justification for unless there
> is a better reason than the one you gave above which has a more simple
> solution.
I agree with Matt. A call like "isChildOf" looks simple, but what's
entailed in that call is that the *correct* CV is available and has
been parsed into a tree in memory. There are good reasons to think
that this will be fairly difficult to do correctly in practice.
But on top of that, it just seems needlessly difficult. It'd be a
little like having products in your grocery store marked with their
trademark name, but not a succinct description of what they
*are*--which you can only find out with a stock list lookup.
("Shimmer? Is that a floor polish or a dessert topping? Hope my
stock list is up to date...")
The alternative here would appear to be very simple. Something like
the previously mentioned
<cvParam cvLabel="MS" accession="MS:1000031" name="instrument
model" value="LTQ-FT"/>
would work fine. As for the differing spellings of "LTQ-FT", there's
a canonical spelling available in the CV, and anyone that can't get
that right will probably find the complexity of multiple CV versions
insurmountable.
Consider also, how should newly created instruments be handled? If
our lab invents the "MassMaster2000", do we need to create our own
augmented CV in order to handle this? Does everyone who wants to read
MassMaster2000 mzML files need a copy of this augmented CV? What if
they have twenty other augmented CVs? How are those to be managed?
Mike
|