Hi Tobias, Andreas,

Many thanks!

Please find my thoughts on this topic below.

*Slide 2: What resources to register*

Register: Algorithms and models, reports, validation, Dataset metadata and
feature representations , no feature values, no compounds.

*Slide 3: Deregistering*

Several approaches:
1)Services register/deregister themselves .  Crash and servers disapearing
can only be solved via timeouts / life span of a registration .   Using
keepalives complicates the protocol in many ways.
2)Services don‘t register themselves, the ontology server(s) which are
querying and gathering information (similar as a search engine – there are
bots that gather information, not web servers registering into Google data
centers)
3)Some compromise between the two (e.g. Services register once , the
ontology server acts like a bot and refreshes the info periodically)


*Slide 4: Duplicate registration*

If URIs are unique, there is no problem, the underlying RDF storage will
recognize duplicates.

There is a problem with anonymous resources in RDF though.  I would suggest
avoiding anonymous resources as much as possible.


*Slide 5:  Scenario: all necessary resources registered, but not all public:
*

We need a representation of users and their access rights in opentox.owl .
There is no RDF representation of users in opentox.owl so far.

LDAP  groups will need some RDF representation as well (perhaps there is an
existing ontology?) .  Some RDF storages have support for user accounts and
offer some levels of security.

In order to register a resource, the ontology server connects to the
resource and reads its RDF representation.  If the resource is protected,
the ontology server will not be able to read the RDF, unless it has rights
to do so.  How do we handle this situation?

As the ontology will publish metadata only (no compounds, no feature values)
there is not much danger in exposing sensitive resources.


*Slide 6: Quality of resources (how to test for compliance)*

Compliance – there should be computer readable specification (wadl, owl,
etc.) , which enables to check any OT service against it.
I have an initial draft of opentox-rest.owl, which aims at representing the
spec (REST operations) as an ontology, additional to opentox.owl, which
represents the resources themselves.
Will publish it shortly into Collaborative Protege.

Approval by named experts – (again) we would need RDF representation of
users (can use FOAF) and assign status of „Expert“ to some of them (how,
when, who will say who is an expert?)

Best regards,
Nina




On 8 November 2010 10:04, Tobias Girschick <tobias.girschick at in.tum.de>wrote:

> Hi All,
>
> as promised in last weeks meeting, I uploaded the notes Andreas K. and I
> took during our brainstorming session on the ontology service:
>
>
> http://www.opentox.org/data/documents/development/framework-design/ontology-service/view
>
> Andreas, please feel free to add anything I forgot.
>
> best regards,
> Tobias
>
> --
> Dipl.-Bioinf. Tobias Girschick
>
> Technische Universität München
> Institut für Informatik
> Lehrstuhl I12 - Bioinformatik
> Bolzmannstr. 3
> 85748 Garching b. München, Germany
>
> Room: MI 01.09.042
> Phone: +49 (89) 289-18002
> Email: tobias.girschick at in.tum.de
> Web: http://wwwkramer.in.tum.de/girschick
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>