Menu
▾
▴
Re: [SO-devel] GFF3 specification - qualifiers for Ontology_term IDs?
|
From: Josh G. <jog...@in...> - 2007-07-06 20:14:30
|
Thanks!
Scott Cain wrote:
> 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
|
