Hi All,

On 19 October 2010 17:18, Tobias Girschick <tobias.girschick at in.tum.de>wrote:

> Hi Nina,
>
> I am not sure I get the whole thing. Just to clarify. If I issue a GET
> on, e.g., TUMserver/algorithm/CDK/sparqlendpoint the result would be the
> URI of all ontology servers the algorithm is registered with?
>

Thinking again, it will likely be overkill to have for every single instance
of REST resource (e.g. have /algorithm/{id}/sparqlendpoint ) .

However,  at the top level (e.g. /algorithm/sparqlendpoint  ) should be
ok.   Thus, it by definition the returned url should not be interpreted as
the ontology service, all algorithms are registered with (some may be, some
not) , but merely a pointer to the sparql endpoint some of the sub-resources
might be found.

If the client doesn't find anything at the sparqlendpoint, then it always
has an option to establish its own ;)

Does this make sense for both service and client developers ?


> Point 3) is done "automatically" on registering with an ontology
> service?
>

This could get more complicated when introducing authn/authz ...

Best regards,
Nina


> best regards,
> Tobias
>
> On Tue, 2010-10-19 at 16:21 +0300, Nina Jeliazkova wrote:
> > All,
> >
> > As the answer of the question in the subject of this email doesn't have
> an
> > easy answer via the current API, here is a suggestion (originally by
> Egon)
> > how to extend the API :
> >
> > 1) Each service implements  /{service}/sparqlendpoint
> >
> > e.g. /compound/sparqlendpoint  , /model/sparqlendpoint , etc.
> >
> > 2) The /{service}/sparqlendpoint  returns on GET zero, one or mode URLs
> of
> > ontology services, using text/uri-list   mime type;
> >
> > 3) Adding, updating and deleting entries is done via POST , PUT and
> DELETE
> > to /{service}/sparqlendpoint
> > (whether it will use www-form or text/uri-list as content-type is to be
> > specified )
> >
> > Similar approach might be adopted for returning URLs of AA services ,
> e.g.
> > /{service}/auth.
> >
> > Any feedback is welcome.
> >
> > Best regards,
> > Nina
> > _______________________________________________
> > Development mailing list
> > Development at opentox.org
> > http://www.opentox.org/mailman/listinfo/development
>
> --
> Dipl.-Bioinf. Tobias Girschick
>
> Technische Universität München
> Institut für Informatik
> Lehrstuhl I12 - Bioinformatik
> Bolzmannstr. 3
> 85748 Garching b. München, Germany
>
> Room: MI 01.09.042
> Phone: +49 (89) 289-18002
> Email: tobias.girschick at in.tum.de
> Web: http://wwwkramer.in.tum.de/girschick
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>