[OTDev] Dataset features in Ontology

Egon Willighagen egon.willighagen at gmail.com
Fri Apr 8 09:22:08 CEST 2011


Hej Nina,

On Thu, Apr 7, 2011 at 10:05 PM, Nina Jeliazkova
<jeliazkova.nina at gmail.com> wrote:
>> Nina, does the OpenTox ontology distinguish currently between a model
>> / algorithm instance and its specification?
>
> Yes, algorithms and models are different resources by design.

I meant rather if instances of models and algorithms *compared to*
their specifications are different.

The things I had in mind here is the following. We have some piece of
software running on some remote machine, and we have a specification
that says what it does. Now, it's not important of this piece of
software is an Algorithm or a Model, they both have a specification.
So, the ontological description could be the specification, and the
REST end point the actual running software.

Now, if the OpenTox API does in fact distinguish between these two
concepts (actual running code and the specification), the PSO ontology
is easily applicable, because it can make statements about the
specifications. The implication that the running software is no longer
available if its specification has been 'withdrawn'.

>> (This reminds me about the discussion of http://example.org/SomeTopic
>> is the URI of a webpage or the URI of the resource described on that
>> webpage :)
>
> Arrrgh ... we'd better take more pragmatic route in OT, we are dealing with
> live online resources, addressable by URIs. They are both informational
> (description of the resource) and non-informational (e.g. the model resource
> itself is richer than its RDF description), to use the terminology from [1].

Pragmatic++

<snip>

In that respect, it would probably be much better to use ideas of PSO
rather than using it. Ontologies are cheap. So, which predicates would
be good to have in OpenTox? The ontology focusing on the state of the
service, and the ontology looks pretty bad to me, in fact, with
overlapping concepts and labels that can be applicable at the same
time.

I guess these include (following the life cycle of a service):

draft
published
retracted

Then on top of that there are other aspects that might be interesting:

peer reviewed
archived

But then you'd might in fact also like pointers to replacements,
updates, etc. It might indeed be interesting to archive service
specifications of published services. So that one people can look up
details (in the "OpenTox Service Archive") of services used in some
calculation at some point.

Well, there is so much that can be done, and I lost what it was that
got this thread started... what is the problem to be solved again?

Egon

-- 
Dr E.L. Willighagen
Postdoctoral Researcher
Institutet för miljömedicin
Karolinska Institutet (http://ki.se/imm)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers



More information about the Development mailing list