Dear all,

Here are my 5 cents:

> *Slide 2: What resources to register*

Register: Algorithms, models, reports, validation, datasets

no compounds, features and feature values

I always had the impresion that the Ontology service should register
resource URIs, not complete resources or metadata (still acessible
through resource URIs). 

I can see a point in registering features (make them accessible for
searches and resoning), but I think it is
impractical to register e.g 10000+ features that might come from
substructure mining. Also features are implicitly registered (and
available) trough their parent resources (datasets, models, reports,
...). 

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

That sounds like a good idea! Would that mean, that individual resources
would have carry a metadata tag that tells the ontology service to
include the resource?

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

At present I cannot imagine anonymous models, algorithms, datasests or
reports. Features could be anonymous in datasets which might be taken as
another argument against registering features (although I would prefer
non-anonymous features).

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

Maybe the easiest solution in the beginning is to publish only public
resources in the Ontology service (could be another incentive to make
resources public) and to modify the strategy later as soon as we have
more experience with A+A.  If I understand A+A correctly the ontology
server will be unable to read protected resources unless it has some
super-user privileges.

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

I would like to see automated tests that use opentox-rest.owl
> 
> 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?)

Why not proceed like this:

- Resource owner decides to publish, resource will be available through the Ontology service.
- Other users (maybe only non-anonymous) have the facility to comment, which would resemble a post publication review process.

I expect that this could 

	- reduce the barrier for publishing resources
	- remove the necessity of a formal review with invited experts 
	- improve resources by accounting for comments/criticisms
	- improve resource usage (e.g. a resource might
	  be perfect for early screening, but not for regulatry porposes -
		such experiences can be described in comments)

Best regards,
Christoph