General:

• 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 URIs for collections should be in plural (e.g GET /datasets) to reflect common English wording (my personal preference)
• GET result for collections (e.g. datasets) could be simply a list of URIs (delimited by newlines), no urgent need for XML
• POST URIs that creates a new instance of the same class should be in plural (e.g. POST /compounds, POST /datasets) to reflect common English wording (my personal preference)
• POST URIs that create a new instance of another class should be in singular (e.g. POST /prediction_model)
• PUT should be optional (DELETE/POST can do the same job)

Compound:

• DELETE is only applicable, if compounds are stored permanently
• Chemical MIME priorities:

I would prefer the following priorities:

• smiles
• inchi
• sdf
• ...

• Conformers: should be optional
• Features:

I would move this proposal with slight modifications into the *dataset* API (in my understanding a dataset is a collection of compounds together with their features)

Proposal:

Chemical compound

Component description

A chemical compound that has a unique and defined chemical structure.

REST operations

HTTP status codes

Compound representation:

Supported MIME formats (http://www.ch.ic.ac.uk/chemime/), sorted according to priority

• chemical/x-daylight-smiles
• chemical/x-inchi
• chemical/x-mdl-sdfile
• chemical/x-mdl-molfile
• chemical/x-mol2
• chemical/x-cml

Feature:

I would reduce the API to:

GET /feature returns feature representation
POST /features returns URI for the new feature
DELETE is only applicable, if features are stored permanently

• The feature definition part should be moved into the feature ontology API
• The feature service part is redundant with the dataset API
• The feature reference part should be moved into the feature ontology API

Proposal:

Feature

Component description

A feature is a (chemical, structural, biological, toxicological, ...) property of a chemical compound.

REST operations

HTTP status codes

Feature XML representation

See XML schema definition for Feature object

Dataset:

• Dataset queries should be performed through ontologies
• HEAD: I think we should stick to the standard GET, POST, DELETE and PUT to keep things simple
• Compounds and features in a dataset:

I would prefer the proposal in the current compound API with the following URI modifications:

• GET /dataset/{dataset_id}/compounds set of compounds
• GET /dataset/{dataset_id}/features set of features
• GET /dataset/{dataset_id}/compound/{compound_id}/features set of features of a compound

and their corresponding POST and DELETE methods

At present I do not need the reverse lookup (i.e. finding compounds for features) which would correspond to URIs like /dataset/{dataset_id}/feature/{feature_id}/compounds

• Set operations:

I would make them optional, because they can be performed also on the client side. Maybe they should go into the algorithm component, even if they are implemented in a dataset webservice. The same is true for similarity calculations.

Proposal:

Dataset

Component description

A set of chemical compounds and assigned features

REST operations

Dataset

Algorithm:

IMHO most of the proposed methods should be part of the algorithm ontology API, the most important (and the only requested) method should be

POST /algorithm/{algorithm_id}

It would return an URI for a new resource (e.g. model URI for learning algorithms, dataset URI for feature calculation/selection algorithms)

Proposal:

Algorithm

Component description

REST operations

Model:

o.k.

Other APIs: