Fwd: Re: Status of GO slots?

[Lincoln Stein]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://brie4.cshl.edu/pipermail/po-dev/attachments/20050131/184842ec/attachment.sig>