Christoph,

Just a quick note,I haven't yet tested examples myself, so this my not
be relevant to your case:

The superservice reads model RDF representation and finds which
features are used as descriptors by reading ot:independent.  Then it
reads the content of the independent features and looks for
ot:hasSource property to figure out which algorithm service was used
to generate them.  Therefore, if you use non-dereferencable ("fake")
URIs for features, this will not work.

I'll test the examples and reply later.

Best regards,
Nina


On Fri, Aug 20, 2010 at 4:42 PM, Christoph Helma <helma at in-silico.ch>
wrote:the content
> Excerpts from Vedrin Jeliazkov's message of Fri Aug 20 12:39:34 +0200 2010:
>> Hi Christoph,
>>
>> Nina is flying to ACS' fall national meeting in Boston right now. I'll
>> try to answer your queries on her behalf. Nina could provide further
>> details (if needed) as soon as she gets a chance to open her mailbox.
>
> No need to hurry - I am not running out of work here ;-)
>>
>> On 20 August 2010 12:03, Christoph Helma <helma at in-silico.ch> wrote:
>> > Excerpts from Nina Jeliazkova's message of Mon Aug 16 17:27:03 +0200 2010:
>> >> curl -X POST -d dataset_uri=$dataset_uri -d model_uri=$model_uri
>> >> http://apps.ideaconsult.net:8080/ambit2/algorithm/superservice
>> >>
>> >> Returns task URL.
>> >
>> > Thanks! I have tried with
>> >
>> > curl -X POST -d dataset_uri=http://ot-dev.in-silico.ch/dataset/356 -d model_uri=http://apps.ideaconsult.net:8080/ambit2/algorithm/J48 http://apps.ideaconsult.net:8080/ambit2/algorithm/superservice
>> >
>> > which returns the RDF (not task URI):
>>
>> Yes, according to the current API, RDF is returned by default. If you
>> prefer to receive a uri-list, then you should add a corresponding
>> Accept header to the POST request:
>>
>> - - - - - - - - 8< - - - - - - - -
>> vedrin at ambit:~$ curl -X POST -H "Accept:text/uri-list" -d
>> dataset_uri=http://ot-dev.in-silico.ch/dataset/356 -d
>> model_uri=http://apps.ideaconsult.net:8080/ambit2/algorithm/J48
>> http://apps.ideaconsult.net:8080/ambit2/algorithm/superservice
>> http://apps.ideaconsult.net:8080/ambit2/task/33ca80be-2d2b-47c0-bc89-0c9fdb706016
>> - - - - - - - - 8< - - - - - - - -
>
> Ok, thanks for clarification.
>>
>> Well, you could have a look at a somehow similar working example
>> (without a superservice invocation though) here:
>>
>> http://ambit.uni-plovdiv.bg/cgi-bin/smokeping.cgi?target=IDEA.Algorithms.J48ModCreation
>>
>> I tried to follow this example with the relevant feature URI in your
>> case (http://ot-dev.in-silico.ch/toxcreate/feature#hamster_carc), but
>> got the same error as the one you've reported above. I don't have a
>> clue what's going wrong ... One possible culprit is that this feature
>> cannot be found:
>>
>> - - - - - - - - 8< - - - - - - - -
>> vedrin at ambit:~$ curl 'http://ot-dev.in-silico.ch/toxcreate/feature#hamster_carc'
>> <h1>Not Found</h1>vedrin at ambit:~$
>> - - - - - - - - 8< - - - - - - - -
>
> As we do not run a feature service I use "fake" URIs for features
> (intending to replace them with links to ontology entries later). I can
> of course provide a "valid" link for features if necessary.
>
>> ... but again, I'm not sure whether this is expected or not (I noticed
>> that in fact http://ot-dev.in-silico.ch/toxcreate/feature#hamster_carc
>> is available in http://ot-dev.in-silico.ch/dataset/356). It is not
>> clear either whether there's only one single reason for the failure or
>> an accumulation of several issues. I guess Nina will have to shed some
>> light on this.
>
> It could be also a dataset compatibility issue, but I am using the same
> libraries as Martin and his services seem to work.
>
> Best regards,
> Christoph
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>



-- 
Dr. Nina Jeliazkova
Technical Manager
4 A.Kanchev str.
IdeaConsult Ltd.
1000 Sofia, Bulgaria
Phone: +359 886 802011