It was agreed a feature is defined not only with a name (there can be multiple features with same name, coming from different sources) , but with as a feature_definition (units, references, types, algorithms used to generate, experimental protocol, etc.). Therefore I would not agree to decouple feature and feature_definition objects. In your proposal you use only a name, when in the initial proposal for the same purpose feature_definition is used.

If I understand right, your proposal (YAML) assumes there might be more than one value per feature. This somewhat in contradiction with the initial proposal. I would propose to introduce tuples (or set) of feature/value pairs , in order to handle the case multiple values need to be aggregated. Any comments?

Otherwise, I agree feature services is indeed redundant.

I was not really happy with the initial proposal, because it blurred the distinction between objects (features) and annotations. I would suggest to address features not by name, but by ids (which can contain of course the name, if you are clever enough to construct an unique id from it - but that's an implementation detail). So if you have for example a features for a calculated {logP_id1} and a measured {logP_id2} logP, you can get the actual values with

GET /feature/{logP_id1}
GET /feature/{logP_id2}

You should be able to get details about features (e.g. calculation algorithm, measurement protocol, ...) by asking the feature ontology, e.g.

GET /feature-ontology/(logP_id1} => returns XML/YAML that contains "calculated", algorithm="ALOGP"
GET /feature-ontology/(logP_id2} => returns XML/YAML that contains "measured", protocol="whatever"

I have introduced property/value pairs, because I needed them for my purpose (I need to know, the statistical significance of my fragments, as well as their activating/deactivating properties). An alternative would be to introduce datasets for features of features, but that seems to complicate the matter even more.

Sorry, the feature-ontology part should read:

GET /feature-ontology/feature/{logP_id1} => returns XML/YAML that contains "calculated", algorithm="ALOGP"
GET /feature-ontology/feature/{logP_id2} => returns XML/YAML that contains "measured", protocol="whatever"

Retrieving feature values by IDs is fine. Human readable feature names (different from the IDs and possibly not unique) then should belong to the ontology - right?

GET /feature-ontology/feature/{logP_id1} => returns XML/YAML that contains "calculated",algorithm="ALOGP",name="LogP",type="descriptor-ontology-entry-forAlogP", reference="..."

There is actually no difference with the API 1.0, besides changing the name "feature_definition" to "feature-ontology" (for better).

e.g. (will be fine to rearrange URI like /feature/8/compound/1 )
http://ambit.uni-plovdiv.bg:8080/[…]/8

What is still not clear to me if you use just "GET /feature/{logP_id1}", without referring to a compound, LogP_id1 value of which compound is expected to be retrieved ?

> Retrieving feature values by IDs is fine. Human readable feature names (different from the > IDs and possibly not unique) then should belong to the ontology - right?

Yes.

> What is still not clear to me if you use just "GET /feature/{logP_id1}", without referring > to a compound, LogP_id1 value of which compound is expected to be retrieved ?

Just the logP value. You will need the dataset to find the logP for particular compound. The benefit is more obvious for classifications, where you need only 2 features (eg. active, inactive) for all compounds.

>I have introduced property/value pairs, because I needed them for my purpose (I need to know, the statistical >significance of my fragments, as well as their activating/deactivating properties). An alternative would be to introduce >datasets for features of features, but that seems to complicate the matter even more.

To clarify - a list of name/value pairs is a feature value,where the feature has feature_uri and feature_name and feature_id linked to feature-ontology ?

An interesting question is where the meaning of "name" in the name/value pair is defined (the names are hard coded and the meaning is assumed to what is relevant to your system I guess). To have this in a generic way, we would need to have means to annotate those names as well.

I would propose to introduce another object, namely Tuples of features,which will handle the case when we need to group several features related to each other. Tuples might be annotated with feature-ontology as well, or another ontology.

/tuple/A
feature name=endpoint value= Rodent_carcinogenicity
feature name=classification value=active

or

/tuple/B
feature name="?" value=NN
feature name=p_value value=0.98
feature name=effect value=activating

This works well with presenting experimental data as well and can reuse feature xml schema:

e.g. excerpt from http://ambit.uni-plovdiv.bg:8080/[…]/261244

<Features>
<Feature CompoundID="23" ID="11988" Name="fish length" Value="8.0"/>
<Feature CompoundID="23" ID="11982" Name="species common name" Value="common carp"/>
<Feature CompoundID="23" ID="11971" Name="exposure concentration" Value="0.1"/>
<Feature CompoundID="23" ID="11960" Name="BCFss ww" Value="1.8"/>
</Features>

Yes, that could be a good alternative, that could work also with predictions (where we need not only the predicted value, but also a confidence,...). I am not sure, if anyone will need more complex data models (graphs?). BTW /tuple/B could be

feature name="smarts" value=NN
feature name=p_value value=0.98
feature name=effect value=activating