management, as well as the documental contributions provided by the World Wide Web Consortium, do not fully address the problem space delimited by the aspects of networking and relatedness. Therefore, part of the burden of addressing these problems lies upon application developers, who are faced with computational resource manage- ment issues and the need to trade them o↵ with the normative specifications above. Assumptions A4 (i.e. the existence of software) and A8 (i.e. the black-box nature of its ontology interpretation functions) altogether form this complementary space, which is both a solution provider and a problem source, as verified further on in Section 3.5.1.
3.5
Hypotheses
The objectives identified earlier, under the assumptions made, allow us to formulate a series of hypotheses, to be proven or disproven as our research work proceeds.
H0. (null hypothesis) The layout of ontology networks, i.e. the ways networked on- tologies are connected with one another, has no e↵ect on their interpretation in OWL.
H1. If each application sets up dedicated ontology artifacts that reference the (persis- tent and volatile) knowledge required, then each artifact determines a standalone ontology network that lives independently on any other ontology network. H2. Spreading the components required by an ontology network across a 3-tier on-
tological structure will reduce the amount of axioms that cannot possibly be interpreted correctly compared to using a flat import scheme.
H3. An aggressive ownership and persistence policy applied to the data payload, and a conservative policy applied to the shared knowledge base portions, can reduce the memory occupation of concurrent ontology networks by at least one third of the memory occupied by each ontology network if it were fully in its own memory space.
3.5.1 Null hypothesis negation
That the null hypothesis H0 be untrue under the assumptions made, it can be verified through a simple counterexample to begin with. In the following, the original ontologies have been serialized in Turtle syntax.
Given the following prefix assignment:
@prefix : <http://www.ontologydesignpatterns.org/ont/test/ontonet#> . @prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix connected: <http://www.ontologydesignpatterns.org/ont/test/ ontonet/imports-connected/> .
@prefix disconnected: <http://www.ontologydesignpatterns.org/ont/test/ ontonet/imports-disconnected/> .
let ontology network Odisconn have the following root node (i.e. the ontology that
is encountered first when visiting the whole network): disconnected:root.owl rdf:type owl:Ontology ;
owl:imports disconnected:abox.owl , disconnected:tbox.owl .
The root ontology therefore directly imports both a TBox ontology and an ABox ontology. The imported ABox ontology is encoded as follows:
disconnected:abox.owl rdf:type owl:Ontology . :Alex a :Person ;
:knows :Begona . :Begona a :Person .
The imported TBox ontology is encoded as follows: disconnected:tbox.owl rdf:type owl:Ontology . :knows a owl:ObjectProperty .
When root.owl was loaded using the OWL API 3 [OWLa] (e.g. by using Prot´eg´e 4.2) [Pro], the following OWL interpretation was returned (in OWL functional syntax)1:
1This ontology network example is available online at the intended URL http://www.
3.5 Hypotheses
Declaration(ObjectProperty(:knows)) ClassAssertion(:Person :Alex)
ClassAssertion(:Person :Begona)
AnnotationAssertion(:knows :Alex :Begona)
Note the presence of the axiom AnnotationAssertion(:knows :Alex :Begona). The fact that it was interpreted as an annotation assertion in OWL implies the impos- sibility to reason on it, as non-logical axioms are not computed in DL. In terms of the leading example introduced in Section 1.1.2.1, this means that, even if we were able to place the papers authored by Begona in the friends directory of Alex, we would still be unable to place those from people in Begona’s network in the friends-of-friends directory, unless we fell back to low-level querying such as SPARQL.
Now let ontology network Oconn have the following root node:
connected:root.owl rdf:type owl:Ontology ; owl:imports connected:abox.owl .
The root now only imports an ABox ontology, which is exactly the same as before, except that it imports the TBox ontology:
connected:abox.owl rdf:type owl:Ontology ; owl:imports connected:tbox.owl .
:Alex a :Person ; :knows :Begona . :Begona a :Person .
The imported TBox ontology is also the same as before, except for its name: connected:tbox.owl rdf:type owl:Ontology .
When root.owl is loaded using the same OWL API version, the following OWL interpretation is given1:
Declaration(ObjectProperty(:knows)) ClassAssertion(:Person :Alex)
ClassAssertion(:Person :Begona)
ObjectPropertyAssertion(:knows :Alex :Begona)
That is, what was interpreted as an annotation assertion in the network layout of Odiscconn, is interpreted as an object property assertion in Oconn. The latter is more
desirable, since it respect the explicit declaration of :knows as an object property made in each TBox ontology.
This counterexample proves that simply appending each ontology as subtrees to a root node will not work, because there are common ontology management applications which visit ontology networks (in this case built on OWL import declarations) in a way that can cause object property assertions to be interpreted as annotations, and to be potentially ignored by reasoners.
Further tests, here omitted for simplicity, have also invalidated the null hypothesis, and hinted that the manipulation of ontology network structures could be one way to counter the problem of erroneous OWL interpretation.