Hi Florent,
As a matter of fact, Stanbol isn't entirely new to that, thanks to our
Stanbol adopters who are already managing SKOS thesauri with OntoNet.
They might be able to tell you more on that.
From my side:
After storing :
- User will be able to modify them easily (I start some svg code for
it) and store this modifications (with history keeping could be cool)
to actually perform the updates (and storage), you could either use the
ontologymanager/store component, or interact with it via Clerezza if
instead you opt to load the thesaurus via OntoNet scopes or a session.
If you choose to go the OntoNet way, for each ontology collector (spaces
- which in turn make scopes - or sessions) it tells you what Clerezza
graphs its contents map to.
- User will be able to map concepts from one skos to another one.
Setting up one Session per active user, where the mappings are managed,
should do the trick. To obtains the entities to map from and to, you
could set up a "my-skos-thesaurus" scope, load SKOS in its core space
and the thesaurus in its custom space.
Even better, if you think you can benefit from partitioning the
thesaurus somehow, you can manage multiple scopes with one partition in
the custom space of each. This usually comes into play if you need to
perform some reasoning.
- Standard user can only modify his maps ; power users can modify all
maps (latter requirement)
Rule of thumb (which however is currently not enforced by the framework) is:
* sessions are managed by unprivileged users or client applications
* scopes can be read-accessed by anyone, but only privileged users or
Stanbol plugins should create or tamper with them.
As a matter of fact, anyone can do anything right now because we've no
REST API with authentication (yet? should we?)
- Skos thesauri and concept have to be dereferencables.
OntoNet has a mechanism for "hijacking" every loaded ontology into
Stanbol, and creating dynamic import statements. It is mainly designed
for ontology collectors, but can also be applied to ontologies not
loaded in a scope/session.
As for the *concepts*, there's no rewriting of entity IRIs, nor were we
sure to do it as logically it would open a can of worms - that is,
unless we add an OWL equivalence statement everytime a concept is
"moved", but even so all the "old" names should still be dereferenceable!
I "feel" that ontonet/kres can be great help on it, I read
documentation I find about (mails and [1] essentially), but can't get
clear picture of what is already there and what it not for this usecase...
More documentation is coming right these days, in the meantime I hope
I've given you a clearer picture.
I'd have a few questions, too:
* what would your mappings look like? depending on the complexity, you
could find Stanbol Rules to be of use too.
* do you have an insight on the size of your thesaurus, in
entries/triples? Is it a huge, undivided bulk or would it make sense to
partition it?
* I assume you would interact with OntoNet via the REST API, or would
you need to add some server-side interaction with the Java API using a
new OSGi bundle or so?
Please feel free to write to the list on my attention for further inquiries.
Alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"As for the charges against me, I am unconcerned. I am beyond their timid, lying
morality, and so I am beyond caring."
(Col. Walter E. Kurtz)
Not sent from my iSnobTechDevice
