[OTDev] Ontology service

Tobias Girschick tobias.girschick at in.tum.de
Mon Nov 15 16:20:45 CET 2010


Dear All,

I added a summary of the results of today's SWDT discussion on the
ontology service to the respective API 1.2 page.

http://www.opentox.org/dev/apis/api-1.2/Ontology%20service

regards,
Tobias


On Fri, 2010-11-12 at 11:33 +0100, Tobias Girschick wrote: 
> Dear All,
> 
> as next Monday's SWDT agenda contains "Ontology Service Specifications &
> Development - feedback and discussion", and Barry asked us to organize
> the feedback, it would be great if people could give some feedback
> either here on the mailing list (as Nina already did), or in a direct
> mail to Andreas Karwath or me. 
> The slides from last Monday's meeting can be found here:
> http://www.opentox.org/data/documents/development/framework-design/ontology-service/view
> 
> best regards,
> Tobias
> 
> On Mon, 2010-11-08 at 10:09 +0100, Tobias Girschick wrote: 
> > On Mon, 2010-11-08 at 10:59 +0200, Nina Jeliazkova wrote:
> > > 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)
> > 
> > I like that idea (3). 
> > 
> > > 
> > > 
> > > 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 agree. 
> > 
> > > 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?)
> > 
> > Well, that is hard to say. I guess, at least in the beginning, we would
> > have to do that. But the very important fact is that the name of the
> > expert appears (and maybe some short profile or link). 
> > 
> > Best regards,
> > Tobias
> > 
> > > 
> > > 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 
> > > 
> > 
> 

-- 
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




More information about the Development mailing list