Motivated by requirements of the VIKEF 1 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 [2], [14]. We claim that the distributed nature of the Semantic Web raises issues that can be attacked by contextualizing knowledge bases, i.e. restricting the scope of statements to the circumstances they were made under.
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 [4]. In continuation of the ideas and preliminary results presented in [14], we have been concentrating more on the aspects of compatibility relations (CRs) between contexts, which can be used to describe in which way statements in more than one context can be combined to answer queries to the KB. We have conducted a more extensive experiment to investigate performance aspects of RDFCore and our extensions, and backed by general theories of Contextual Reasoning we believe that we will in some cases be able to provide for better scalability than a flat, non-contextual KB.
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 1 Virtual 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). 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 A 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 [7], [12], [11], [6], [1], [5], [13], we believe it is a viable approach to attack issues of this nature by binding consistent sets of assertions to the circumstances they were made under, i.e. to limit their scope to a context, as we will describe in Sect. III.
As discussed in [8], [2], [3], this contextualization can serve as a basis for a number of KR modelling aspects, such as temporal evolution, trust, beliefs and provenance. The contributions of our approach compared to the proposals made in [8], [3], [10], [9] as well as compared to named graph implementations in current RDF triple stores are that i) we do not propose or require an extension of the current RDF standard and ii) we aim at substantial support for Compatibility Relations (CRs).
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 that are run on the same document, at different points in time. Assume P 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 C (created by P ) with a relation EXT EN DS that explicates that C 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 C , 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 C and C produces an inconsistent ABox which makes query-answering impossible. This can result from cardinality constraints in the TBox (see the Berlusconi-Prodi 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 C and C. One possible criticism could be that of course we could pose the query to C alone, without respecting C , 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 [14] is fairly general and can be used to implement relations of different kinds. In the course of the project we envision relations that make explicit temporal evolution, trust and a number of domain specific aspects.
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: 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 [14], using the multiuser environment of RDFCore to enable use of Context information by other applications.
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 Splittin-gReason 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 C 1 and C 2 , if we add to the CRO the statement S 1 = C 1 EXTENDS C 2 , this will trigger a consistency check over C 1 C 2 . If there is an inconsistency, the statements in C 2 that cause the inconsistency are moved to a Graph G 1 , and then a SplittingReason SR 1 will be created in the CRO, linked to C 2 and G 1 , with a reason of class Inconsistency which is linked to C 1 and a part of relation between C 2 and G 1 ; S 1 will be reified and attached to SR 1 , 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 Compatibili-tyRelation that RDFContextManager will use when managing the CRO and the knowledge base.
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:
the following statements are added to the CRO:
Matching objects for the describes predicate are necessary because this enables an application to say that C 1 extends different unrelated contexts, in the sense that C 1 adds information to both of them, even if the two extended contexts are incompatible; in fact, a View over C 1 , 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 C 1 that follows the EXT EN DS chain does not produce an inconsistent model; therefore, it takes the content of C 1 and of C 2 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 C 2 and removes them from C 2 ; the statements are then stored as a Graph G 1 . The split is tracked by creating a SplittingReason object, connected to C 2 , which is the source, and G 1 , 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 C 1 which is related as incompatible w.r.t G 1 . 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 C 2 and G 1 . Since the EXT EN DS relation is defined transitive, in case C 2 is already connected through a EXT EN DS relation to other contexts, then the check is performed not against C 2 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 C 1 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 ARQ 3 as SPARQL engine to interpret and answer it V. RESULTS
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 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.