You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by florent andré <fl...@4sengines.com> on 2012/01/17 00:52:14 UTC
Save Skos thesauri, modify, map and share them
Hi Stanbolers !
I have a use case that begin with some thesauri in Spreadsheets / CSV
format (D'oh !).
I have to transform them into a correct Skos format (not the hard part,
I already have some demo code about this), and then store them.
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)
- User will be able to map concepts from one skos to another one.
- Standard user can only modify his maps ; power users can modify all
maps (latter requirement)
- Skos thesauri and concept have to be dereferencables.
Hard point of the question is not really on the user interface, I may
have a clue to deal with...
My question is about the backstage for it.
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...
Can you provide any pointers / thoughts about this use case to an
ontoNewbee ?
++
[1] :
http://stanbol.staging.apache.org/stanbol/docs/trunk/ontologymanager.html
Re: Save Skos thesauri, modify, map and share them
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Florent,
Sorry for getting back to you so late on your feedback, kind of slipped
through - hope you can still put my answer to use now.
On 1/19/12 2:52 PM, florent andré wrote:
> What I clearly understand now it that all is store in the
> Stanbol/clerezza store.
> And that I can store thesauri directly via repository or via Ontonet.
>
> What is not totally clear for me now are the concepts of "spaces",
> "session" and "scope"...
Don't worry about spaces right now. You can just assume for now, that
into scope S1 you will load
- The SKOS ontology into its core space "S1.core"
- The thesauri for a specific user into its custom space "S1.custom" (if
these thesauri can coexist without creating inconsistencies, otherwise a
single user might need multiple scopes).
/****** Free-thought rambling ******/
A much more sophisticated use of spaces, not currently implemented,
could be:
- load the SKOS ontology in S1.core
- load the initial, unabridged thesaurus in S1.custom
- then we could have "user spaces" on top of the custom spaces (similar
to the now-deprecated session spaces) to store diffs for each user's
reorganization of the thesaurus.
e.g. in the initial thesaurus says that Concept 1 and Concept2 are siblings
- in S1.userA : "Concept1 skos:narrower Concept2"
- In S1.userC : "Concept2 skos:altLabel Concept1"
... and these "user spaces" would not see each other, unless one user
explicitly decides to inspect another user's thesauri and handle overlaps.
The hardship in implementing this is the monotonic nature of the
Semantic Web: we would have to implement axiom negation and such.
/****** END Free-thought rambling ******/
> In my usecase I will have many users that each save one to many
> thesaurus :
> - user A will store thesaurus 1 (TA1) and TA2
> - user B will store thesaurus 1 (TB1) and TB2 and ...
>
> When user C store his TC1 he will choose to map-it to one already
> existing depending on the more appropriate one.
>
> Let's say he select the TA2.
>
> So, the mapping will be done between TC1 and TA2 (and any others
> combinations can be done afterwards).
which is why I think it is best to use scopes here. Because one user
needs to reference knowledge managed by another user.
Sessions are volatile, so you shouldn't use them for cross-user
referencing. Sessions come into play the moment you need to do something
like "Hey Stanbol, here are my data for today, please classify them
according to this SKOS schema here and that one there".
> ... for my user C :
> - I create a sessionC
> - I create a "C-skos-thesaurus" scope
> - Load TC1 in "C-skos-thesaurus".coreSpace
> - load TA2 in "C-skos-thesaurus".customSpace
> - then store mappings done in sessionC
>
> That's a good use of session, scope and space ?
Quite close indeed. I would imagine a scenario such as this.
User A:
* creates "A-skos-thesaurus" scope
* loads the SKOS ontology in "A-skos-thesaurus".core and TA2
"A-skos-thesaurus".custom
User C:
* creates "C-skos-thesaurus" scope
* loads the SKOS ontology in "C-skos-thesaurus".core and TC1
"C-skos-thesaurus".custom
* opens session C-201202061828
* store SKOS mappings in an ontology
http://example.org/C-skos-alignments and load it onto C-201202061828
--> the mappings will be stored to persistence even if they are loaded
on a session, but you will not need the time-identifier to retrieve it:
it will be stored as
[stanbol-host]/ontonet/http://example.org/C-skos-alignments
If C also wants to obtain additional inferred mappings, he will:
* attach scopes "C-skos-thesaurus" and "A-skos-thesaurus" to C-201202061828.
* call Stanbol Reasoners and tell it to classify session "C-skos-thesaurus"
>> 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.
Ok, so my understanding from our exchange is that overlaps are possible
and partitioning is unlikely.
>> 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!
>
> Thesauri I will import don't have prior IRIs (they are in CSV).
Ok - I don't know of any CSV support in Stanbol, though... should be
ported to RDF beforehand.
> So I can set up them as I want and in line with the server name.
Okay. I would not rule out adding a REST resource to OntoNet that, if it
identifies the URI to be an entity, returns its signature (e.g. by a
SPARQL DESCRIBE or an EntityHub query)
> Get old names is really problematic... only currents one will be
> interesting...
> Redirect from old to current with the help of modifications history
> could be really good...
It's not in the short-term plans for OntoNet, but for now I guess we
could add some "safe" OWL equivalences. Anyway if the deal is to only
bring current names "to the front" for now, it shouldn't be a big
bottleneck.
>> * what would your mappings look like? depending on the complexity, you
>> could find Stanbol Rules to be of use too.
>
> For now (it's not clearly define though), mapping will be done with
> SKOS properties.
Ok, then I guess we just need to call different reasoning primitives
(enrich rather than classify) when needed.
> * It's better to use rules in this case (mapping TC1 / TA2) ?
> Constraints (for now) are to be able to get :
> - original thesaurus (just TC1)
> - or the complete one (TC1 and TA2 with mappings)
I'm not sure I understand, but it seems to me that the latter could use
Stanbol Rules.
> No clear idea of the size of each individuals thesaurus... The point
> here is more the amount of thesaurus...
> IMO : 15+ of not so big thesauri.
ok so we're around the tens-to-hundreds of triples as I read in the
proposal.
HTH
Best,
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
Re: Save Skos thesauri, modify, map and share them
Posted by John Pereira <jo...@salzburgresearch.at>.
Hi
Alessandro
To did you get a chance to read Florent's latest blog http://blog.iks-project.eu/thesaurus-management-tool-linked-heritage-project/
You may also want to follow the work of the Skos-js editor that our colleague here at Salzburg Research is working on, See https://github.com/tkurz/skosjs
Thanks
john
On Apr 11, 2012, at 12:29 PM, Alessandro Adamou wrote:
> Hi Florent, all,
>
> Just curious - have you been able to make any progress on using the Ontology Manager for multi-user thesaurus management in your application?
>
> Should you have any questions or inquiries please do not hesitate to ask.
>
> Alessandro
>
>
> On 1/19/12 2:52 PM, florent andré wrote:
>> Hi Alessandro,
>>
>> Thanks for answers.
>>
>> What I clearly understand now it that all is store in the Stanbol/clerezza store.
>> And that I can store thesauri directly via repository or via Ontonet.
>>
>> What is not totally clear for me now are the concepts of "spaces", "session" and "scope"...
>>
>> In my usecase I will have many users that each save one to many thesaurus :
>> - user A will store thesaurus 1 (TA1) and TA2
>> - user B will store thesaurus 1 (TB1) and TB2 and ...
>>
>> When user C store his TC1 he will choose to map-it to one already existing depending on the more appropriate one.
>>
>> Let's say he select the TA2.
>>
>> So, the mapping will be done between TC1 and TA2 (and any others combinations can be done afterwards).
>>
>> So...
>>
>> On 01/17/2012 10:54 AM, Alessandro Adamou wrote:
>> ...
>>>
>>>> - 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.
>>
>> ... for my user C :
>> - I create a sessionC
>> - I create a "C-skos-thesaurus" scope
>> - Load TC1 in "C-skos-thesaurus".coreSpace
>> - load TA2 in "C-skos-thesaurus".customSpace
>> - then store mappings done in sessionC
>>
>> That's a good use of session, scope and 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?)
>>
>> Yep I know that, let's see what append on this subject... even without a framework level solution a little workaround could not be so hard to set-up.
>>
>>>
>>>> - 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!
>>
>> Thesauri I will import don't have prior IRIs (they are in CSV).
>> So I can set up them as I want and in line with the server name.
>>
>> Get old names is really problematic... only currents one will be interesting...
>> Redirect from old to current with the help of modifications history could be really good...
>>
>>>
>>>> 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.
>>
>> For now (it's not clearly define though), mapping will be done with SKOS properties.
>>
>> * It's better to use rules in this case (mapping TC1 / TA2) ?
>> Constraints (for now) are to be able to get :
>> - original thesaurus (just TC1)
>> - or the complete one (TC1 and TA2 with mappings)
>> Also be able to do some reasoning on it will be great value added.
>>
>>> * do you have an insight on the size of your thesaurus, in an
>>> entries/triples? Is it a huge, undivided bulk or would it make sense to
>>> partition it?
>>
>> No clear idea of the size of each individuals thesaurus... The point here is more the amount of thesaurus...
>> IMO : 15+ of not so big thesauri.
>>
>>> * 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?
>>
>> Don't know for now, depending how I can answer to requirements...
>>
>>>
>>> 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
>
>
> "I will give you everything, so long as you do not demand anything."
> (Ettore Petrolini, 1930)
>
> Not sent from my iSnobTechDevice
>
Re: Save Skos thesauri, modify, map and share them
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi Florent, all,
Just curious - have you been able to make any progress on using the
Ontology Manager for multi-user thesaurus management in your application?
Should you have any questions or inquiries please do not hesitate to ask.
Alessandro
On 1/19/12 2:52 PM, florent andré wrote:
> Hi Alessandro,
>
> Thanks for answers.
>
> What I clearly understand now it that all is store in the
> Stanbol/clerezza store.
> And that I can store thesauri directly via repository or via Ontonet.
>
> What is not totally clear for me now are the concepts of "spaces",
> "session" and "scope"...
>
> In my usecase I will have many users that each save one to many
> thesaurus :
> - user A will store thesaurus 1 (TA1) and TA2
> - user B will store thesaurus 1 (TB1) and TB2 and ...
>
> When user C store his TC1 he will choose to map-it to one already
> existing depending on the more appropriate one.
>
> Let's say he select the TA2.
>
> So, the mapping will be done between TC1 and TA2 (and any others
> combinations can be done afterwards).
>
> So...
>
> On 01/17/2012 10:54 AM, Alessandro Adamou wrote:
> ...
>>
>>> - 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.
>
> ... for my user C :
> - I create a sessionC
> - I create a "C-skos-thesaurus" scope
> - Load TC1 in "C-skos-thesaurus".coreSpace
> - load TA2 in "C-skos-thesaurus".customSpace
> - then store mappings done in sessionC
>
> That's a good use of session, scope and 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?)
>
> Yep I know that, let's see what append on this subject... even without
> a framework level solution a little workaround could not be so hard to
> set-up.
>
>>
>>> - 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!
>
> Thesauri I will import don't have prior IRIs (they are in CSV).
> So I can set up them as I want and in line with the server name.
>
> Get old names is really problematic... only currents one will be
> interesting...
> Redirect from old to current with the help of modifications history
> could be really good...
>
>>
>>> 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.
>
> For now (it's not clearly define though), mapping will be done with
> SKOS properties.
>
> * It's better to use rules in this case (mapping TC1 / TA2) ?
> Constraints (for now) are to be able to get :
> - original thesaurus (just TC1)
> - or the complete one (TC1 and TA2 with mappings)
> Also be able to do some reasoning on it will be great value added.
>
>> * do you have an insight on the size of your thesaurus, in an
>> entries/triples? Is it a huge, undivided bulk or would it make sense to
>> partition it?
>
> No clear idea of the size of each individuals thesaurus... The point
> here is more the amount of thesaurus...
> IMO : 15+ of not so big thesauri.
>
>> * 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?
>
> Don't know for now, depending how I can answer to requirements...
>
>>
>> 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
"I will give you everything, so long as you do not demand anything."
(Ettore Petrolini, 1930)
Not sent from my iSnobTechDevice
Re: Save Skos thesauri, modify, map and share them
Posted by florent andré <fl...@4sengines.com>.
Hi Alessandro,
Thanks for answers.
What I clearly understand now it that all is store in the
Stanbol/clerezza store.
And that I can store thesauri directly via repository or via Ontonet.
What is not totally clear for me now are the concepts of "spaces",
"session" and "scope"...
In my usecase I will have many users that each save one to many thesaurus :
- user A will store thesaurus 1 (TA1) and TA2
- user B will store thesaurus 1 (TB1) and TB2 and ...
When user C store his TC1 he will choose to map-it to one already
existing depending on the more appropriate one.
Let's say he select the TA2.
So, the mapping will be done between TC1 and TA2 (and any others
combinations can be done afterwards).
So...
On 01/17/2012 10:54 AM, Alessandro Adamou wrote:
...
>
>> - 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.
... for my user C :
- I create a sessionC
- I create a "C-skos-thesaurus" scope
- Load TC1 in "C-skos-thesaurus".coreSpace
- load TA2 in "C-skos-thesaurus".customSpace
- then store mappings done in sessionC
That's a good use of session, scope and 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?)
Yep I know that, let's see what append on this subject... even without a
framework level solution a little workaround could not be so hard to set-up.
>
>> - 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!
Thesauri I will import don't have prior IRIs (they are in CSV).
So I can set up them as I want and in line with the server name.
Get old names is really problematic... only currents one will be
interesting...
Redirect from old to current with the help of modifications history
could be really good...
>
>> 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.
For now (it's not clearly define though), mapping will be done with SKOS
properties.
* It's better to use rules in this case (mapping TC1 / TA2) ?
Constraints (for now) are to be able to get :
- original thesaurus (just TC1)
- or the complete one (TC1 and TA2 with mappings)
Also be able to do some reasoning on it will be great value added.
> * do you have an insight on the size of your thesaurus, in an
> entries/triples? Is it a huge, undivided bulk or would it make sense to
> partition it?
No clear idea of the size of each individuals thesaurus... The point
here is more the amount of thesaurus...
IMO : 15+ of not so big thesauri.
> * 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?
Don't know for now, depending how I can answer to requirements...
>
> Please feel free to write to the list on my attention for further
> inquiries.
>
> Alessandro
>
Re: Save Skos thesauri, modify, map and share them
Posted by florent andré <fl...@4sengines.com>.
Rupert,
Do you also have some medium capabilities ? :)
It's will be one of my furthers questions !
As the first step, this will really be centred on thesauri management.
For a second step being able to run engine(s) from them will be really
great value.
A step further, as it will be a public service (and thinking of one
Reto's comments) it will be really cool to be able to export a Stanbol
engine+index bundle directly pluggable into a "personal" Stanbol instance...
++
On 01/18/2012 08:30 AM, Rupert Westenthaler wrote:
> Florent, I think you plan to use the SKOS thesauri in combination with
> the KeywordExtrationEngine. Is that right?
>
> For the KeywordExtrationEngine engine to work efficiently the SKOS
> thesauri should be stored within a SolrYard of the Entityhub. In
> principle it would be also possible to use the ClerezzaYard
> implementation, but I think that the performance for label based
> search will be much worse than with Solr based implementation of the
> Yard interface.
>
> So if one wants to "manage" the SKOS thesauri via OntoNet but still
> use it with the Stanbol Enhancer than we need to integrate the
> Entityhub and OntoNet somehow.
>
> Alessandro,
>
> * do you think that OntoNet could use the Yard interface of the
> Entityhub as storage interface?
> * is it more realistic to re-index changed concepts (after changes
> performed in a Session, Context) to the Entityhub.
>
> Any other suggestions?
>
> best
> Rupert
>
> On Tue, Jan 17, 2012 at 10:54 AM, Alessandro Adamou<ad...@cs.unibo.it> wrote:
>> 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
>>
>
>
>
Re: Save Skos thesauri, modify, map and share them
Posted by Rupert Westenthaler <ru...@gmail.com>.
Florent, I think you plan to use the SKOS thesauri in combination with
the KeywordExtrationEngine. Is that right?
For the KeywordExtrationEngine engine to work efficiently the SKOS
thesauri should be stored within a SolrYard of the Entityhub. In
principle it would be also possible to use the ClerezzaYard
implementation, but I think that the performance for label based
search will be much worse than with Solr based implementation of the
Yard interface.
So if one wants to "manage" the SKOS thesauri via OntoNet but still
use it with the Stanbol Enhancer than we need to integrate the
Entityhub and OntoNet somehow.
Alessandro,
* do you think that OntoNet could use the Yard interface of the
Entityhub as storage interface?
* is it more realistic to re-index changed concepts (after changes
performed in a Session, Context) to the Entityhub.
Any other suggestions?
best
Rupert
On Tue, Jan 17, 2012 at 10:54 AM, Alessandro Adamou <ad...@cs.unibo.it> wrote:
> 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
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: Save Skos thesauri, modify, map and share them
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
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