Tobias Girschick wrote:
> On Mon, 2009-10-12 at 12:21 +0200, Christoph Helma wrote:
>   
>> Excerpts from Tobias Girschick's message of Thu Oct 08 15:29:01 +0200 2009:
>>     
>>> Hi Christoph,
>>>
>>> On Tue, 2009-10-06 at 16:03 +0200, Christoph Helma wrote:
>>>       
>>>> Excerpts from chung's message of Mon Oct 05 17:43:19 +0200 2009:
>>>>         
>>>>> Dear all,
>>>>>
>>>>> In API 1.0, there is no POST for feature selection algorithms. I propose
>>>>> the following RESTful operation: 
>>>>>
>>>>> ***POST /algorithm/preprocessing/featureselection/{feat_sel_algorithm_id} 
>>>>>           
>>>> I agree in principle, but I would separate the algorithm ontology from
>>>> the algorithm webservices (see my proposal for the API 1.1
>>>> http://opentox.org/dev/apis/api-1.1/Algorithm), 
>>>>         
>>> I am not totally clear how you envision the algorithm ontology. Here 
>>> http://opentox.org/dev/apis/api-1.1/Algorithm you propose that a 
>>> GET on /algorithm/{id} returns an algorithm_ontology_uri. Could you
>>> specify what I do get back from something like that:
>>>
>>> GET /algorithm_ontology/{id}
>>>
>>> Would this return the XML (or whatever we choose) representation of the
>>> algorithm?
>>>       
>> In principle yes. Another (maybe more intuitive) option would be to get
>> the algorithm representation by
>>
>> GET /algorithm/{id}: returns algorithm representation
>>     
>
> this is definitively more intuitive and basically what's happening right
> now. Just the URI is changed/reduced.
>
>   
>> and to use the algorithm ontology to search for algorithms e.g.
>>
>> GET /algorithm-ontology/learning/classification: returns URIs for all classification algorithms (or a representation of the the learning/classification subtree)
>> GET /algorithm-ontology/preprocessing: returns URIs for all preprocessing algorithms (or a representation of the the preprocessing subtree)
>>     
>
> makes sense. We would have to think about, if we return every algorithm
> on 
> GET /algorithm-ontology 
> or if we just return the next URI level. Which would be a little bit
> more inconvenient.
>
>   
>> This would require of course, that the algorithm representation uses the same ontology as the algorithm-ontology webservice.
>>     
>
> Well, yes, but that's the goal of creating/using an ontology, isn't it.
>   

Indeed.

I agree with simplification of the URIs, few questions follow.

- If we have the so-called Algorithm Ontology service completely
independent of the Algorithm service, how does Algorithm Ontology
service knows which Algorithms are available ?

- An ontology implies that we have defined classes (e.g. algorithm
types) and individuals (specific algorithm instances).  An algorithm
type will be an ontology entry (of type class). An algorithm will be
again an ontology entry, but of type "individual".  Thus, what is the
purpose  of  splitting  classes and instances in different resources /
services ? 

Best regards,
Nina

> Best regards,
> Tobias
>
>   
>> Best regards,
>> Christoph
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>