[DAS2] Notes from the weekly DAS/2 teleconference, 5 May 2006

[Steve Chervitz]

Notes from the weekly DAS/2 teleconference, 5 May 2006

$Id: das2-teleconf-2006-05-01.txt,v 1.1 2006/05/01 17:52:48 sac Exp $

Note taker: Steve Chervitz

Attendees: 
  Affy: Steve Chervitz, Ed E., Gregg Helt
  Dalke Scientific: Andrew Dalke
        
Action items are flagged with '[A]'.

These notes are checked into the biodas.org CVS repository at
das/das2/notes/2006. Instructions on how to access this
repository are at http://biodas.org

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable, given the desire to get the notes out with a
rapid turnaround. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit. 


Proposed agenda:
* Discuss feedback on Andrew's writeback spec and solution to splits
  and joins


Topic: Writeback
-----------------

[A] Collect feedback from UK folks at next mtg since today is UK holiday.

ad: likes the model where you have multiple, composed change
statements rather than a single document describing all changes.
if you have history tracking, you have the server understand
versioning. 

gh: if you do a merge by deleting a feat and then extending another
feat or delete 2 and create one, how do you get history tracking?

ad: you have a single delta, describing "delete this, extend
that". Lots of small deltas comprise a big delta --- wraps up all of
the curator's work in a single session.
gh: delta lets you figure out what came from what in the change element.

ad: when do people use the split and merge history trail?
gh: to ask, "what the hell happened to the gene that I'm interested
in?" when the thing it got merged into has a completely different id.

ad: what I'm proposing could capture this history,
gh: it allows the capturing as long as client is careful about how it
constructs the change and server is configured to track changes.
ad: client and server both need special care.
gh: I could see a more direct way of doing it that doesn't require
such carefulness. I.e., explicitly say what a new feature is derived
from.
ad: this could be a micro-delta, such as a comment or remark saying
"this is a merger of x and y" along with a controlled vocab of changes.
I'm hoping people had a chance to look at it.

gh: to me it looks sufficient, but the main question is, does this
meet requirements of existing Apollo and Otter systems?

[A] Andrew will talk directly with Nomi and Otter folks.

gh: so we need to get someone to implement. Allen and Brian.

[A] Allen and/Brian provide feedback to Andrew for writeback based on their
impl.

gh: there's still the question of having arbitrary xml in a feature,
editing it, and how to indicate what should/shouldn't be changed.
Also, the locking document isn't on-line.

ad: the locking document is on my todo list. as we discussed, locking
and writeback are orthogonal.

[A] Andrew will create a locking document.

Topic: Stylesheets
------------------

ad: changed stylesheets a bit.
ee: I like getting color etc. out of the main tag. still not sure how to
impl this in IGB. We may ignore stuff about hi/low zoom, box, line.
ad: what are units of height and width. pixels, em?
sc: we could specify units in the document.
ad: ...

ad: Also, does width/height include the label and where is the label
to be positioned? 
ee: could just let it be undefined. leave it up to the
browser. There's too much variation in what sort of vizualization
different viewers will be doing.

ad: do we need to specify height/width?
ee: shouldn't need width since that's based on chromosomal
coordinates. maybe need a minimum width.
ad: would be glad to drop width/height from stle element.

[A] Andrew will drop height/width from stylsheet until there's a clear need.


Topic Status
------------

ee: investigated bug for our old das servers are not returning unique
ids for certain things (alignments).  in our das/1 parser, if both
things come back with same id in one request, it merges, if they come
back in different requests, the second will be ignored (will say it's
already seen it). They need to modify server to return unique ids.

ad: seems to be a common problem.

gh: still on vacation. Need to set up teleconf to discuss resubmission
of renewal grant, and the possibility of bridge funding until we get
another grant.
ad: what about the no-cost funding extension?
gh: still figuring out what we have funding-wise.

sc: Fixed the cronjob on biodas.org to CVS update the spec
documentation, so the docs on the website will stay current now.
Other things: I've been playing with ruby on rails for rapid web app
development. so far I'm impressed. The URL-based nature of it's
request processing makes me think about hooking it up with das, making
a simple das server and/or viewer. E.g., table-based views of
sources, versions, types. We could possibly do web-based graphical
views as well.
ad: the das url structure should make this feasible. processing
queries would take some work. there's an analogous python approach too.
sc: might be nice to have sample das servers and/or web-based viewers
in python, ruby, perl, and java.

[A] steve will set up a demo das server/client using ruby on rails.