Notes from the weekly DAS/2 teleconference, 15 May 2006 $Id: das2-teleconf-2006-05-15.txt,v 1.1 2006/05/16 00:25:27 sac Exp $ Note taker: Steve Chervitz Attendees: Affy: Steve Chervitz, Gregg Helt CSHL: Lincoln Stein Dalke Scientific: Andrew Dalke UCLA: Allen Day, Brian O'connor 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. Status reports -------------- gh: have been working on adding curation ability to IGB. Can do basic creation and editing of features based on other features. Can write out the curations in bed format. working on writing out das2xml. gh: grant renewal - plan is to submit new on in October. we can extend unused funds from original grant for two months after first grant ends (so thru july). we'll also request bridge funding after our funding runs out. Three things to do: * no cost extension (of remaining money) * request for bridge funding. * re-application in oct w/ Suzi as PI ad: (see email for my report). gff to das xml. writeback spec, validator work. Can get it back up and running today. sweden and iceland travel for teaching courses. [A] andrew will get his validator app back online. ls: got married, had lab retreat. had genome biology meeting. now am finishing off two grants due tomorrow. no das-related work to report. bo: finished up what we talked about (w/ gregg). sourceforge is fixed. server is up but beware: CVS root has changed. gh: it has been frustrating not being able to commit to sf the past week. sc: we'll have to consider other options if sf continues to be so unreliable. gh: other options? ls: open-bio.org -- much less downtime than sf. sc: My status: I've been working on getting affy das server registered with Andreas. found bugs in affy das server's features response (xml:base). gregg has fix. also working on updating the data served up by our das and quickload servers - new version of human and mouse genome assemblies. aday: set up database for writeback. xml parser using dom, handles features, not type writeback. working on code that coverts xml into sql insert statements. then we'll have writeback. had trouble getting apache to expose the post data to me, need to explore this more. other problem: loss of information in the way the current das server exposes the way ontology terms are attached on to a feature, as properties. e.g., mol function, cell component, biol process, and sequence types - key is not go id, value is not. [A] andrew, allen will think about best way to encode properties ad: as new xml elements, extensions to das, so they could say this means that exactly. you can specify what goes into which element. aday: a way to insert property types. ad: you extend das xml to include your own non-das element. [A] andrew will write up email description of using das xml extension for ontology terms gh: if you have non das xml embedded in an xml feature, client gets that, edits and sends back in writeback, does it have to send it back? ad: yes, must return it back, otherwise it will be assumed to be a delete. gh: could you put an example of a property of a feature being deleted by omission? ad: how about an accompanying document describing interaction behaviors. [A] andrew will include example of writeback deletion by omission. ad: why would client send back human readable text? aday: so person wouldn't have to parse the ontology. would prefer giving back an accession not the human readable term since that changes. need something that is reliably unique. ad: new xml element aday: what do we do for properties then? ad: properties are a way for humans to create annotations, a catch-all. Use them because you don't want to define a new xml element, perhaps. aday: will then have GO annotated elements, return as properties later in response to a get request. could be confusing for clients. ad: property table is accessible to humans, editable, no constraints on what can be in there. To summarize my position: let's use the 'x' in xml. [A] gregg/andrew get response from suzi re: urls for ontology terms Topic: Authentication ---------------------- ad: did research, see email. Two options: basic auth or http-digest auth. Have never used it before. Don't know best practices. gh: how about saying it's outside the scope. server supported on a server-specific basis. we have enough stuff to figure out. ad: fine. call it das 2.1 Other topics: -------------- sc: writeback issue: confirmation from server before it modifies anything on the server side. "You have requested to delete 17 features, and modify 13 others. Confirm?" ad: what if thre are hundreds of modifications after serveral hours of editing? will the user be expected to confirm each one? sc: user could commit changes in a more piecemeal fashion to avoid that situation. gh: I would prefer to have this done on the client side. the editing tool can provide this functionality more effectively, flexibly, etc. sc: ok. seems reasonable. but will server send confirmation response to client that the writeback request succeeded? and the client will be unable to issue a request until after the previous request succeeded? gh: yes.