A policy for touching lazy libraries when requesting ontologies from OntoNet.
-----------------------------------------------------------------------------
Key: STANBOL-497
URL: https://issues.apache.org/jira/browse/STANBOL-497
Project: Stanbol
Issue Type: Improvement
Components: Ontology Manager
Reporter: Alessandro Adamou
Assignee: Alessandro Adamou
The Ontology Registry Manager lazy loading policy allows to load and store the
ontologies in a library only once the contents of that library are requested
(-> "touch" the library).
However, one might request an ontology from the Ontology Manager, without
having to know if it is being referenced by a library, and which library should
be touched in order to load the ontology.
For example, suppose the FOAF ontology is (a) a child of LibraryA, which
contains 50 ontologies; (b) also a child of LibraryB, which contains 10
ontologies; (c) individually loaded into ontology scope S.
The problem is, if OntoNet gets a request for FOAF, where should it get the
ontology from?
- If (a,b,c) all occur and LibraryA and LibraryB have NOT been loaded (because
of the lazy policy), it should get the version from S.
- If (c) is not occurring, then either LibraryA or LibraryB (but not both)
should be loaded before retrieving FOAF. The original request should not fail
while the library is being loaded.
The user should not bother to specify "get me the FOAF ontology from S" or "get
me the FOAF ontology from LibraryA", unless she deliberately wants to do so.
Different implementations define different policies:
1) The OntoNet RESTful API first asks the OntologyProvider for the stored
version of FOAF. If it cannot find one, asks the RegistryManager to load a
library that references FOAF.
2) The OntoNet RESTful API only asks the OntologyProvider. As the request
occurs, the RegistryManager captures an event, selects a library, loads it and
stores FOAF before the store is queried.
3) The OntoNet RESTful API only asks the OntologyProvider. The request fails.
The RegistryManager reacts to the failure, selects a library, loads it and
stores FOAF. A second request is issued for retrieving it.
Strategy (1) ensures the OntologyProvider takes precendence over registries and
that everything occurs in series during a single call, but defers this business
logic to the Web component. Strategy (2) opens us to the risk that a large
library could be loaded just for an ontology that maybe was already stored by
the OntologyProvider. Stragegy (3) is the least practicable due to the need to
react on a failed request with another request (not very applicable in REST).
Even so, there is still the problem of selecting the most appropriate library.
Loading the library with fewer ontologies can be one criterion, but a few
graphs could be very large, while many graphs could be small. However, we
cannot determine the size with certainty before loading the ontologies.
--
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
