You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stanbol.apache.org by "Alessandro Adamou (Created) (JIRA)" <ji...@apache.org> on 2011/09/29 20:03:45 UTC
[jira] [Created] (STANBOL-332) Have OntoNet manage graphs in
Clerezza natively.
Have OntoNet manage graphs in Clerezza natively.
------------------------------------------------
Key: STANBOL-332
URL: https://issues.apache.org/jira/browse/STANBOL-332
Project: Stanbol
Issue Type: Improvement
Components: Ontology Manager
Reporter: Alessandro Adamou
Priority: Minor
OntoNet has been managing scopes, spaces and sessions so far, by creating OWL API objects that live throughout the whole Stanbol lifecycle, and are serialized for Web Services.
The current implementation creates OWL ontology objects that persist in memory even when they are not being used. This has the advantage to provide an axiom-oriented view on RDF graphs, which is very useful for applications and users that dig OWL(2).
However, it is also inefficient for a number of reasons:
- memory occupation with data that essentially replicate the content of the persistence layer
- no slick reaction to changes in low-level graphs. If an imported ontology is updated, or a new import is added, pre-existing axioms should be re-interpreted (e.g. for classification and other reasoning tasks). This generally doesn't happen, unless the ontologies are serialized and re-loaded in the OWL API ontology manager.
- non OWL-aware applications that use the OntoNet Java API are forced to handle OWL if they need to access RDF graphs.
An ideal solution would be to avoid loading ontologies in OWLOntologyManager objects when ontology scopes and sessions are set up. Ontology network information could be stored in the Clerezza TcManager just like every other RDF graph, and only when the content of a scope is requested as an OWL ontology it is brought up that way, to be then garbage-collected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (STANBOL-332) Have OntoNet manage graphs in
Clerezza natively.
Posted by "Alessandro Adamou (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alessandro Adamou resolved STANBOL-332.
---------------------------------------
Resolution: Fixed
> Have OntoNet manage graphs in Clerezza natively.
> ------------------------------------------------
>
> Key: STANBOL-332
> URL: https://issues.apache.org/jira/browse/STANBOL-332
> Project: Stanbol
> Issue Type: Improvement
> Components: Ontology Manager
> Reporter: Alessandro Adamou
> Priority: Minor
>
> OntoNet has been managing scopes, spaces and sessions so far, by creating OWL API objects that live throughout the whole Stanbol lifecycle, and are serialized for Web Services.
> The current implementation creates OWL ontology objects that persist in memory even when they are not being used. This has the advantage to provide an axiom-oriented view on RDF graphs, which is very useful for applications and users that dig OWL(2).
> However, it is also inefficient for a number of reasons:
> - memory occupation with data that essentially replicate the content of the persistence layer
> - no slick reaction to changes in low-level graphs. If an imported ontology is updated, or a new import is added, pre-existing axioms should be re-interpreted (e.g. for classification and other reasoning tasks). This generally doesn't happen, unless the ontologies are serialized and re-loaded in the OWL API ontology manager.
> - non OWL-aware applications that use the OntoNet Java API are forced to handle OWL if they need to access RDF graphs.
> An ideal solution would be to avoid loading ontologies in OWLOntologyManager objects when ontology scopes and sessions are set up. Ontology network information could be stored in the Clerezza TcManager just like every other RDF graph, and only when the content of a scope is requested as an OWL ontology it is brought up that way, to be then garbage-collected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira