[Hackathon] Re: [Bioperl-l] proposed change to
lstein at cshl.edu
Wed Jun 18 17:57:14 EDT 2003
The idea for GFF3 is that the third column becomes controlled by an ontology
AND is used as the primary_tag. I guess this implies that the primary_tag
becomes controlled by an ontology. The aggregator/fluffer/unflattener should
be able to look at the primary tags of a bunch of seqfeature primitives and
turn them into the right structure.
BTW, the second column, the "source" is still unconstrained. I tend to think
of this as some sort of private qualifier on the primary tag that you can use
col 2 col 3
On Wednesday 18 June 2003 12:47 pm, Mark Wilkinson wrote:
> On Wed, 2003-06-18 at 10:30, David Block wrote:
> > If I could just jump in here, :-)
> > We didn't have the SO at the time. I think it's clear from both
> > Mark's work and mine (Hilmar can vouch for me) that the Genquire
> > people were not opposed to ontologies in principle - rather, we were
> > ahead of the tools.
> Well... the problem was bigger than that. For example, as I recall,
> when Bioperl parses e.g. GFF, it takes the third column ('featurename')
> and assigns that to the primary_tag. There are no rules about what is
> allowed in that field in GFF, so if Bioperl is going to assume that this
> tag has some implicit additional meaning (other than just an arbitrary
> string representing the name) then you should not be using that column
> as the primary tag. The fact that it does strongly implies that the
> primary_tag value *should not* be interpreted. Thus, since we couldn't
> safely put any meaning into primary_tag, we needed to put that meaning
> into the object's @ISA.
> If primary_tag is now going to be linked to an ontology I will be
> thrilled, but then it does change the "meaning" of that tag... and in
> fact, it might be nicer for primary_tag to then return an ontology Node
> object of some sort, rather than just a string...
> > Please break everything - Mark is paying a summer student to fix
> > Genquire anyway :-)
> Two, in fact!! :-)
> I'm actually quite shocked at how well Genquire has survived the changes
> in Bio::SeqI, which now implements all sorts of new interfaces that
> didn't exist when we originally wrote Genquire. One of the students is
> now implementing those interfaces in the Genquire::Seq objects and then
> we should be able to import any datatype that BioPerl supports, do
> many/most Bioperl Seq and Seqfeature manipulations using the Genqurie
> GUI, and write-out in any datatype that BioPerl supports (or write out
> to the db). I am hoping that we can resurrect interest in Genquire once
> this is done.
> > And thanks, Chris, for your GenbankWhateverUnFlattener code. Someone
> > had to try, and Mark and I kept thinking about it. We're happy to let
> > you guys do it.
> yeah... I thought about it for a while, and my hair went white... I'm
> really happy that it is done! thanks!!
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein at cshl.org Cold Spring Harbor, NY
More information about the Bioperl-l