Status of GO slots?

Mon Jan 31 15:11:54 EST 2005

Thanks for forwarding this Lincoln.
	 It seems as though it would be worth trying this software if Chris  
can write it.   He seems to have hit the crux of the problem when he  
states that "This is partly due to the nature of GO, whereby the matrix  
of meaningful combinatorial terms is quite sparse; this may not hold  
for other ontologies such as POC...."  The matrix of meaningful  
combinatorial terms in the Plant Ontology is indeed very large, and is  
also necessary; plant structure is not intrinsically hierarchical, it's  
modular and combinatorial.   	
	He also notes that "I'm interested in looking into this further; we  
will eventually need some kind of advanced description logic or  
slot-based querying system for phenotypic data, where the combinatorial  
explosion is enormous (and possibly infinite in the case of quantative  
values)."  Yes - this is exactly the problem that the PO has run into  
repeatedly and continuously, starting with our first meeting.
        (From Chris) "At this stage I'm not sure whether the best  
solution is a home-grown relational one, a special purpose  
object/knowledge-based db, or a hybrid one (such as Manchester's  
InstanceStore)."   I certainly don't have the expertise to answer this  
question - the only sort of db I'm familiar with is a relational one,  
and I suspect it will work, but maybe there are better things out  
there.
      It will be interesting to see how the "slot expander" works, and  
if it solves the immediate problem.
Toby

On Jan 31, 2005, at 8:43 AM, Lincoln Stein wrote:

