Hi All,

surajit ray wrote:
> 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.
>   
We have /dataset/{id}/metadata for retrieving information about a
dataset, without its content. In fact we are serving different content
of a model, based on media type
- text/uri-list - just URIs
- application/rdf+xml, text/n3, (all RDF types) - metadata of the model
(note this is not the model itself!)
- PMML (where applicable)  - the content of the model itself

So, we have totally different representations, based on content
negotiation, and this is truly REST style.   I don't see the reason why
we should invent an RDF representation, that mimic uri-list - if one
wants to use terse representation with URIs only, then it's way better
to use uri-list, instead of serving/transfering/parsing RDFs.

> 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 ...
>   
I would avoid coding in this direction, without agreement with
partners.  The idea that representations depends on a parameter doesn't
seems to be to fit with REST style guidelines.
If this is indeed necessary, it would be better to invent URI hierarchy,
like  /model/{id}/algorithm  or /model/{id}/title  (Note we already have
/model/{id}/dependent , /model/{id}/predicted for variables and this is
convenient and REST style).

It would be better if we can explicitly request what part of information
is required and standardize explicit query parameters, as Pantelis
suggested.

Finally, I would propose to postpone this discussion after the end of
February, because otherwise it will be impossible to complete demo use
cases like Fastox.

Best regards,
Nina
> 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
>>
>>     
>
>
>
>