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

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

Huh!  I just repeated the syntax from the other examples, but now see
that they were wrong.  There should not be double quotes at all; you are
quite right.

I've attached a new diff with the quotes removed from all of the
examples.

Scott


On Fri, 2007-07-06 at 15:48 -0400, Josh Goodman wrote:
> Hi Scott,
> 
> After staring at your diff for a bit the presence of double quotes around the
> DBTAG-ID examples jumped out at me.  Do you think new users might interpret the
> examples to mean that the quotes are explicit and need to be in the GFF file?
> Other than this minor point it looks good to me.
> 
> Thanks,
> Josh
> 
> Scott Cain wrote:
> > 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
> 
> -------------------------------------------------------------------------
> 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