Hi Egon,

On 20 October 2010 11:36, Egon Willighagen <egon.willighagen at gmail.com>wrote:

> On Wed, Oct 20, 2010 at 10:13 AM, Nina Jeliazkova
> <jeliazkova.nina at gmail.com> wrote:
> > On 19 October 2010 17:18, Tobias Girschick <tobias.girschick at in.tum.de
> >wrote:
> >> 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.
>
> I had originally in mind to actually have only one /sparqlendpoint per
> 'OpenTox API server/service'... so, when I originally wrote:
>
> /service/sparqlendpoint
>

Yes, I was responding to the example Tobias wrote above.



>
> I meant to have a subfolder *literally*, just like "/algorithm"
>
> One service could indeed also be just "/sparqlendpoint"
>
> But your proposal may perhaps be useful, to have different sparql
> endpoints for the various parts of the OpenTox API...
>
>
Although ambit implementation do have top level entry (
http://apps.ideaconsult.net:8080/ambit2), there are implementations, which
don't have top level entry for all APIs, but these are different
applications.

In fact OpenTox API doesn't specify there should be a single top level entry
... so there is no common single place like /service and this is the reason
I've suggested /algorithm/sparqlendpoint , etc.

However  /algorithm/sparqlendpoint  is actually confusing, since
/algorithm/{id} matches to specific algorithms ... we should think of some
other syntax


Nina


> Anyway, I would be more than happy with one REST service returning
> relevant SPARQL end points...
>
>



> Egon
>
> --
> Dr E.L. Willighagen
> Postdoctoral Research Associate
> University of Cambridge
> Homepage: http://egonw.github.com/
> LinkedIn: http://se.linkedin.com/in/egonw
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: http://www.citeulike.org/user/egonw/tag/papers
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>