Christoph Helma wrote:
> Excerpts from Nina Jeliazkova's message of Tue Oct 13 12:08:44 +0200 2009:
>   
>>> 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 ?
>>     
>
> It could register a new algorithm, eg. with
>
> PUT /algorithm-ontology/{class}/{subclass} algorithm_uri
>
>   
Ah, OK.   So we can apply the same style for other objects, this is what
you mean by separating feature ontology from features, don't you?  That
requires this separate "registration" ability, which has its advantages.
>> - 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 ? 
>>     
>
> I think the main benefits are
>
> - simplified algorithm_uris
> - stable algorithm_uris, even if the algorithm ontology is modified
> 	(I suspect that we will need a lot of reclassificiations/modifications/additions of algorithms in the near future and we do not want to modify the algorithm API/URIs every time we modify the ontology)
>   
Makes sense, in fact the classification of the algorithms might not be
hierarchical at all (which is fine, an ontology doesn't need to be
hierarchical). 

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