Menu
▾
▴
Re: [SO-devel] GFF3 specification - qualifiers for Ontology_term IDs?
|
From: Josh G. <jog...@in...> - 2007-07-06 19:48:32
|
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
|
