Back to conference overview
ACeDB2000: Day 2
The Good, the Bad and the Ugly about ACeDB
A free form discussion about features that we like about ACeDB and should (probably) be classified as 'vital' organs, features that could be classified as 'vestigial' (a L.Stein term) and could (should?) be removed surgically.
The Good
Features that we like about ACeDB and should (probably) be classified as 'vital' organs. May be a bit sketchy since this is jotted down on a laptop during the meeting:
- Data: easy to mass-import and -export data. Aceformat is convenient. XML may be a viable option as an alternative input/output format. Ease of complete dumps of datasets, data transfers, FTP-setup or distribution by CD. Also query dumps to Acefile convenient.
- Data models: easy to manipulate in the text format, even for non-programmers.
- Queries: AQL + classical queries both available (version 4.8). Tablemaker powerful
- Output formats: FASTA, Acefile, Embl.
- Prefixes in Acefiles: -J, -P, -R, -D, quite useful stuff for batch processing.
- Performance: Handles complexity of biological data well. Most comprehensive package for working with genomic data. Relatively fast, indexing in code improved speed in queries.
- Cost issues:Open source and free. May be a turnoff for some parties.
- Portability: Linux, Solaris, binaries or source => compile.
- Displays: flexible displays, configurability, user views saveable..
- Keysets:good concept, nice to work with and saving.
- Blixem & Dotter
- Tool integration: pick-me-to-call to run programs & scripts. FetchSeq-concept cool but won't work oftentimes.
- AcePerl: nice in itself!
The Bad
-models.wrm: not well documented, needs better formalism, better metalanguage necessary? Hard to see how parts of classes work, especially for display functions. Discussions going into more technical display thoughts. Whitespace dependencies annoying
-Documentation: şarf ağ skipuleggja og koma effort af stağ. Wiki? DocBook a la O'Really? XML? Latex? Sylvia Martinelli's course manual to Web.
-Table maker: parameters different in xace vs. tace.
-tace: command line partial show of objects (less?)
-Reverse upload of data. Can get around by using acediff or perl-script.
-Acediff: bug, strips out // from URL's
The Ugly
-Politics & publicity: may need more exposure. Connect with SourceForge, and/or Freshmeat for better visability code releases? Better docs of course.
-Professionalism: Performance, docs, open source and other issues that pertain to the status of ACeDB in the eyes of the world.
Some known comments from outsiders on ACeDB (Ed Griffiths):
- -it won't scale to large projects
- -It is not concurrent
- -sparse publications (docs?)
- -old technology, rather homegrown
- -GUI & dbase not seperated
- -Lack of modern concurrency tools
- -No replication tools
- -Retrofitting, not reusing.
- -Limited to 1 Gb in size (really??!..)
Back to conference overview
Improvements thoughts from Ed Griffiths
Threading: would mean better IO-performance
Transactions: not possible in current ACeDB kernel form. Rollback/recovery, safe multistage something...can't read transparencies here.
Reliability: NFS problems, indexes, object lockes, database recovery strategy..all important in scaling up to larger projects.
Interface issues: online help for Gmap. ToolTips for Gmap. Drag & drop. More configuration possilities for displays. Better scrolling. A whole lot of stuff that would be good to have.
Curation issues: Tools for model checking. Dbase verification. Tools for annotation, edit windows Data entry validation. Developers should perhaps spend some time annotating and curating, so that they'll be sick of the interface and really dive into changing it :)
Data issues: AcePerl the best bet currently. XML straigth from Ace does look promising. Need of 'modern' data interchange format, preferably self-describing.
Documentation issues: Need of technical papers brought up to date and collected from the various README-files. Maintainance information, FAQ-maintainance.
Tech stuff: storing lumps of data in relational dbase that would control threading and access. Ace would be layer on top of the relational one. See Richard's comments on this issue please and ZAce-stuff later this week...
Back to conference overview
First results from task group discussions
The programming group is going to discuss the XML and SMAP issue Wednesday afternoon, and Richard is working on the ZAce-stuff. Simon has a working MacOS GTK port, so the MAC-port seems to be rising from the ashes.
After lunch, we split up into an AcePerl-discussion and a website/documentation-organization discussion. The plan is to make http://www.acedb.org a free-standing website (get rid of the Sanger-headers) and reorganize it to make it easier to navigate. Especially for newcomers looking for a tool to try out and read about. The documentation stuff was also prominent, and it is clear that to do a proper job, a full time doc person is necessary. But a WIKI-style multi-contributor effort should be sufficient to begin with...The AcePerl-group talked about some 'gripes', more specifically the problem of getting data from fields beyond the first field after the tag (e.g. the Homol tag in Sequence). I will ask Lincoln to post the solution (if there was one) to some good place.
Back to conference overview
The dendrogram display
Richard Bruskiewich did a small talk on the Dendrogram-display and the Peptide-display. Apparently he is importing phylogenetic data from ClustalW with various colour-coding extras. He had some overheads that I hope he will put on the web if contain information that is not already in the help-file in /whelp.
And finally, Dave Matthew distributed this list for the curators' plans involving presentations, feature requests and documentation writing.
Back to conference overview