[jira] [Updated] (STANBOL-497) A policy for touching lazy libraries when requesting ontologies from OntoNet.

["Alessandro Adamou (Updated) (JIRA)" <ji...@apache.org>]

     [ 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