Hi Egon,


Egon Willighagen wrote:
> Hi Nina,
>
> On Wed, Oct 28, 2009 at 2:45 PM, Nina Jeliazkova <nina at acad.bg> wrote:
>   
>> - Do we need to make distinction between different e.g. XLogP
>> implementations (I would say yes) ?
>>     
>
> I think so too.
>
>   
>> Is it possible to handle this via BO ontology, or we need an extension?
>>     
>
> The ontology I am working on supports this.
>
>   
>> - What would be the best way to extend BO ontology (this is more a
>> question to Egon)?
>>     
>
> By simply adding classes and axioms. But the above is covered...
>
>   
>> - How would we handle quantities, defined in existing data sets (e.g.
>> all LogP flavours available in EPA DSSTOX), not calculated via OpenTox,
>> or an user uploaded dataset.
>> - How to handle quantities, calculated via some algorithm, but with
>> different parameters (e.g. eHOMO calculated with AM1 or PM3).
>>
>> I would prefer that the property (e.g. blueobelisk:xlogp) refer to a
>> specific implementation, rather to the algorithm itself  (same concept
>> as algorithm/model split we already invented).
>> The implementation itself will be linked to the algorithm.
>>     
>
> Agreed; the ontology works like that.
>
>   
>> We would need a way to handle dynamically defined properties and even
>> ontologies.  I am particularly thinking of user-defined datasets.
>>     
>
> One advantage of RDF is that everyone can contribute... Bioclipse
> allows people to 'add' descriptors by providing a number of RDF
> triples...
>
>   
Please excuse the naive question, could you tell how this technically
happens -  to add an entry in e.g. BO descriptors is it sufficient to
create a separate file and just refer to BO URL, or every time one needs
to edit that single "master" owl file at BO site?  (same for other
ontologies).

There will be number of OpenTox services, providing  e.g descriptor
calculation.  One scenario is a client application looking for any
implementation of particular descriptor across several services. 
We can solve this by making services register themselves in a single
place, but this approach has its own complications.  I am curious what
would be the RDF-based solution?
>>>   - It can help us to solve the problem of unique IDs, by using URIs
>>>
>>>       
>> AFAIK, that will require an RDF store for the ontology service
>> (centralised one?)  - am I right?   It would be good if three is a
>> distributed solution.
>>     
>
> RDF is highly distributed... the store can take many formats. A simple
> file on a web server, a full fledged RDF triple store with SPARQL
> frontend, or XHTML with the RDF embedded.
>
>   
Yes, but I have an impression the current state of the art for querying
is gathering everything on a central space and then performing the query
- I hope I am wrong :)

Best regards,
Nina
> Egon
>
>