Recall from Section 4.1.3.3, that when an ontology o, o2 O is managed by an ontology collector C, then a new ontology exists, called the C-image of o, which does not belong to the original knowledge base O. In addition, o can be managed by multiple ontology collectors at the same time, with the only exception of a single ontology space within each scope. This means that, if m are such ontology collectors, then m ontology images will be created for o or, to rephrase, o will have m images. In addition, these images will all be di↵erent, if anything because of the axioms that give them their names, per conditions (1) and (2) of the definition of ontology image.
This process of creating many di↵erent images from a single ontology is called multiplexing. Therefore, in order for an ontology to be multiplexed, it must be managed by at least one ontology collector, and there has to be a procedure that queries the ontology collector for the corresponding image.
An example of how ontologies can be multiplexed by an ontology collector is shown in Figure 4.6. In the figure, o1 and o2 are two ontologies in a knowledge base, i.e.
4.2 Virtual ontology network assembly in OWL 2
Figure 4.6: Multiplexing in an ontology collector - Ontology collector create images for ontologies stored in the knowledge base. Whenever the ontology reference has no version identifier, the collector sets its own identifier as a prefix for the version identifier of the image.
in their plain, unmanaged form. o1 ha a fully qualified reference (io1, vo1), while o2
has a reference that lacks a version identifier, (io2, nil). C is an abstract ontology
collector, whose specific type we need not know at this stage. We do, however, need to know its identifier, which we have expanded as (iC, nil) for compatibility with ontology
references1. C manages both o1 and o2, therefore each ontology has a C-image, oC1
and oC2, respectively. Because the reference of o1 was fully qualified, the collector does
not rewrite the version identifier of oC
1, which remains (io1, vo1). However, a version
identifier can computed for oC
2 as the concatenation of the collector identifier with the
ontology identifier, (iC||io2)2. The reference of o2C then becomes (io2, iC||io2).
The method described here uses specific ontology collector types in order to organize ontology images across three layers of complexity, which are called tiers. Each tier accommodates one single type of ontology collector only, and mainly communicates with adjacent ones via connectivity and dependency relations.
A schematic representation of the rationale behind this method is given in Figure 4.7. The basic tier, which we have numbered as zero, is the original knowledge base that
1Recall that the identifiers of ontology collectors are not versioned. 2We have used the vector concatenation operator ‘
||’ for generality; however, in cases such as RDF and OWL 2, where the identifiers are represented by URIs or IRIs, the string concatenation operator ‘.’ can be assumed.
constitutes the pool by which ontologies are taken from ontology collectors and thereby imaged. Tiers 1 and 2 accommodate two di↵erent classes of ontology space, called core spaces and custom spaces, respectively, while in tier 3 ontologies are distributed across sessions. Two adjacent tiers in the figure, naming those of core and custom spaces, are delimited by thicker strokes and grouped as the scopes layer, which hints at a grouping of core and custom ontology space pairs into scopes.
tier 3 Sessions tier 2 Custom spaces tier 1 Core spaces tier 0 Unmanaged ontologies Scopes
Figure 4.7: Distribution of ontologies across tiers in virtual ontology networks - Tier 0 contains the original knowledge base. In cases where an ontology with images in tiers 1 or 2 is natively networked, its image can still reference ontologies in tier 0. If an ontology is natively networked in tier 0, then its connectivity is preserved, thus still allowing for paths longer than 3.
The circles with an ontology icon inside denote ontologies1; those in tier zero are
the original, unmanaged ontologies, while those in the upper tiers are ontology images created by some collector. Dashed and dotted edges that connect ontologies indicate some connectivity relation between them, therefore every connected graph resulting from combining nodes edges, the latter being at least one, denote ontology networks. Also note that, in the figure, some unmanaged ontologies in tier zero belong to ontology networks. This happens whenever an ontology collector is set to manage an ontology
1The standard ontology icon was used in lieu of identifiers because the latter are not relevant in
4.2 Virtual ontology network assembly in OWL 2
that is natively networked, i.e. designed by its developers to already be part of an ontology network, or in other words, that is part of a statically assembled ontology network. For example, if the Agent-Role ontology design pattern [Prea] is set to be managed by a core space [Preb], because this pattern inherits from other patterns such as Object-Role [Prec] and Classification [Preb] and is therefore part of a static ontology network, these other patterns will be in Tier 0 and will be indirectly referenced by the ontology space that manages Agent-Role.
Each tier has its own way of setting its management status on submitted ontologies. The following sections provide algorithmic support to each tier built upon the base one.