Difference between revisions of "DASworkshop200903Day3"

From BioDAS
Jump to: navigation, search
(→‎DAS vs. ontologies, how and why)
m (→‎DAS writeback)
 
(23 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
Doodle Poll: [http://doodle.com/68bxciw5vaqq7icw poll]
 
Doodle Poll: [http://doodle.com/68bxciw5vaqq7icw poll]
  
−
This page is for people attending day 3 of the workshop to put down their ideas and volunteer to host a session on a topic or write some minutes of the meeting on the biodas wiki site, so we have a record of what was discussed and what the outcomes were or ideally some code to work with.
+
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.
−
* My current suggestion for the format would be to have the 1.6 spec and the DAS1/DAS2 merger topics discussed in the first 2 hrs of the day and be open to everybody. Then have groups split up into the remainder of the topics?
 
−
 
 
 
===DAS 1.6 spec and where to go with the Registry===
 
===DAS 1.6 spec and where to go with the Registry===
 
Host: Jonathan Warren and Andy Jenkinson
 
Host: Jonathan Warren and Andy Jenkinson
Line 9: Line 7:
  
 
[[1.6_Examples]]
 
[[1.6_Examples]]
 +
 +
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).
 +
*Suggestion of having a browsable ontology on the registry was also made maybe using javascript/AJAX
 +
*query by cooridinate systems.
 +
*lucene/Google type search idea was proposed and accepted but above still wanted.
  
 
===DAS1/DAS2 merger===
 
===DAS1/DAS2 merger===
 
===DAS writeback===
 
===DAS writeback===
 +
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 [http://www.biodas.org/wiki/DAS1.6E 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===
 
===Adapting Java DAS client libraries for alignment and PDB file retrieval for clients that dont use BioJava===
−
===Ajax das client/server library (allow DAS server discovery and retrieval on the browser page)===
+
Not discussed.
−
Graphical Representation of data
+
 
 +
===Javascript das client/server library (allow DAS server discovery and retrieval on the browser page)===
 +
Meeting held on Thursday as relevant people were available after workshop:
 +
 
 +
MINUTES
 +
Attendees: Bernat, Greg, Andy, Jonathan, Gustavo and Rafael
 +
 
 +
On Thursday 12 we talked about JavaScript DAS client libraries. We identified three different ways to create user interfaces using javascript.
 +
 
 +
*1.- Clients based on the google maps idea. Creating images on the server and using javascript on the client to manage tailing images. Victor de la Torre show a nice example on his presentation "collaborative annotation tool (MaDAS)"
 +
 
 +
*2.- Clients drawing graphics using canvas. Canvas is a new HTML element which can be used to draw graphics using scripting (usually JavaScript). Following this idea the client collects the information to render it on the canvas. Bernat Gel gave some examples with his genome viewer "DASgenexp".
 +
 
 +
*3.- Client creating graphics using HTML elements and transparent shaped images. In this case the client creates graphic representations creating HTML elements through the DOM and javascript. We can find an example in Dasty2 and the Karyotype Viewer.
 +
 
 +
To be able to share javascript on web DAS clients rendering graphics on the client side we proposed to create a standard javascript library. On a web client we can identify three general stages: Request, Parsing and Visualization. Since visualization it is more up to the developer and the necessities of the project we proposed to create this standard library for requests and parsing. Rafael agreed to create the first prototype for this library.
 +
 
 
===DAS interfaces to sequence analysis tools===
 
===DAS interfaces to sequence analysis tools===
 +
Not discussed as a group due to time constraints
 +
 
===BioSapiens ontology lookup and general Ontologies===
 
===BioSapiens ontology lookup and general Ontologies===
 
How to represent the ontology in DAS, e.g. JR Macias' "term" command
 
How to represent the ontology in DAS, e.g. JR Macias' "term" command
Line 57: Line 118:
  
 
===Searching, Filters and tags===
 
===Searching, Filters and tags===
 +
A proposal was made and accepted that Andreas should post a proposal for adding the DAS search functionality to DAS under the [http://www.biodas.org/wiki/DAS1.6E 1.6E spec] of the biodas wiki

Latest revision as of 13:58, 23 March 2009

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.

DAS 1.6 spec and where to go with the Registry

Host: Jonathan Warren and Andy Jenkinson Secretary: Jonathan Warren and Andy Jenkinson

1.6_Examples

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).
  • Suggestion of having a browsable ontology on the registry was also made maybe using javascript/AJAX
  • query by cooridinate systems.
  • lucene/Google type search idea was proposed and accepted but above still wanted.

DAS1/DAS2 merger

DAS writeback

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

Not discussed.

Javascript das client/server library (allow DAS server discovery and retrieval on the browser page)

Meeting held on Thursday as relevant people were available after workshop:

MINUTES Attendees: Bernat, Greg, Andy, Jonathan, Gustavo and Rafael

On Thursday 12 we talked about JavaScript DAS client libraries. We identified three different ways to create user interfaces using javascript.

  • 1.- Clients based on the google maps idea. Creating images on the server and using javascript on the client to manage tailing images. Victor de la Torre show a nice example on his presentation "collaborative annotation tool (MaDAS)"
  • 2.- Clients drawing graphics using canvas. Canvas is a new HTML element which can be used to draw graphics using scripting (usually JavaScript). Following this idea the client collects the information to render it on the canvas. Bernat Gel gave some examples with his genome viewer "DASgenexp".
  • 3.- Client creating graphics using HTML elements and transparent shaped images. In this case the client creates graphic representations creating HTML elements through the DOM and javascript. We can find an example in Dasty2 and the Karyotype Viewer.

To be able to share javascript on web DAS clients rendering graphics on the client side we proposed to create a standard javascript library. On a web client we can identify three general stages: Request, Parsing and Visualization. Since visualization it is more up to the developer and the necessities of the project we proposed to create this standard library for requests and parsing. Rafael agreed to create the first prototype for this library.

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.


What are:

  • Ontodas
  • 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 pmr@ebi.ac.uk 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?)

Searching, Filters and tags

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
Retrieved from "http://biodas.open-bio.org/w/index.php?title=DASworkshop200903Day3&oldid=849"