On 12 November 2010 14:58, Christoph Helma <helma at in-silico.ch> wrote:

> 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,
> ...).
>

It's not necessary to register all objects (e.g. available), so
substructures could be just avoided.  Otherwise, features provide major
linking between other components, many queries will be impossible without
them and this questions the very idea of using SPARQL and RDF storage for
registration purposes.

Just my two cents.
Nina


>
> > *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
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>