- In this paper we are presenting the context architecture implemented on top of the RDFCore system. With this extended Knowledge Representation framework we are trying to overcome some of the limitations of RDF and OWL as they are today, without losing sight of performance and scalability issues. We are illustrating motivations - partly based on requirements in the VIKEF project - as well as theoretical background, implementation details and test-results of our latest works.
Motivated by requirements of the VIKEF1 project, where a large-scale Semantic Web knowledge-base about documents and other objects provides for intelligent services to the user, we are investigating and developing a more extended KR framework, trying to overcome some of the limitations of RDF and OWL as they are today.
Our basic idea is to introduce the notion of context into
Semantic Web Knowledge Representation (KR), as previously
described in [
The contribution of this paper is to present one possible
realization of this more complex KR approach for the
Semantic Web, and to illustrate our progress based on the KBMS
RDFCore [
The paper is organized as follows: In Sect. II we present intuitive and technical motivations for our approach, as well as related work. Sect. III describes our general proposal, whereas Sect. IV contains a technical description of the steps taken to realize our ideas. In Sect. V we present our experimentation 1Virtual Information and Knowledge Environment Framework; more information at http://www.vikef.net results, and we wrap up with a conclusion and a short mention of planned further works in Sect. VI.
One of our initial motivations to move in the direction of contexts in Semantic Web KBs was our critical view on one of the ideas of the Semantic Web, namely that – with a shared ontology – two RDF Aboxes provided by different agents can simply be merged, collapsed on identical URIs, and thus provide a new, bigger KB for answering a query (the pre-merge scenario is depicted in Fig. 1).
Fig. 1. Two RDF Aboxes A and A’ compliant to a single TBox T.
However, apart from implicit semantics that are omitted
when applying such a strategy, cases can be constructed that
unveil problems even on the logical level. Take the following
example, as depicted in Fig. 2: on the formalization side we
have a TBox T with some relations that have cardinality
constraints, and two ABoxes A and A0 with assertions compliant
to this TBox. Both ABoxes are consistent by themselves,
but when merged, they produce an inconsistency as the two
following statements violate the cardinality constraints in T :
< prodi prime minister italian government >
< berlusconi prime minister italian government >
Relying on a host of research done in the area of Context in
KR [
As discussed in [
These relations between contexts enable us to make explicit in which way the assertions in the related contexts are supposed to be combined for query answering, to provide for flexible and powerful contextual reasoning as envisioned in the mentioned bibliography.
In the course of the VIKEF project it became evident that some of the relations we have in mind have procedural semantics, and can thus not be formalized in an OWL ontology, and these are what we are concentrating on at the moment. In the next section we will describe our examplary proposal of such a complex relation.
The EXTENDS relation we have chosen to illustrate is meant to describe a situation where we know that two contexts describe the same object, but assume that one context contains more information about it than the other.
Take the example of two Information Extraction processes P and P 0 that are run on the same document, at different points in time. Assume P 0 is a more advanced process and is able to extract more information from the document. We propose to model this as two contexts C (created by P ) and C0 (created by P 0) with a relation EXT EN DS that explicates that C0 is an extension to C (a necessary condition for this relation is that both contexts describe the same object). Intuitively we want to keep the information derived from different sources separate and with explicit metadata, but have the possibility to combine the resulting information where necessary.
When a query q is posed on C0, the procedural semantics of EXT EN DS are envisioned as follows: if q can be answered in C’
then return answer else propagate query to
C’ union C.
One issue that becomes obvious immediately is the case where the union of C0 and C produces an inconsistent ABox which makes query-answering impossible. This can result from cardinality constraints in the TBox (see the BerlusconiProdi example in Sect. II), or subsumption issues (an individual o is said to be instance of different classes). Our basic solution approach is to extract a minimal subgraph containing the statement(s) that caused the inconsistency into a named graph NG, as illustrated in Fig. 3.
The result is that the query can be processed on the conflictfree part of the union of C0 and C. One possible criticism could be that of course we could pose the query to C alone, without respecting C0, and thus avoid the conflict altogether. This however ignores the EXT EN DS relation between the two (which has been established for a reason), and thus should only be allowed on contexts that are not in such a relation.
The case is of course slightly more complex when we take into account more than two contexts. We envision the EXT EN DS relation to be transitive. This can result in a reasoning chain i) when establishing the relation, as conflicts have to be detected and re-modelled and ii) when querying the contexts, as the necessary contexts and relevant subgraphs have to be traversed. This chain however is non-cyclic, as the relation is directional. Section IV describes our first implementation of this relation.
We have chosen to attack and illustrate this specific relation
due to its relative complexity. However, we are convinced that
our basic approach as described in [
The component we developed to manage contexts is called RDFContextManager; its architecture is presented in Fig. 4. RDFContextManager is implemented as a Java interface, exposing methods to: • set the Compatibility Relation Ontology (CRO), which is the ontology that defines Compatibility Relations, Contexts, parts of Contexts (Graphs) and also gives the concepts necessary to represent context splitting and relations between Contexts and Graphs • add new statements to the CRO, stating for example that a given URI C1 represents a Context, that this Context extends an existing context C2, or that there is a Graph G1 which is part of C2 and is compatible or not with C1 • add, remove or update Contexts and Graphs in the underlying persistence layer • obtain Views over a Context, e.g. ask RDFContextManager to return all Contexts and Graphs that are connected to a Context C1 with EXTENDS relations, directly or by means of part of relations, following all the relation chains and obeying imposed limitations
A CompatibilityRelation is a Java interface exposing methods to: • verify whether an implementation of CompatibilityRelation should be triggered into action by some statements added to the CRO, e.g. the insertion of a statement C1 EXTENDS C2 should trigger the consistency check over C1 t C2, and, if an inconsistency is detected, countermeasures should be undertaken, in order to guarantee that a View over C1 do not answer an inconsistent set of statements • carry out the check specific for this CompatibilityRelation • ask this implementation to provide a set of Contexts or Graphs that would be excluded from a View over a Context C1 due to some reason, e.g. incompatibility due to inconsistency • ask the implementation to provide a set of Contexts or Graphs that would be included in a View over a Context C1, e.g. because of an EXTENDS or a part of relation or chain of relations
The implementation we are presenting in this paper relies on
RDFCore for RDF models storage, and on Pellet2 for
reasoning tasks such as consistency check over a View. As illustrated
in Fig. 4, the DL reasoner is used by the CompatibilityRelation
implementations (note that different implementations could
need different reasoning settings, e.g. only RDFS or OWL Lite
inference rather than OWL DL inference), while all the storage
and retrieval of RDF models is done on RDFContextManager,
which uses RDFCore and its facilities for model storage and
query[
The CRO contains the definition of the main concepts used to describe the KB structure in terms of contexts; it contains the definition of Context and the definition of Graph, where both concepts represent entities that are named graphs; a Context has the (informal) property of representing something that has a meaning as a whole, e.g. the set of statements extracted from a specific document, at a specific time, with a specific algorithm, while a Graph is a set of statements that is included in one or more Contexts or other Graphs, but has no specific meaning alone (e.g. the set of statements in a Context that cause inconsistencies with another Context). A domainrange view of the CRO is given in Fig. 5.
Moreover, the CRO contains the definition of the SplittingReason class, which represents the reason that led to the isolation of a part of a Context and the storage of that fragment as a Graph; a SplittingReason instance includes references to the Context from where the statements that are being split belonged, the Graph that will hold these statements, the reason for which this split has been done, e.g. because the statements create inconsistencies w.r.t. another context (which is also linked to the reason), and the reification of the statements in the CRO that triggered the split, if any.
An example of SplittingReason generation is the one we will illustrate in detail in Sect. IV-C.1: let us have Contexts C1 and C2, if we add to the CRO the statement S1 = C1 EXTENDS C2, this will trigger a consistency check over C1 t C2. If there is an inconsistency, the statements in C2 that cause the inconsistency are moved to a Graph G1, and then a SplittingReason SR1 will be created in the CRO, linked to C2 and G1, with a reason of class Inconsistency which is linked to C1 and a part of relation between C2 and G1; S1 will be reified and attached to SR1, so that the complete splitting process can be tracked.
The CRO also acts as a registry for CompatibilityRelation implementations, since each declaration of a CompatibilityRelation amounts to the declaration of a property in this ontology; an AnnotationProperty for this property, called implementation uri, gives the java class name of the corresponding implementation; this is used to retrieve the set of CompatibilityRelation that RDFContextManager will use when managing the CRO and the knowledge base.
2www.mindswap.org/2003/pellet/
The simplest use case for the framework is as follows: • An external application adds one or more different Contexts in RDFContextManager, assigning them URIs or letting RDFContextManager choose one • The external application asserts some relations between the contexts or specific to a context; the relations between the contexts are expressed through properties defined in the CRO • RDFContextManager receives these new assertions, and triggers all the CR implementations available into first verifying if any of the new assertions is relevant (i.e. the asserted relation corresponds to the URI the implementation is attached to) and then checking whether the new relation is likely to cause reorganization of the knowledge base; if this is the case, corrective actions are undertaken • The external application makes a query over the CRO to find out all the contexts that satisfy some conditions (e.g. all the contexts which have been created in a specific date), and then asks to perform a query over the set of statements resulting from the union of the contexts; this involves creation of a View for each context that is selected by the query 1) EXTENDS Example: We will now use EXTENDS as a practical example of the described use case: • Two contexts C1 and C2 are inserted in RDFContextManager • C1 is asserted to extend C2 w.r.t a specific subject S1: the following statements are added to the CRO: < C1 EXT EN DS C2 > < C1 describes S1 > < C2 describes S1 > Matching objects for the describes predicate are necessary because this enables an application to say that C1 extends different unrelated contexts, in the sense that C1 adds information to both of them, even if the two extended contexts are incompatible; in fact, a View over C1, which is forced to be consistent, will include only one of the extended contexts • The implementation of EXT EN DS will be triggered to check matching with the three statements, and it will fire the check for knowledge base reorganization • The check performed by EXT EN DS consists of verifying that any View over C1 that follows the EXT EN DS chain does not produce an inconsistent model; therefore, it takes the content of C1 and of C2 and runs a DL reasoner (Pellet in this case) over the union. If any inconsistency is detected, EXT EN DS tries to isolate the responsible statements, selects those that appear in C2 and removes them from C2; the statements are then stored as a Graph G1. The split is tracked by creating a SplittingReason object, connected to C2, which is the source, and G1, which is the result; it is also connected to a reason, which in this case is instance of the Inconsistency class, and in turn to C1 which is related as incompatible w.r.t G1. The statements added to the CRO are reified and attached to the SplittingReason as triggers, in order for the split to be traceable, and finally a part of relation is asserted between C2 and G1. Since the EXT EN DS relation is defined transitive, in case C2 is already connected through a EXT EN DS relation to other contexts, then the check is performed not against C2 alone but over the resulting View; the generated splits in the KB can then be distributed along the EXT EN DS chain, which is one of the scalability issues we analyze in Sect. V • When a View over C1 is requested, all the CR implementations are requested to provide a set of Contexts or Graphs that must not appear in the final view (EXCLUDE set), i.e. are requested to forbid to follow some paths in the CRO assertions; this is because, when multiple CR are present, some of them may forbid the presence of a result that others would allow to appear in the results; simply removing all the forbidden results after all the paths are followed is not correct nor efficient, since this would require complex pruning strategies. After the EXCLUDE set has been computed, all the CR implementations are required to provide the set of Contexts or Graphs that should appear in the resulting View (INCLUDE set), and they will prune their visiting graph as soon as a forbidden result is reached. The final View is then computed as the INCLUDE set plus the resources connected through part of to these elements (not including those in the EXCLUDE set) • The View can now be viewed as a single model, or the set of URI for the contexts and graphs can be used as dataset for a SPARQL query to be issued to RDFCore, which in turn uses ARQ3 as SPARQL engine to interpret and answer it
In this section we presents the empirical evaluation we have conducted so far. In order to check the system for scalability, we needed to design a big knowledge base with non trivial contents, and at the same time divided in smaller chunks without changing the semantics of the content. This, however, seems a very difficult task, and so far we have not found real world ontologies that satisfy these requirements, so we used a homemade tool to generate individuals for a generic ontology; repeating the process many times gave us two well sized knowledge bases.
Using the SOFSEM ontology 4, an ontology to describe the SOFSEM conference, we generated two knowledge bases, one composed of 30 models containing about 70000 statements each (for a total of more than 2 millions triples), and the other containing 900 models of about 2000 triples each (1.8 millions triples); on the first one, we tried to chain the models with EXT EN DS relations involving two models at a time, while in the second one we chained tirthy models at a time, obtaining many chains, and then joined the chains. The results are presented in Table I, where the results for the first experiment are presented, in Table II for the second experiment. The second experiment is also depicted in Fig. 6.
As is depicted in the graph, the time elapsed to create a view over the graphs is almost constant, even if the number of relations to navigate increases, while the time elapsed to check the consistency of the models grows proportionally to their size. It is important to note that the consistency check runs only when new relations are enterend in the CRO; the most frequent operation, then, will be the request to create a View starting from some specified models, and the experimental evaluation shows that this operation is usually performed in less than half a second on the test machine (a laptop with 3http://jena.sourceforge.net 4http://nb.vse.cz/˜svabo/oaei2006/data/Conference. owl
TABLE I
RESULTS FOR 70000 TRIPLES MODELS 512 MB of RAM, which is not an adequate server setup). The time required to complete the consistency check and automatic splitting on models of greater size is around one minute, which is acceptable from our point of view if we consider that this operation has to be done only once, and occasionally as new relations are added.
The most relevant point, here, is that requesting a View operation will return a set of graph identifiers that can be used as dataset for a SPARQL query, ensuring that the model resulting from the union of the queried data is consistent, without having to check at the time of querying; this also means that the memory requirements (at query time) of the framework only depend on the number of relations between Contexts and Graphs, and not on the size of the contained data, or on their complexity. The memory needed by the SPARQL engine to run the query itself, instead, depends heavily on the specific query; still no complete evaluation of the behavior of the system w.r.t. the possible kind of queries has been performed.
Basing on the opinion that contexts in Semantic Web KR are a way to tackle some of the current limitations of the languages available and provide for better scalability in some cases, we have presented a theoretical approach and an implementation of Contextual Reasoning in a Semantic Web KB and the associated testing results. We have not only implemented a context mechanism into our KBMS to be able to use a context as a first-class object in assertions, but also illustrated a way to provide for context relations with procedural semantics which – in our opinion – is required for a complete context functionality.
Our next steps will be directed towards the formal definition and implementation of more compatibility relations. Some of them will be as required by the VIKEF project, but we are also interested in exploring more general and domain independent relations between contexts and their properties.
On the implementational side, these planned steps will be accompanied by the development of a more standardized test set and a set of exemplary queries that specifically display and make use of contexts, to assess the practicability, performance and scalability of our implementations.
This research was partially funded by the European Commission under the 6th Framework Programme IST Integrated RESULTS FOR SMALL SIZED MODELS AND LONG CHAINS Project VIKEF - Virtual Information and Knowledge Environment Framework (Contract no. 507173, Priority 2.3.1.7 Semantic-based Knowledge Systems; more information at http://www.vikef.net).