Notes from the weekly DAS/2 teleconference, 1 May 2006 $Id: das2-teleconf-2006-05-01.txt,v 1.2 2006/05/01 18:19:01 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.