Re: [Obo-format] [Obo-discuss] Any newer OBO spec?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

See inline...

Chris Mungall wrote:
> On Mar 18, 2008, at 10:00 AM, Erick Antezana wrote:
>
>   
>> Chris,
>>
>>  see below...
>>
>> Chris Mungall wrote:
>>     
>>> On Mar 18, 2008, at 4:04 AM, Erick Antezana wrote:
>>>
>>>
>>>       
>>>> Hello,
>>>>
>>>>   I was wondering whether a newer OBO spec (1.3?) will be  
>>>> available in
>>>> the near future. There were many issues raised sometime ago in this
>>>> mailing list (e.g. properties/attributes on the relationships). We
>>>> have
>>>> been building our ontologies by adding some ugly workarounds (like
>>>> having several specific types of relationship (Typedefs) since
>>>> there is
>>>> no way to add an attribute/property to a relationship).
>>>>
>>>>         
>>> There is no set release date, but if you have use cases it may drive
>>> the process faster. Can you give some examples? Are the link
>>> attributes purely metadata or do they change the semantics of the
>>> relation?
>>>
>>>       
>> The link attributes we expect to have are for changing the  
>> semantics to
>> express for instance that a given protein (e.g. ZW10_ARATH ) is  
>> located
>> in (rel name: located_in) a specific place (e.g. chromosome,  
>> pericentric
>> region) according to a given evidence (e.g. IEA). Currently, "only"  
>> the
>> following could expressed in OBO:
>>
>> [Term]
>> id: CCO:B0002272
>> name: ZW10_ARATH
>> relationship: located_in CCO:C0000102 ! chromosome, pericentric region
>> ...
>>
>> however, as I've mentioned some workarounds could be devised by  
>> creating
>> a *specific relationship* (Typedef) for each evidence code:
>>
>> [Typedef]
>> id: CCO_REL:located_in(IEA)
>> name: located_in(IEA)
>> is_a: CCO_REL:located_in
>> def: "C located_in L (Inferred from Electronic Annotation) if and only
>> if: given any continuant c that instantiates C (at a time t) there is
>> some location p that instantiates L (some time t), such that: c is
>> located in p at t" [CCO:ea]
>> ...
>>
>> so, that solution will allow to have
>>
>> relationship: located_in(IEA) CCO:C0000102 ! chromosome,  
>> pericentric region
>>
>>
>> However, we don't like the *verbose* solution (define all the specific
>> typedef's). Something like the following would be nice to have, where
>> IEA is the (optional?) *modifier* or attribute for located_in:
>>
>> [Term]
>> id: CCO:B0002272
>> name: ZW10_ARATH
>> relationship:  IEA located_in CCO:C0000102 ! chromosome,  
>> pericentric region
>> ...
>>
>> Perhaps a set of predefined *modifiers* would be necessary? or a  
>> section
>> (like the one for synonymtypedef:) to define the possible ones...
>>     
>
> I see. There are in fact two interchangeable solutions to this in  
> obof1.3
>
> The first is to attach an id to the link itself
>
> relationship: located_in CCO:C0000102 {id=_:annot1} ! chromosome,  
> pericentric region
>
> Then you can say whatever you like about _:annot1 in an Instance stanza
>   
This first solution looks like the one I described above but as you said 
below it adds some fake IDs and thus it pollutes the ontology...which 
was the motivation of having such a representation? For any 
problem/requirement in particular?

