Interfaces Discussion

General remarks (ch):

• I would like to see YAML support (in addition to XML) - it is so straightforward to (de)serialize datastructures in YAML (also easier to read and less markup).
• Requested MIME type should be set in the requests "Accept" header, e.g. curl -X GET -H "Accept:chemical/x-daylight-smiles" http://{server}/compound/{id}
• Submitted MIME type should be set in the requests "Content-Type" header, e.g. curl -X POST -H "Content-Type:chemical/x-daylight-smiles" -d "structure={smiles} http://{server}/compounds
• GET result for collections (e.g. datasets) could be simply a list of URIs (delimited by newlines), no urgent need for XML
• I would like to make a clear separation between core objects (compounds, features, datasets, algorithms, models, i.e. everything, that you need for computations) and their annotations/ontologies (i.e. everything, that you need to put data/algorithms/results into a domain specific context). This would mean that most webservice can work with a minimal core API, while GUIs (and maybe also report generation and query services) will have access to the full background information through the ontology APIs.
• Up to now I have no practical experience with the ontolgy APIs.
• For my work I would need most urgently a decision about the dataset representation and the authorisation procedures.

Questions (nj):

• Which is the correct MIME type for YAML?
  
• Should one of YAML or XML (or both) be mandatory to all services? If not, how to ensure interoperability between services? 
  
• Does anybody of the OpenTox partners have experience with YAML besides Ruby on Rails developers?  Doesn't seem there is YAML support in Restlet http://restlet.tigris.org/issues/show_bug.cgi?id=196
  
• Update: Using JYAML http://jyaml.sourceforge.net/ is pretty straightforward (source code) . However, I would prefer to have control on which data structure fields to be serialized, instead of dumping entire object in what might not be YAML format defined in the API. Not sure if it is possible with YAML.
  
• Data structures might differ between different services implementations, thus if the data structure(s) does not match the agreed YAML format, one of YAML advantages is lost. 
  
• Small correction: the data content in the curl example should follow the mime type - e.g. curl -X POST -H "Content-Type:chemical/x-daylight-smiles" -d "{smiles} http://{server}/compounds
• GET result for collections (e.g. datasets). Dataset by definition contains links to compounds and links to features, with a simple list of URIs it would be hard to distinguish between e.g. compounds and features.
  
• Clear separation between core objects and their annotations/ontologies. It would be hard to make a separation, except for some very simple cases, or if the service(s) rely on hard-coded assumptions. The meaning of the objects themselves is defined by ontologies.  Feature values depend on feature definitions (ontologies).  Datasets depend on feature definitions as well. Models depend on descriptors and endpoints (ontologies). 
• What about introducing JSON instead of YAML? JSON seems to be better supported in Java and might be a better fit for the multi-platform framework. Last, but not least it will make easier development of OpenTox GUI by Javascript.