[OTDev] Some things have to be clarified

chung chvng at mail.ntua.gr
Mon Feb 8 13:17:02 CET 2010


Hi all,
 In the OpenTox API specifications it is documented that the GET method
on /model should return "List of model URIs or RDF representation".
However it is not clear what we mean by "RDF representation"; is it just
a URI list in RDF, or a set of model resources along with all/some of
their meta data. In order to be more specific, the following meta
information are included in the RDF representation of a single model
(at /model/{id} ):

1. title
2. creator
3. date
4. audience
5. rights
6. provenance
7. description
8. source
9. relation
10. identifier
11. language
12. publisher
13. subject
14. type
15. A list of the algorithm tuning parameters used to train the model
(if any)
16. A list of independent features
17. dependent feature
18. predicted feature
19. status (NEW)

* Should all these meta (or some subset of these ) be available
under /model ?

What is more if a client performs a very specific query like:

http://opentox.ntua.gr:3000/model?user=chung&dependent_feature=feature1&independent_feature[]=feature10&independent_feature[]=feature11&independent_feature[]=feature12&kernel=RBF&gamma_min=1&gamma_max=10  (Let me mention that queries like this or even like ?algorithm={...} are not documented or included in the API)

the server will return, say, 10 models, so its OK to include all meta
data in the RDF representation. But if you navigate to
http://opentox.ntua.gr:3000/model you'll find yourself in front of
something like 56000 models. The representation of all these including
all meta data will be HUGE!!! Is there a point to do this? The reasoning
behind the current API, and behind REST in general, is that a client can
get the information it needs assuming it knows where to find it. So one
can first ask for a URI list from the corresponding service and then,
for every URI in the list, perform another GET request to get the
representation of the underlying resource.

Well I think some things have to be clarified because after all we
encounter serious problems designing our services (the database and web
part of it) since the specifications are unclear(!).

BRs,
Pantelis Sopasakis
Charalampos Chomenides




More information about the Development mailing list