Hi,

I'd like to share my thoughts on this ....

I had thought about this also - and one way out is the structure of the REST
architecture itself. At least in Restlets (java) we can embed client-end
REST data reader (code) directly into lets say the welcome page
representation resource ( with  all the models, algorithms etc).

So lets say we have
A) algorithm with GET method - throws a representation of the algorithm and
its parameters.
B) when we access the welcome page url with a GET method - we mention
another parameter, lets call it content=lite,full
C) If content=full , internally the resource generating code initiates a GET
on the algorithm URL resource and all its parameters. Otherwise it just
lists the URLS (+ maybe one or two details - with the content variable being
passed on in the internal GET call). Same with Datasets etc.
D) the content variable is applied on the algorithm representation also :
implying that content=full gives a full list of the algorithm details -
otherwise just one or two important ones.
E) When we initiate the internal GET in Step (C) we can use this variable
(content) to get minimal representations of the algorithms (or full
representation). and similarly for all the components of the model.

Nina,

Could you please verify if this would be a satisfactory way of dealing with
the level of detail. Right now I am coding in this direction ...

Thanks
Surajit





On Mon, Feb 8, 2010 at 5:47 PM, chung <chvng at mail.ntua.gr> wrote:

> 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
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>



-- 
Surajit Ray
Partner
www.rareindianart.com