> Hello,
>
> Some information from Chris Mungall about the prospects for
> automatically expanding "slots" (by which he means modifier terms
> such as "dorsal") into instantiated terms.
>
> Lincoln
>
> ----------  Forwarded Message  ----------
>
> Subject: Re: Status of GO slots?
> Date: Friday 28 January 2005 07:21 pm
> From: Chris Mungall <cjm at fruitfly.org>
> To: Lincoln Stein <lstein at cshl.edu>
>
> The tricky part of the code is automatically computing the
>  relationships in the derived DAG - luckily that part is essentially
>  done as part of Obol. It should only be a few days work, hopefully I
>  can do it sometime in the next 3 weeks
>
> On Fri, 21 Jan 2005, Lincoln Stein wrote:
>> Hi Chris,
>>
>> Yes, I did pick up on the slot expander idea from your earlier
>> email and I suggested it at the POC meeting. People seemed a bit
>> puzzled by the idea, so I'll send out a longer description of it by
>> email.
>>
>> Any idea of when work on the expander will start and when we might
>> be able to start working with it?
>>
>> Lincoln
>>
>> On Friday 21 January 2005 04:47 pm, Chris Mungall wrote:
>>> OK. Sometime I hope I can convince you not to be disappointed at
>>> the alternatives.
>>>
>>> For example, how about this: a SlotExpander tool that maps a file
>>> of slot-based annotations to simple annotations, creating a new
>>> DAG with appropriate combinatorial terms (and naming them
>>> sensibly) on-the-fly. The simple annotations and extended DAG
>>> could be treated with all existing GO tools, including the
>>> DB/AmiGO. Granted it doesn't solve the DAG navigation problem (we
>>> are working on this) but it does solve most of the ontology
>>> curation and annotation crises.
>>>
>>> The tool isn't written yet, but it's easy to do using the current
>>> obol infrastructure. It could be written if it would be useful &
>>> if POC were to be willing to help test it.
>>>
>>> c.
>>>
>>> On Tue, 18 Jan 2005, Lincoln Stein wrote:
>>>> Hi Chris,
>>>>
>>>> Thanks for the update.  I'm disappointed at your answer, but I
>>>> understand the tradeoff between costs and benefits that the GO
>>>> project is facing.
>>>>
>>>> Lincoln
>>>>
>>>> On Monday 17 January 2005 07:03 pm, you wrote:
>>>>> Hi Lincoln
>>>>>
>>>>> I was probably a little vague in my message here:
>>>>> http://www.geneontology.org/email-go/go-arc/go-2004/2438.html
>>>>>
>>>>> My analysis of GO is that the introduction of annotation
>>>>> slots would complicate things unnecessarily for the MODs
>>>>> implementing GO queries, and would introduce lots of other
>>>>> problems. It's better to manage the complexity centrally and
>>>>> in an automated fashion, using formal definitions of terms.
>>>>> This can go a long way to ameliorating the complexity of
>>>>> combinatorial terms. I can give more details on this approach
>>>>> if you like.
>>>>>
>>>>> This is partly due to the nature of GO, whereby the matrix of
>>>>> meaningful combinatorial terms is quite sparse; this may not
>>>>> hold for other ontologies such as POC - I don't know enough
>>>>> about plant anatomy to follow the examples in the document
>>>>> Katica sent.
>>>>>
>>>>> At the moment, the implementation of slot-based annotations
>>>>> in the GO database and AmiGO isn't a high priority. I believe
>>>>> that OBO-Edit does or will soon allow you to define slots (or
>>>>> annotation_properties and datatype_properties in OBO/OWL
>>>>> lingo) for classes. However, the database and query support
>>>>> for this isn't there. Implementing queries over annotations
>>>>> with recursive slot values is actually a fairly tricky
>>>>> problem, and not something that will work with direct SQL
>>>>> queries.
>>>>>
>>>>> One thing we have considered in the database is a vastly
>>>>> simplified formalism allowing annotation conjunctions (eg
>>>>> function F is exercised during process P in component CC in
>>>>> cell type CT in anatomical part A). This is simpler to query
>>>>> over, but has some severe limitations. The structure for this
>>>>> is there in the GO DB schema, but as yet there is no
>>>>> immediate plans to populate or query over it.
>>>>>
>>>>> There may be similar simplifications that can be made to the
>>>>> slot formalism to support the immediate needs of the POC -
>>>>> but this may not be generic enough to cover other more
>>>>> general cases.
>>>>>
>>>>> I'm interested in looking into this further; we will
>>>>> eventually need some kind of advanced description logic or
>>>>> slot-based querying system for phenotypic data, where the
>>>>> combinatorial explosion is enormous (and possibly infinite in
>>>>> the case of quantative values). At this stage I'm not sure
>>>>> whether the best solution is a home-grown relational one, a
>>>>> special purpose object/knowledge-based db, or a hybrid one
>>>>> (such as
>>>>> Manchester's InstanceStore). However, we're lacking the
>>>>> programmer resources for this at the moment...
>>>>>
>>>>> Sorry to be vague and handwavey. I can be more specific on
>>>>> any of the points above if you like.. but the short answer is
>>>>> there is no timetable
>>>>>
>>>>> Cheers
>>>>> Chris
>>>>>
>>>>> On Mon, 17 Jan 2005, Lincoln Stein wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> There's a POC meeting tomorrow and I wanted to check in
>>>>>> about the progress towards software to handle ontology
>>>>>> slots.  We need it here to handle the "multiplicative
>>>>>> crisis" introduced by multiple similar anatomic structures
>>>>>> that appear in different contexts. As I understand it,
>>>>>> DAG-Edit with OBO already handles slots, but the GO
>>>>>> database doesn't utilize the slots for associations.  Is
>>>>>> this correct?  Can you fill me in on the development plans
>>>>>> and timetable?
>>>>>>
>>>>>> Lincoln
>
> -------------------------------------------------------
>
> --  
> Lincoln D. Stein
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724
>
> NOTE: Please copy Sandra Michelsen <michelse at cshl.edu> on
> all emails regarding scheduling and other time-critical topics.
>
Elizabeth A. Kellogg
E. Desmond Lee and Family Professor of Botanical Studies
Department of Biology
University of Missouri-St. Louis
St. Louis, MO 63121
Tel: 314-516-6217
FAX: 314-516-6233
http://www.umsl.edu/divisions/artscience/biology/Kellogg/Kellogg/ 
home.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 7460 bytes
Desc: not available
URL: <http://brie4.cshl.edu/pipermail/po-dev/attachments/20050131/1612f9e1/attachment.bin>