Knowledge Modelling and Processing for the Social Semantic Web. (Ingénierie des connaissances pour le Web sémantique et social)

Data Structures. The KGRAM interpreter accesses the queried data bases through an abstract API that hides the graph's structure and implementation: it operates on a graph abstraction by means of abstract structures and functions and it ignores the internal structure of the nodes and edges it manipulates to evaluate a query expression over a target graph. More precisely, the target graph is accessed by node and edge iterators that implement the Node and Edge interfaces of KGRAM. These are the very same interfaces that operationalize the node and edge expressions of KGRAM's query language. GRAPH-BASED KRR ON THE SEMANTIC WEB 69 As a result, KGRAM can process any kind of knowledge graph, among which conceptual graphs (with n-ary relations) as well as RDF graphs (with binary relations). It remains independent of any graph implementation and any data structure. Abstract Operators. KGRAM accesses the target graph through an abstract graph manager which implements its Producer interface. This graph manager enumerates the graph nodes and edges (implementing the Node and Edge APIs) that match the nodes and edges occurring in a given expression (and implementing the same APIs). It uses the KGRAM APIs of a node and edge matcher described bellow and thus ignores the way nodes or edges are matched. A node and edge matcher implements the KGRAM Matcher interface. It is responsible for comparing node and edge labels. It implements the match semantic rule base occurring in the rules of natural semantics specifying the expressions node and edge of the query language. Depending on the Matcher implementation, the label comparison consists in testing string label equality or it may take into account class and property subsumption, or compute approximate matching based on semantic similarities, etc. Constraints are abstract entities that implement the Filter interface which specify the filter expression of the query language. Filters are evaluated by an object that implements the Evaluator interface. KGRAM ignores the internal structure of lters, it calls the eval function of Evaluator on Filter objects and passes the Environment as argument. This eval function implements the eval rule base occurring in the rules of Natural Semantics 3.2 of filter. Figure 3.4 presents the resulting architecture of KGRAM query engine.Operators. KGRAM accesses the target graph through an abstract graph manager which implements its Producer interface. This graph manager enumerates the graph nodes and edges (implementing the Node and Edge APIs) that match the nodes and edges occurring in a given expression (and implementing the same APIs). It uses the KGRAM APIs of a node and edge matcher described bellow and thus ignores the way nodes or edges are matched. A node and edge matcher implements the KGRAM Matcher interface. It is responsible for comparing node and edge labels. It implements the match semantic rule base occurring in the rules of natural semantics specifying the expressions node and edge of the query language. Depending on the Matcher implementation, the label comparison consists in testing string label equality or it may take into account class and property subsumption, or compute approximate matching based on semantic similarities, etc. Constraints are abstract entities that implement the Filter interface which specify the filter expression of the query language. Filters are evaluated by an object that implements the Evaluator interface. KGRAM ignores the internal structure of lters, it calls the eval function of Evaluator on Filter objects and passes the Environment as argument. This eval function implements the eval rule base occurring in the rules of Natural Semantics 3.2 of filter. Figure 3.4 presents the resulting architecture of KGRAM query engine. Figure 3.4: KGRAM core query engine Interoperability. KGRAM comes with a default implementation of its APIs, for querying RDF with SPARQL 1.1 with RDFS entailment. It is developed and maintained by Olivier Corby. We showed that our goals of abstraction and interoperability with other graph-based reasoning framework were achieved http://wimmics.inria. fr 70 GRAPH-BASED KRR ON THE SEMANTIC WEB through the development of two additional implementations of KGRAM APIs with both Corese and Jena [69]. The connection to Corese was almost immediate because KGRAM was designed as an abstraction of the principles of Corese. In this port, KGRAM handles its whole query language, and queries RDF graphs implemented as conceptual graphs. We have also ported KGRAM (except property path) on Jena (we co-supervised the Master trainee of Corentin Follenfant on this subject). This required less than 1000 lines of code. 3.2. 3 Querying Heterogeneous and Distributed RDF Data with KGRAM Nowadays, a growing number of applications expect to manipulate the Linked Data seamlessly available over the Web. Conversely, Linked Data opens new opportunities to enrich existing applications by exploiting enlarged, joined data and knowledge repositories. This momentum creates the need for new tools able to query, join, and manipulate the heterogeneous and distributed data sources composing the Web of Linked Data. The GRIWES model and KGRAM's design principles have broaden the perspective to answer these needs. This section shows how KGRAM supports (i) query-based federation of multiple data sources; (ii) mediation of a wide range of heterogeneous data models encountered on the Web; (iii) access to distributed data sources. These are the results of a collaborative work with Olivier Corby, Johan Montagnat and Alban Gaignard published in [39], [60] and [59]. Olivier Corby and I participated to the supervision of the PhD thesis of Alban Gaignard [58] directed by Johan Montagnat. Federation of Multiple Data Sources KGRAM query evaluation algorithm makes it easy to query multiple data sources through multiple data producers. A meta-producer, interfaced to the query engine of KGRAM on the one side and to multiple data producers on the other side, just forwards the graph node and edge queries of KGRAM core query engine to all attached producers before merging all resulting bindings received into a single environment returned to the query engine. Integration of Heterogenous Data The implementation of KGRAM's Producer interface by a metaproducer is also the key to integrate data with heterogeneous knowledge models. It only requires that an implementation of the Producer interface is implemented for each knowledge model, with also di erent implementations of the Node and Edge interface, and that a metaproducer iterates over all of them. In that case, the matcher of the query engine which is called by the interpreter for each candidate node or edge returned by the metaproducer is here to harmonize the semantics of the preliminary matchings of the producers. http://jena.sourceforge. net/ GRAPH-BASED KRR ON THE SEMANTIC WEB 71