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

[Steve Chervitz]

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.