[
https://issues.apache.org/jira/browse/STANBOL-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessandro Adamou updated STANBOL-497:
--------------------------------------
Description:
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.
Policy (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. Policy (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. Policy (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.
was:
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.
> 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.
> Policy (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. Policy (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. Policy (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
