Doodle Poll: poll
This page is for summarising the results of day 3 of the DAS workshop 2009 and results/agreements made as a result of the workshop so we have a record of what was discussed and what the outcomes were. This also shows discussions that were held after the workshop.
- 1 DAS 1.6 spec and where to go with the Registry
- 2 DAS1/DAS2 merger
- 3 DAS writeback
- 4 Adapting Java DAS client libraries for alignment and PDB file retrieval for clients that dont use BioJava
- 6 DAS interfaces to sequence analysis tools
- 7 BioSapiens ontology lookup and general Ontologies
- 8 Searching, Filters and tags
DAS 1.6 spec and where to go with the Registry
Host: Jonathan Warren and Andy Jenkinson Secretary: Jonathan Warren and Andy Jenkinson
DAS1.6 spec discussions:
- Generally 1.6 was accepted as a good idea ,Minor changes to 1.6 document:
- Document XDAS server version so its implemented correctly.
- Alignment clarified in the das spec?
- BOSC proposed as a release date for the 1.6 spec
- The entry_points cmd is proposed as being compulsory in 1.6 for both annotation and reference servers?
this caused a lot of discussion as to how to handle cases where there are 1000's of entry_points. A consensus seemed to be that the spec should allow people to specify a range eg. 1-1000, then 1000-2000 in the request in a similar way that you can for the alignments you want returned in the alignment 1.53E spec. There should be a DAS standard default range always returned if no params sent say 1-10. The response should always return a count for the total number of entry_points available for the source. We need to provide a explanation as to why the above is available.
- IUPAC names for moltype was suggested e.g. deoxyribonucleic acids (DNA).
- it was suggested that the registry should enforce the number of types available in a source.
- we need to explain what cvId stands for in the spec (Controlled Vocabulary Identifier) and why people should be encouraged to use it.
- JS suggested that the maxbins should encompass a returned value that says how the data is being made i.e. whether it is an average or an extreme of the data in those bins.
this at least should be some kind of free text field. response should also say if returning 200 of 10,000??
- The parent and sub part feature and deprecation of the group attribute for features was unanimously accepted as a good idea, however there was significant debate as to the the exact specification.
Should a server return all children (or parts) of a parent even if they are outside the viewable area of the screen/segment. The argument for saying yes was due to DAS being used as a data interchange format. The argument for no because as a purely visual tool it DAS would not need to return features not included in the viewable segment/area.
Registry - suggested:
- Dont trust the sources document or the capabilities ticked by users but test each capability anyway to see what servers do what.
- Give a graphical representation of the capabilities supported by each source e.g. red for not supported and green block for supported.
- JW suggestion would be do as above and get rid of manual configuration of DAS sources capabilities and only use the sources document and have the registry suggest
if a capability is not specified but seems to exist?
- As if BOSC or a certain date it was agreed that every new data source registered should conform to the 1.6 spec and not be allowed into the registry unless it does.
- have testing pages for testing only - not for registering.
- people want to be able to query by ontology cvID type e.g. gene, protein etc
- Ontology cache was suggested and I said that this was in hand and almost done. (JW to finish).
- query by cooridinate systems.
- lucene/Google type search idea was proposed and accepted but above still wanted.
Attendees: Bernat , Rafael , Andy , Gustavo , Gregg , Jonathan. -Generally Gustavos implementation was considered to be good and is based on DAS2 writeback. -discussion took place as to how handling of auto generation of features on the server side should be handled
- should the server respond with the id created by the client and it's new id and information generated by the server?
- should the server just accept the information and the client be asked to refresh the current view to get the new feature id generated by the server?
- should the input format be as similar as possible with the output GFF format, in order to follow patterns of other collaborative systems?
- how to handle features when the update implies a change of segment?
No decision was made on the correct approach.
A proposal was made and accepted that Gustavo should post a proposal for adding the DAS writeback functionality to DAS under the 1.6E spec pages of the biodas wiki and give a link to source already developed for this capability.
Adapting Java DAS client libraries for alignment and PDB file retrieval for clients that dont use BioJava
Meeting held on Thursday as relevant people were available after workshop:
MINUTES Attendees: Bernat, Greg, Andy, Jonathan, Gustavo and Rafael
DAS interfaces to sequence analysis tools
Not discussed as a group due to time constraints
BioSapiens ontology lookup and general Ontologies
How to represent the ontology in DAS, e.g. JR Macias' "term" command
DAS vs. ontologies, how and why
This topic was suggeseted because I'd like to understand how 'ontologies' (in general) are implemented in DAS and how this relates to the feature annotation models in Chado or GFF3, for example. How should an annotator use an ontology? How should the use of an ontology be reflected in the client behaviour? What about DAS ontology servers (and the 'term' DAS command)? This topic dosn't really fit with the idea of a 'hackathon', but is a very interesting aspect of DAS. i.e.
- DAS Protein Ontology
- Ontology Lookup Service
- The BioSapians (feature type?) ontology
- The ontology of 'input filters' from EMBRACE This is an effort by the EMBRACE project to define ontologies for use in registering web services in the EMBRACE registry and later in the BioCatalogue registry. The ontology will cover the terms used in EMBRACE servcies, including BioMart and EMBOSS - both of which already have well-defined terms which will be used to populate the ontology. This will be contributed to the OBO foundry (like the other ontologies used in DAS) and can be extended to cover algorithms to give a better description of a service, its inputs, parameters and outputs. Contact Peter Rice email@example.com for more information.
Discussion group notes
- similar to attribute, but includes hierachical structure
- if treated like coordsys, but additional layers hidden
- use case: anatomical ontology, uses "term" as query command;
but more general terms return too much data, response needs to be cut
-> proposed solution: use "maxbins"-like functionality
-> For DAS 1.6: adopt ontology from 1.53E as cvID and method
a) Sequence Feature Ontology (SFO)
add terms if necessary, other ontology may need to be added for anatomical eg.
b) evidence codes
example: <TYPE id="exon SO:0000147" category="inferred from RT-PCR experiment (ECO:0000109)">exon</TYPE>
- Add to Registry: Cache Ontology, add links to master ontology files (PSI?) and ontology browser (EBI?)
A proposal was made and accepted that Andreas should post a proposal for adding the DAS search functionality to DAS under the 1.6E spec of the biodas wiki