This section illustrates how ontology collectors in tier 3, which are all sessions, proceed in managing ontologies submitted to them. Algorithm 3 explains the procedure.
Data: $o : an ontology reference; z = ((iz,⇤), Rz) : a session; O : a knowledge
base
Result: modified states of z, o and O if o /2 O then
load o;
O := O[ {o}; . push o into tier zero give z and exclusive write-lock on o;
end
foreach o0: d⇤(o, o0) do if o0 2 O then/
load o0; . store every dependency that is not present O := O[ {o0};
if d(o, o0) then
. direct dependencies must always be hijacked remove d(o, o0) from o;
if exists space c = (ic, Rc) that manages o0 then
Rc := Rc[ {$S}, where S is the scope that owns c;
else
. no such space : set a dependency using the ontology source add d(o, o0) (via so0) to o;
end end end
Rz:= Rz[ {$o};
Algorithm 3: Algorithm for setting an ontology to be managed by a session. The algorithm for managing ontologies in sessions is more complex than those for
managing ontologies in spaces, due to the di↵erent nature of these ontology collectors and the fact that they are designed to collect volatile ontological data, therefore their policies are more aggressive.
As with core and session spaces, if an ontology that is not part of the knowledge base is added to a session, the algorithm proceeds to store it, i.e. push it into tier zero. In addition, however, it gives the session an exclusive write-lock on the ontology, which means that the session will be the only object entitled to dispose the ontology once it has run its course. This lock is not given if the ontology was already in the knowledge base, because it is assumed that the ontology was stored by another procedure on the assumption that other ontology networks, real or virtual, could require it.
Afterwards, every dependency of the submitted ontology is stored into the knowl- edge base, as with tiers 1 and 2. However, a further check is performed here as well: if the dependency relation at hand is a direct dependency relation, hence the use of d(o, o0) instead of d⇤(o, o0), then the corresponding ontology is pushed into the lower tiers. The rationale is that, if a static ontology network is added to a session, then the other components of the network would not participate in the interpretation of the other network components added to the same session in the form of scopes. If these ontologies are moved to the lower tiers, it will be more likely that an interpretation pro- cedure will visit them before it visits the content of the session, which is more likely to be comprised of ABox axioms. Therefore, if the algorithm finds that the direct depen- dency is already being managed by a scope attached to the sessions, i.e. belonging to the same ontology network in tier 1 or 2, then the dependency is removed, as it will be inherited from the scope itself, which in turn inherits it from its space. Otherwise, the dependency is rewritten, so that the submitted ontology depends on the other ontology via its source (which is now pointing to the knowledge base, because the ontology was stored beforehand)1.
4.2.4.1 Example: multi-user content directories use case
We recall here the use case introduced in Section 1.1.2.1, where in a multi-user CMS, di↵erent users – three in this simple example – need to classify their research paper directories according to di↵erent criteria. Suppose there is an application plugged into
1Recall from Section 4.1.2, that a dependency between two ontologies can hold by referencing, in
4.2 Virtual ontology network assembly in OWL 2
the system, that is responsible for creating and synchronizing virtual directories. We now describe one possible way this application can exploit multiplexing techniques and lay out the ontologies required for obtaining the desired virtual networks. These ontologies are also shown in Figure 4.8. Once a virtual network is reasoned upon, subdirectories will be created for each user.
Let us take three CMS users A, B and C, each with their own private flat directory, and all sharing a common directory, also originally flat. For the metadata of all of these directories, there is an RDF representation computed by the system itself. We can assume Schema.org as the core vocabulary for representing these data, as it is a widespread standalone vocabulary.
Figure 4.8: Virtual ontology networks for multi-user content directories - Core vocabularies and standalone TBox ontologies such as FOAF, Dublin Core and the Event ontology lie within core spaces of tier 1. Persistent ABox and dependent TBox ontologies are placed in custom spaces (tier 2). Volatile ABox ontologies are placed in tier 3, one session per user.
• User A wants to classify the papers she has access to according to the events they were presented at, when conference or workshop papers. The representation of
scientific events is provided by a Linked Data set that is aligned with the DBLP biographical data [DBL] and represented using a particular event ontology [RA07]. Let us assume, however, that the application responsible for creating content directories queries against the Schema.org event representation [Sch]. Therefore, an ontology containing alignments between the Schema.org OWL representation and the Event ontology is placed inside a custom space. This ontology space will belong to a scope whose core space manages both the event ontology and Schema.org. This way, the three ontologies will appear connected in the resulting ontology network that is obtained from user A’s session (outer tier). This session, in turn, will be managing the metadata ontology of user A’s private directory, as well as the DBLP biographical data for it.
• User B wants to classify her private and shared papers by topic using two schemas, i.e. the Wikipedia categories (available from DBPedia [DBP]) and the Dewey classification system [Mit09]. To that end, the application can keep track of a topic scope, whose core space contains standalone core vocabularies, e.g. Schema.org, and whose custom space contains one of the other TBox ontologies that extend or align with the former, such as the DBPedia ontology or the Dewey linked data. To obtain the desired ontology network, this scope (or these scopes, if one is use for each classification system) is appended to a dedicated session containing User C’s private directory metadata in RDF, and so is the scope containing the RDF description of the shared directory.
• User C wants her papers to be classified according to the roles of their authors or reviewers in a social network she belongs to. Suppose for simplicity that there are RDF data available, which represent user C’s profile and social graph, either because the social network itself exports them as Linked Data, or because a third-party application provides an RDF export for them. These data are represented using common vocabularies such as FOAF, SIOC and Schema.org (cf. Section 2.5). Reviews published on the Web are retrieved by querying the Revyu dataset [HM08]. The resources containing the data in question are managed by a dedicated session for C. Vocabularies for describing social network data, such as FOAF and SIOC, are stored in the core space of a dedicated scope. Since C also
4.2 Virtual ontology network assembly in OWL 2
wants to be able to retrieve papers by Dewey classification, the scope containing the Dewey schema as Linked Data can be reused from user B.