[Hackathon] Re: [Bioperl-l] proposed change to Bio::SeqFeature::Gene::*

[Lincoln Stein]

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 
like this:

	col 2		col 3

	my		exon
	your		exon
	genbank	exon

Lincoln

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!!
>
> Mark

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY
========================================================================