At the center of the Maana Q Knowledge Platform is the Computational Knowledge Graph, which consists of a cloud distributed set of GraphQL and RESTful microservices. Each service exposes a set of types and functions. The functions can be evaluated lazily (i.e., streaming) or strict/eager (i.e., batch) and can be marked as having pure (i.e., referential integrity) vs effectful (i.e., causes change or relies on changing externals) semantics.
The purpose of this system is to represent domain knowledge (i.e., concepts, properties, relations, individuals) and perform reasoning (i.e., operations performed on the domain to achieve various goals). This is similar in nature to the goals of the Semantic Web, which aims to unify:
- Linking data
- Organizing data into "ontologies"
- Querying data
- Logical inference (e.g., deduction, induction)
While the goals are similar, the underlying technologies are unfortunately not. Ideally, we'd like for these two systems/approaches to interoperate. Maana Q takes the general approach of "wrap-and-map" services, i.e., build a GraphQL endpoint that represents the system/database/library to interoperate with (this is the "wrap" part) and conform the domain model to the common/best-practice models (e.g., common definition of person, place, thing, event, date/time, ...) (this is the "map" part).
One popular, open-source solution for managing large-scale "semantic web" data, queries, and inferences via Java APIs is the Apache Jena system. It also comes with a web-based management and query interface, Fuseki.
Our task is to create a Maana Q-ready Jena service that:
- define ontologies via RDF and OWL
- load datasets via TDB
- issue queries using SPARQL
- perform inference
... all from within the Q ecosystem of services and function composition.
We'll follow the steps of Hoiw to Load Yago into Apache Jena Fuseki to configure, load, and test a Jena installation.
Our Q service, maana-apache-jena, will expose the set of types (Kinds) and functions used to interact with the Jena platform. The Maana methodology suggests that we design our service as a Maana Q workspace.
Our Q workspace defines the types and functions, along with various function decompositions, that are provided by the microservice. At the leaf nodes of the function graph are points where actual code/computation is needed to fulfill the contract. Here, we will use a Scala-based service template to define the necessary schema and provide the implementations (i.e., resolvers).