> The second way is to use the proposed new Annotation stanza, which is  
> convenient syntactic sugar for the above, with some typical  
> properties built in as tags:
>
> [Annotation]
> subject: CCO:B0002272
> relation: located_in
> object: CCO:C0000102
> evidence: IEA
> assigned_by: UniProtKB
> provenance: PMID:1234567
>
> One advantage here is that you avoid the need to create fake ids for  
> annotation links
>   
I think this second proposal fulfills the requirement (I guess this 
stanza will consider most (or similar) of the annotation fields used by 
the GOA people). This new stanza will boost the development of more 
application ontologies.
> The obvious way to translate this to OWL is to use reification and/or  
> annotation axioms (OWL1.1), we're waiting on OWL1.1 becoming a W3  
> recommendation before we say for sure. I know you release CCO in OWL  
> too so we should make sure we're harmonized here.
>   
Totally agree.
> The org.obo code that underpins oboedit is already cognizant of these  
> stanzas and can read and write them fluently. The model is being  
> actively used in the phenote project - this may be of interest to you  
> as it's a general purpose annotation tool, and what you have in CCO  
> is better explained to some as a mixture of ontologies and  
> annotations. I think there could be a really useful synergy here.
>
> Having said that, I'd be hesitant to recommend you publishing in  
> obof1.3 before we solidify the spec, unless anything you distribute  
> is clearly marked experimental
>
>   
>> One more thing that some people might have realized: time issues (as
>> described in the tentative definition given above). That may actually
>> mean an extra attribute... Anyway, has anybody faced those issues? any
>> ideas/solutions?
>>     
>
> This is a big topic. The OBO Relations list is perhaps the best place  
> to discuss this. We should all be agreed on a course of action after  
> a meeting we're having in May.
>   
Is it a meeting about RO: status/future developments/etc? Will it be 
possible to attend it "virtually" (TC, skype, etc)?
> You probably want some kind of help sooner. For example, your  
> located_in statement above should really be temporally  
> contextualized. We have some ideas for this, but these are fairly  
> experimental. We can start kicking around suggestions on the obo- 
> format list.
>   
could you comment a bit on the ideas you mention to deal with the 
temporal issues? Do you have any samples of prospective 
representations/models? We are very interested in that topic since CCO 
will integrate time series data from cell cycle microarray experiments; 
we had some brainstorms on how that sort of data could be represented on 
OBOF/OWL, etc But there wasn't so far any nice solution (only workarounds).

cheers,
erick
>   
>> cheers,
>> Erick
>>
>>     
>>>>    On the other hand, some work on a super set of the Relations
>>>> Ontology
>>>> (RO) has also been done, which was sent off-line  for  
>>>> consideration to
>>>> some OBO people. This new relations ontology (named METAREL) is  
>>>> trying
>>>> to fill some gaps present in RO as well as providing a formal and
>>>> generic infrastructure for dealing with relations. Anyway, if  
>>>> somebody
>>>> is interested in following up (online /offline) more discussions,
>>>> do not
>>>> hesitate in contacting us.
>>>>
>>>>         
>>> I'm aware of this, it's interesting, though there is obviously some
>>> overlap with what OWL provides
>>>
>>>
>>>       
>>>> cheers,
>>>> Erick
>>>>
>>>> -- 
>>>> ==================================================================
>>>> Erick Antezana                    http://www.cellcycleontology.org
>>>> PhD student
>>>> Tel:+32 (0)9 331 38 24                        fax:+32 (0)9 3313809
>>>> VIB Department of Plant Systems Biology, Ghent University
>>>> Technologiepark 927, 9052 Gent, BELGIUM
>>>> er...@ps...                  http://www.psb.ugent.be/~erant
>>>> ==================================================================
>>>>
>>>> -------------------------------------------------------------------- 
>>>> --
>>>> ---
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Obo-format mailing list
>>>> Obo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/obo-format
>>>>
>>>>
>>>>         
>>> --------------------------------------------------------------------- 
>>> ----
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Obo-discuss mailing list
>>> Obo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>>>
>>>       
>> -- 
>> ==================================================================
>> Erick Antezana                    http://www.cellcycleontology.org
>> PhD student
>> Tel:+32 (0)9 331 38 24                        fax:+32 (0)9 3313809
>> VIB Department of Plant Systems Biology, Ghent University
>> Technologiepark 927, 9052 Gent, BELGIUM
>> er...@ps...                  http://www.psb.ugent.be/~erant
>> ==================================================================
>>
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Obo-discuss mailing list
>> Obo...@li...
>> https://lists.sourceforge.net/lists/listinfo/obo-discuss
>>
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Obo-format mailing list
> Obo...@li...
> https://lists.sourceforge.net/lists/listinfo/obo-format
>   

-- 
==================================================================
Erick Antezana                    http://www.cellcycleontology.org
PhD student
Tel:+32 (0)9 331 38 24                        fax:+32 (0)9 3313809
VIB Department of Plant Systems Biology, Ghent University
Technologiepark 927, 9052 Gent, BELGIUM
er...@ps...                  http://www.psb.ugent.be/~erant
==================================================================