Christoph Helma wrote:
> Excerpts from Nina Jeliazkova's message of Mon Oct 19 12:35:34 +0200 2009:
>   
>> Hi Tobias,
>>
>> Tobias Girschick wrote:
>>     
>>> On Fri, 2009-10-16 at 13:22 +0200, 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
>>>>     
>>>>         
>>> This sounds intuitive, the problem I see is, that of the different
>>> servers. To which server do I PUT the new algorithm? Only my own, where
>>> also the algorithm is provided? All servers that provide algorithms
>>> (IMHO no good idea)? 
>>>       
>> Why not - each particular server need not to support all the ontology,
>> only the part that is relevant.  Besides, the purpose of ontology is
>> common meaning, what I would be interested is to be able to query like
>> "get me all feature definitions that represent 'Melting point'" or
>> "retrieve all classification algorithms" . "Melting point" in the sense
>> of ontology is a "class" and particular "MP_1" feature definition is an
>> instance of that class.  
>>
>> Following these thought, my initial idea is that each resource (e.g.
>> feature definition, algorithm, model) comes with an assigned meaning
>> (e.g. MP_1 is assigned "Melting Point"), based on corresponding
>> ontology.  Christoph suggested to split ontologies and resources, IMHO
>> mostly driven by the fact he is developing a single application, where
>> the resources have predefined (hardcoded) meanings and an ontology
>> resource is perceived as something optional.
>>     
>
> My main intention is to separate the semantic part (which is moѕtly
> needed at the application/GUI level) from the core information that is
> needed by the individual webservices. This should allow us to build
>   
That might feel true for calculations, but for dataset access services
semantics of the data is crucial :) . Even for calculations there are
lot of semantics, which is usually hardcoded. (e.g. which values are
predictors, endpoints, identifiers, etc.)
> small and efficient webservices, that do not have to care about
> semantics and to assemble those into applications that use the
> ontologies to put the computational results into a meaningful
> (toxicological) context.
>
> I am also too lazy to build my own ontologies and I hope to reuse
> external ontologies as soon as it comes to application development.
>
>   
>> I am fine with the split, provided that an ontology service for each
>> kind of resource is mandatory, so that the meaning  of each resource
>> will not rely on anything predefined and specific for the application.
>> My point of view is the most easiest way is for everybody implementing
>> "feature" resource or "algorithm resource" is to implement its ontology
>> counterpart. For these to be compatible, we need a common description of
>> the ontologies, for example for descriptors we can use Blue Obelisk OWL
>> file (and perhaps extend it).  If all implementations depend on the same
>> e.g. OWL file , there should not be compatibility issues. 
>>
>> An example: Below is the RDF description of XLogP descriptor from BO
>> ontology.  MolecularDescriptor is a class, defined in the BO dictionary;
>> same for constitutionalDescriptor.   All OpenTox resources, implementing
>> XLogP could refer to this entry in BO ontology.  Additionally, we might
>> establish OWL for endpoints and annotate that XLogP is "Octanol water
>> partition coefficient" and "Octanol water partition coefficient" belongs
>> to "Physicochemical effects" (following ECHA vocabularity).
>>
>>         <MolecularDescriptor rdf:about="&me;xlogP">
>>             <rdfs:label>XLogP</rdfs:label>
>>             <dc:contributor rdf:resource="&me;mf"/>
>>             <dc:contributor rdf:resource="&me;elw"/>
>>             <dc:date>2005-01-27</dc:date>
>>             <definition rdf:parseType='Literal'>
>>                 Prediction of logP based on the atom-type method called
>>     XLogP.
>>             </definition>
>>             <description rdf:parseType='Literal'>
>>                 For a description of the methodology see
>>                 <bibtex:cite ref="WANG97"/>
>>                 .
>>             </description>
>>             <isClassifiedAs rdf:resource="&me;constitutionalDescriptor"/>
>>         </MolecularDescriptor>
>>
>>     
>>> Or do we want a central server that hosts at least
>>> the ontologies (it's the same questions for the feature ontology as
>>>   
>>>       
>> yes, of course it's the same issue.
>>     
>>> well)? That would make it easier to control the ontology vocabulary...
>>>   
>>>       
>> Well, I thought a set of common .owl files would be sufficient to keep
>> common vocabulary.
>>     
>
> If we adopt RDF for data exchange (see my separate post on this list),
> we might need ontology webservices to obtain valid URIs for the
> predicates (e.g.
> <http://blueobelisk.sourceforge.net/ontologies/chemoinformatics-algorithms/#xlogP>,
> but this link seems to be defunct). I suspect that local references
>   

> could also work, but this would mean a duplication of efforts (and we
> have to make sure that everyone uses the same vocabulary (version)).
> Although local files have their advantage, when it comes to single
> machine installations I would suggest the following strategy:
>
> - Use (and contribute to) external ontology services whenever possible
> - Run our own service(s) for vocabularies that do not fit into external
>   ontolgies
> - Pull the most recent owl files from these services for local
>   installations
>
>   
In fact what is still unclear to me is what is the best practice to
extend an ontology. Say there is a BO ontology at link
http://blueobelisk.sourceforge.net/ontologies/chemoinformatics-algorithms/#xlogP
,
will it be sufficient to create a separate RDF file where to define pKa
descriptor  and refer to it as 
http://blueobelisk.sourceforge.net/ontologies/chemoinformatics-algorithms/#pKA 
and of course further use it in an OpenTox service?

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