Re: [SO-devel] GFF3 specification - qualifiers for Ontology_term IDs?

[Scott C. <cai...@gm...>]

Hi Josh,

No, it just sat there in my inbox doing nothing :-)  What do you think
about the attached patch for the GFF3 spec?

Scott

 

On Fri, 2007-07-06 at 14:22 -0400, Josh Goodman wrote:
> Hi Scott,
> 
> Do you know if anything has happened with this?  We are preparing for a new
> release in the next few weeks and I'd like to have the GFF files in place with
> this spec change by then.
> 
> Thanks,
> Josh
> 
> 
> Scott Cain wrote:
> > Hi Josh,
> > 
> > From a parsing perspective, I would rather have ! than not() (the regex
> > is easier).  Assuming there are no disagreements, we can ask Lincoln to
> > add it to the spec.
> > 
> > Scott
> > 
> > 
> > On Tue, 2007-06-05 at 11:25 -0400, Josh Goodman wrote:
> >> Hi Scott,
> >>
> >> I discussed this with the people who are concerned with GO here and we seem to
> >> be in agreement with only going forward with the negation operator.
> >>
> >> Thus far we have 2 proposals
> >>
> >> Ontology_term=not(GO:0001234)
> >> or
> >> Ontology_term=!GO:0001234
> >>
> >> What needs to happen next in order to get one or the other moved into the
> >> approved spec?
> >>
> >> Thanks,
> >> Josh
> >>
> >> Scott Cain wrote:
> >>> Hi,
> >>>
> >>> It was support for expressing NOT in GFF3 that had me fairly adamant
> >>> that something had to be done--I am less worried about modifiers, though
> >>> I could see that it would be nice to support some.
> >>>
> >>> If we were to indicate that all we wanted to support was NOT, it would
> >>> be fairly easy to say that the syntax should be the addition of a '!'
> >>> somewhere, like
> >>>
> >>>   Ontology_term=!GO:0001234
> >>>
> >>> Perhaps the should be the syntax for NOT regardless of what else happens
> >>> with modifiers.
> >>>
> >>> Scott
> >>>
> >>>
> >>> On Mon, 2007-06-04 at 09:00 +0100, Rachel Drysdale (Genetics) wrote:
> >>>> Hi,
> >>>>
> >>>>> You can be guaranteed that, programmers being lazy, qualifiers will  
> >>>>> be dropped, so don't treat NOT like a qualifier. It's far better to  
> >>>>> simply omit the annotation altogether.
> >>>> Just a clarification about the NOTs - the NOTs are in fact _positive_
> >>>> statements as Chris said later on
> >>>>> 	negated_annotation := 'NOT(' positive_annotation ')'
> >>>> and are used to indicate that this term does not apply when, for
> >>>> example, sequence motif or whatever might have indicated that it should
> >>>> apply (i.e. things that look like DNA binding domains, but where the
> >>>> protein has been shown, experimentally, to NOT bind DNA)
> >>>>
> >>>> Rachel.
> >>>>
> >>>>> Cc: Susan Tweedie <sa...@ge...>, FlyBase developers 
> >>>> <al...@mo...>
> >>>>> Content-Transfer-Encoding: 7bit
> >>>>> From: Chris Mungall <cj...@fr...>
> >>>>> Subject: Re: [SO-devel] GFF3 specification - qualifiers for Ontology_term	
> >>>> IDs?
> >>>>> Date: Fri, 1 Jun 2007 14:07:27 -0700
> >>>>> To: cai...@gm..., SO developers <son...@li...>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Jun 1, 2007, at 1:28 PM, Scott Cain wrote:
> >>>>>
> >>>>>> Hi Josh and all,
> >>>>>>
> >>>>>> So what we need to do (and I agree that it is needed), is to extend  
> >>>>>> the
> >>>>>> GFF3 spec to allow for modifiers.  Currently, the GFF3 spec for both
> >>>>>> Ontology_term and Dbxref says that the values are of the form
> >>>>>> 'DBTAG:ID', like GO:0000123 and gi:1234567.  The most obvious  
> >>>>>> extension
> >>>>>> I can think of would be to add another, optional, field, like this:
> >>>>>> 'DBTAG:ID:modifier', so you could have GO:0000123:NOT or
> >>>>>> SO:000123:contributes_to (not that I really know what that means :-)
> >>>>> (it's meaningless)
> >>>>>
> >>>>> OK, then next you want the evidence & evidence code. Then provenance  
> >>>>> (eg pubmedID). Then the annotation source...
> >>>>>
> >>>>> Is gff really up to this?
> >>>>>
> >>>>> If you really want to do this, I'd urge you to come up with a formal  
> >>>>> grammar that is extensible. Otherwise just accept the fact that gff  
> >>>>> is a lossy format outside its core domain, locating features of  
> >>>>> sequences.
> >>>>>
> >>>>> NOT should be treated with care. Although "NOT" is commonly referred  
> >>>>> to as a qualifier or modifier, it isn't, it's an operator (the GO  
> >>>>> docs need fixed here). The dictionary definitions of qualify and  
> >>>>> modify include:
> >>>>>
> >>>>> 	to reduce from a general, undefined, or comprehensive to a  
> >>>>> particular or restricted form
> >>>>> 	to make more temperate and less extreme
> >>>>> 	to limit or restrict the meaning of
> >>>>> 	to make minor changes in the form or structure of
> >>>>>
> >>>>> None of these apply to taking a statement and negating its truth  
> >>>>> value (within some context)
> >>>>>
> >>>>> You would expect to be able to drop a modifier or qualifier and  
> >>>>> suffer only a loss of specificity. But if you drop the NOT operator  
> >>>>> then your statements become wrong.
> >>>>>
> >>>>> You can be guaranteed that, programmers being lazy, qualifiers will  
> >>>>> be dropped, so don't treat NOT like a qualifier. It's far better to  
> >>>>> simply omit the annotation altogether.
> >>>>>
> >>>>> If you do include it, I would say include it in such a way that its  
> >>>>> status as an operator is unambiguous and you are automatically  
> >>>>> defended against lax parsers. For example:
> >>>>>
> >>>>> 	negated_annotation := 'NOT(' positive_annotation ')'
> >>>>> 	positive_annotation := id
> >>>>>
> >>>>> Cheers
> >>>>> Chris
> >>>>>
> >>>>>
> >>>>>> Any other suggestions?
> >>>>>> Scott
> >>>>>>
> >>>>>>
> >>>>>> On Fri, 2007-06-01 at 15:07 -0400, Josh Goodman wrote:
> >>>>>>> Hello song-devel,
> >>>>>>>
> >>>>>>> FlyBase would like to know if anyone has given any thought on how  
> >>>>>>> to deal with
> >>>>>>> qualifiers for terms in the Ontology_term section of GFF v3?  At  
> >>>>>>> FlyBase we
> >>>>>>> currently represent GO terms that have been associated with genes  
> >>>>>>> in our gene
> >>>>>>> feature lines.  Since all terms have to be presented in the same  
> >>>>>>> manner,
> >>>>>>> according to the specification, we have to strip out term qualifiers..
> >>>>>>> Qualifiers we are currently dropping include contributes_to,  
> >>>>>>> colocalizes_with,
> >>>>>>> and NOT.  This can obviously completely change the meaning of  
> >>>>>>> terms and cause
> >>>>>>> trouble for data miners who rely on this data.  A quick survey of  
> >>>>>>> a few other
> >>>>>>> MODs shows that this problem exists elsewhere as well.
> >>>>>>>
> >>>>>>> We would like continue to include GO terms in our GFF files, but  
> >>>>>>> if we can't
> >>>>>>> implement them with qualifiers in a standard way that 3rd party  
> >>>>>>> GFF loaders can
> >>>>>>> deal with, we will probably remove them all together.  We will  
> >>>>>>> still have this
> >>>>>>> information in our gene_association.fb file, but it is nice to  
> >>>>>>> have it in the
> >>>>>>> context of our GFF files.
> >>>>>>>
> >>>>>>> A secondary and less important topic that we wanted to bring up  
> >>>>>>> for possible
> >>>>>>> discussion is implementing evidence source (PMID), evidence codes,  
> >>>>>>> and
> >>>>>>> supporting Dbxrefs (UniProt, GenBank IDs, etc...) for these  
> >>>>>>> terms.  Do others
> >>>>>>> think this would be worth while or would the cost of implementing  
> >>>>>>> them outweigh
> >>>>>>> any gains?
> >>>>>>>
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Josh
> >>>>>>> FlyBase
> >>>>>>>
> >>>>>>> --------------------------------------------------------------------- 
> >>>>>>> ----
> >>>>>>> This SF.net email is sponsored by DB2 Express
> >>>>>>> Download DB2 Express C - the FREE version of DB2 express and take
> >>>>>>> control of your XML. No limits. Just data. Click to get it now.
> >>>>>>> http://sourceforge.net/powerbar/db2/
> >>>>>>> _______________________________________________
> >>>>>>> SOng-devel mailing list
> >>>>>>> SOn...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/song-devel
> >>>>>> -- 
> >>>>>> ---------------------------------------------------------------------- 
> >>>>>> --
> >>>>>> Scott Cain, Ph. D.                                          
> >>>>>> ca...@cs...
> >>>>>> GMOD Coordinator (http://www.gmod.org/)                      
> >>>>>> 216-392-3087
> >>>>>> Cold Spring Harbor Laboratory
> >>>>>> ---------------------------------------------------------------------- 
> >>>>>> ---
> >>>>>> This SF.net email is sponsored by DB2 Express
> >>>>>> Download DB2 Express C - the FREE version of DB2 express and take
> >>>>>> control of your XML. No limits. Just data. Click to get it now.
> >>>>>> http://sourceforge.net/powerbar/db2/ 
> >>>>>> _______________________________________________
> >>>>>> SOng-devel mailing list
> >>>>>> SOn...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/song-devel
-- 
------------------------------------------------------------------------
Scott Cain, Ph. D.                                   cai...@gm...
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory