In recent years knowledge graphs gained much attention. Many big companies, like Amazon, Facebook, or Google, are building a knowledge graph. This movement also a ected smaller companies, as a growing number of those ask for knowledge graph solutions or start to build them themselves. The Semantic Web provides a long list of knowledge representation formalisms and ontology languages to build knowledge graphs. Those formalisms and languages cover a broad range of computational complexity, from simple to even undecidable. Focusing on the manifoldness of companies building knowledge graphs, a language that many people understand and accept is intended. Therefore, we present an alternative approach to existing knowledge representation formalisms and ontology languages based on JSON. JSON is the most popular format for exchanging information between systems. Also, JSON comes with its schema language called JSON Schema, allowing to de ne the structure of a given JSON document. Our paper provides an ontology language based on JSON Schema and extends it by inheritance, arbitrary relationships between di erent JSON documents (classes), and rules. The rules are based on OO-logic, a successor of F-logic, and are seamlessly embedded. As we see in our current projects, this language is quickly adopted and used by software developers.
dicts that \Data and analytics will become the centerpiece of enterprise strategy,
focus and investment" [
[
In order to provide an alternative to existing ontology languages, we
provide an ontology language based on JSON-Schema that extends JSON-Schema
with complex constraints, inheritance, relationships, and rules. JSON Schema
provides constraints for single property values only. In this paper, inheritance
is introduced, as it is not provided by JSON Schema so far. Inheritance is
divided into a top-down and a bottom-up part. Top-down speci es that subtypes
inherit all properties from the supertype, and bottom-up de nes that instances
of subtypes are also instances of supertypes. JSON Schema can not yet handle
relationships between di erent JSON documents (classes). However, for
modeling ontologies, this is an essential requirement. Finally, to be able to reason over
the given data, rules must be provided. Therefore, JSON Schema is extended
to be usable with OO-Logic [
To begin with, we present preliminaries relevant to understand the concepts introduced within this paper. The preliminaries include a brief introduction to 1 www.gartner.com 2 https://www.cs.tufts.edu/comp/150IDS/final_papers/tstras01.1/
FinalReport/FinalReport.html#software 3 http://json-schema.org 4 https://json-schema.org/speci cation.html JSON, JSON-LD, and JSON Schema. In Section 3, extensions for JSON Schema towards a simple ontology language are introduced. Then, rules that make use of the JSON data are described. Afterward, we present a use case using the extensions of JSON Schema and the rules. The last but one section (Section 6) mainly introduces SHACL, which is comparable to JSON Schema and brie y also other rule languages present in the Semantic Web. Finally, we conclude our paper and give an outlook on future work. 2
The proposal of this paper is based on an adaptation of JSON Schema, a schema language for JSON. In order to follow the extensions made, we will present the basic terms used within this paper. Therefore, we brie y introduce JSON and JSON-LD, and afterward, relevant concepts of JSON Schema are introduced. 2.1
JavaScript Object Notation (JSON) [
JSON-LD [
JSON Schema [
{ } "title":"Person", "@id":"http://example.org/Person", "@type":"Class", "properties":{ "name":{
"type":"string" }, "age":{
"type":"integer" } }, "required":["name", "age"] Listing 1: A JSON Schema de ning the structure of instances of type person
This schema de nes two required properties, namely name and age. Values given for property name must be strings and integers for property age. Since those properties are marked as required, a given instance must provide those properties to be valid. The keyword additionalProperties is not used in this schema. Hence, an instance validated against the given schema can also have more than the de ned properties and is still valid. When setting additionalProperties to false, only the two de ned properties are allowed.
JSON Schema supports linking di erent schemas to reuse parts of a schema used in many places. A reference to another schema is introduced using the $ref keyword. The value of this keyword is an identi er of the other schema that should be included in the speci ed place. When the schema is validated, 6 we rely on the draft 2020-12 json-schema-core.html
http://json-schema.org/draft/2020-12/ the reference is replaced by the referenced schema. Before evaluating, the content of the other schema is embedded into the source schema and then applied to the given instances. Listing 2 presents a schema including a reference to a schema representing the structure of a DegreeCourse (Listing 3).
{ "title":"Student", "@id":"http://example.org/Student", "type":"object", "properties":{ "matriculation_number":{
"type":"integer" }, "degree_course":{
"$ref":"definitions.json#/degreeCourse" } Listing 2: Student schema referencing the DegreeCourse schema { "title":"DegreeCourse", "@id":"http://example.org/DegreeCourse", "type":"object", "properties":{ "name":{
"type":"string" }, "course_number":{
"type":"integer" } }, "required":["name"] }
Listing 3: Schema representing the structure of DegreeCourses
For the evaluation the DegreeCourse schema is embedded into the root schema (see Listing 4).
Given instances must have the DegreeCourse embedded as well. Only a link to a DegreeCourse instance would be marked as invalid according to the given schema.
JSON Schema usually is used for validating JSON data which have to be structured according to the schema. In our case, we use JSON schema for describing classes and properties of classes of an ontology. So, in this case, JSON schema is not used as a constraint language. On the other hand, using JSON schema for describing ontologies has a nice side e ect, that it can be used in other applications for validation purposes. Using JSON Schema as ontology language requires inheritance as an extension and adapting the semantics of relationships. In this section, we rst introduce inheritance for JSON Schema and then the adapted semantics of relationships. In the following, we refer to a JSON Schema describing the structure of a JSON object as class. 3.1
For referring to a superclass relevant for the inheritance, a new keyword is introduced. In the current JSON Schema draft, keywords have the $ as the pre x. Our keywords are based on the syntax of JSON-LD with @ as the pre x. The keyword for representing the relationship between a class and its superclass is @subClassOf. A class with a @subClassOf property will inherit all the properties and de nitions from its superclass. The following example (Listing 5) shows a subclass of Person describing the structure of a Student. It de nes the superclass Person via the @subClassOf keyword and therefore inherits all the properties from the superclass. In addition to the inherited properties the Student { } "title":"Student", "@id":"http://example.org/Student", "@type":"Class", "@subClassOf":"http://example.org/Person", "properties":{ "matriculation_number":{
"type":"integer" }, "degree_course":{
"type":"string" } }, "required":["matriculation_number"]
Listing 5: Subschema class adds another required property named matriculation number. A JSON object of type Student must ful ll the requirements from Person and Student class to be valid. 3.2
JSON Schema provides a reference mechanism that looks like a relationship de nition at rst glance. However, the original reference mechanism expects the referenced object to be embedded in the JSON instance. This is infeasible when modeling knowledge graphs. Hence a more exible approach is needed to describe references between classes. These relationships will be de ned in the type de nition property. Instead of giving a primitive data type (like integer or boolean), the reference to another class will be given using the @id property. During the veri cation, the referenced class will not be embedded into the root class. However, the referenced object will be validated against the de ned class by considering the hierarchy. The following example (Listing 6) will illustrate a relationship de nition.
In that way, it is possible to refer to an object of a subclass of DegreeCourse. 3.3
The semantics of the presented extensions is described by mapping JSON to Horn-Logic. Mapping means translating the incoming JSON to three types of predicates. First, the member/2 predicate, describing the type of the given triple. Second, the subclass/2 predicate and third, the value/3 predicate. For this mapping the two keywords @id and @type are used. The value of the property @id is always the unique identi er of each triple, and the according class of the object is given using the @type property. Listing 7 shows the predicates resulting from the mapping of the schema of class Person (see Listing 1). In this example, we skipped the quotes of the predicate values for better readability. { "title":"Student", "@id":"http://example.org/Student", "@type":"Class", "properties":{ "matriculation_number":{
"type":"integer" }, "degree_course":{
"type":"http://example.org/DegreeCourse"
}
tion with simple ontology means. As soon as we describe more complex
relationships between data, we have to add additional means. We already mapped
JSON objects as well as our extended JSON schema to a logic-based
representation. So it is pretty obvious to add a rule-based language for expressing complex
relationships. Rules are not meant here to be used for constraints but for
deducing additional facts. In [
OO-logic allows describing the essential parts of an ontology, i.e., classes, properties of classes with their ranges, hierarchies of classes, and relationship types between classes. In addition, instances of classes together with their property names and their relationships can be described in OO-logic easily (see Listing 9).
// every student is a person Student :: Person. // additional properties for students Student[properties:/matriculation_number,degree_course/]. // DegreeCourse is also a class degree_course[range:DegreeCourse]. // Sabine is a student sabine : Student. // Sabine has the matriculation number 5 sabine[matriculation_number:5]. // physicsA is the uid for the degree course sabine[degree_course:physicsA].
Listing 9: Ontology with instances in OO-logic
Rules derive new facts from existing ones. We can now express that if a student is studying the course, then all course members can be derived. Afterward, a query to ask for all courses of Sabine can be executed (see Listing 10). 4.2
OO-logic rules allow seamless access to all properties of our JSON objects. They use the same structure as the JSON objects. That a JSON object is element of a certain class (type) is expressed by colon ":", that a JSON object is a subclass CourseMembers: ?C[member:?S] :- ?S:Student, ?S[degree_course:?C]: ?- ?C[member:sabine].
Listing 10: Query courses of sabine of another class is expressed by two colons "::", and properties are declared by expressions in brackets ([..]). Sub-objects are addressed like related objects. A question mark precedes variables.
OO-logic provides a vast amount of so-called built-ins. All Java methods from the Math- and String libraries are available. Values can be compared; complex mathematical and boolean formulas can be expressed in rule bodies. Rule heads allow to derive new values for JSON objects' properties, create new JSON objects with their properties and relations to other JSON objects, and classify JSON objects.
// what are the sub-classes of class Person ?Subclass :: Person // which members has class person, including the members of the sub-classes ?Person : Person // the matriculation numbers of all students ?Person:Student, ?Person[matriculation_number:?MatriculationNumber] Listing 11: Examples for conditions usable in rule bodies to access JSON objects
An example for creating new values for JSON objects and classifying them using built-ins to access the current time and to compute the age is given in Listing 12.
?P:YoungPerson, ?P[age:?Age] :?P:Person, ?Person[birthDate: ?Born], _now(?Now), ?Age := ?Now-?Born, ?Age < 25. // compute age of a person by subtracting the birth date from the current time // classify person as young person if the age is less than 25 Listing 12: Rule accessing JSON objects, classifying them and creating new property values
Together with the extensions of JSON Schema, those rules are implemented
in a deductive database called SemReasoner (Semantic Reasoner). SemReasoner
is the successor of OntoBroker [
5
At adesso10 we support the e ort of our customers towards better digitalization processes in our projects. Input management is still an area where much manual work takes place. Our current use case for applying our technology is a KYC (know your customer) process in the banking eld. If a corporate customer requests a new bank account, regulations enforce the bank to gather information about the customer to estimate the risks. Therefore, the bank will request information about the customer from risk assessment organizations like Schufa11 or Credit Reform12 in Germany, and the bank will analyze information delivered by the customer himself. One piece of information is the balance sheet of the company. Still, such information is often not delivered in structured form but as texts either by a PDF or even in paper form. Often, those documents are read, interpreted, and analyzed by humans, which is much e ort. adesso has developed a system for analyzing balance sheets for those purposes. Classes describe di erent types of balance sheets with di erent properties. For instance, individuals and small businesses have more straightforward balance sheets while larger businesses have more complex balance sheets. Properties describe the assets and the nancing. An example for a JSON schema describing an IFRS balance is given in Listing 13.
Di erent types of rules are used for di erent purposes. The terminology in
such balance sheets is not standardized. In addition, it often contains typos,
especially if OCR has created the balance document (if it has been received
7 For a more detailed description of OO-Logic and the reasoning, we refer to [
"type":"float" }, "current assets":{
"type":"float" }, "shareholders equity":{
"type":"float" }, "non-current liabilities":{
"type":"float" }, "current liabilities":{
"type":"float" }, "company":{
"type":"Company" }
}
Listing 13: A JSON Schema de ning the structure of an IFRS balance // cell C1 contains the sum of the equity in the document // cell C1 is in the same row as the word "total shareholders equity" // the words are compared with similarity measure Levenshtein ?BS["shareholders equity": ?Sum] :?BS: Balance, ?T:Table,?T[cells:{?C2}], _levenshtein(?C2.value,"total shareholders ,! equity",0.8), ?T[cells:{?C1}],?C1.row=?C2.row, ?C1.column=1. // if the computed sum of all equity values is different from // the sum written in the document a warning is given plausibilityTableBalance("sum for shareholders equity is wrong") :?BS:Balance, sumEquity(?BS,?S), ?BS["shareholders equity":?E], ?E != ?S.
Listing 14: Rule to check for a plausibility as a picture or a sheet of paper). Rules together with string similarity builtins like Levenshtein are used to map the terms to our properties. Those rules also take the geometry, e.g., the table structure of the document, into account. Another type of rule is used for plausibility checks. For instance, a rule sums up the di erent positions for equities and compares it to the sum mentioned in the document. An example for a rule performing a plausibility check is given in Listing 14. Finally, the last type of rules do the analysis itself, i.e., determine whether the customer is in good nancial shape or the risk with this customer is high.
At adesso this technology is also used in other applications, e.g., in a chatbot
platform [
When considering the web developer community, most developers are more familiar with JSON and JSON Schema compared to standards provided by the W3C (e.g., RDF, RDFS, SHACL). However, a similar approach to JSON Schema is SHACL.
A standard of the W3C consortium for de ning the structure of entities in a knowledge graph based on RDF is the SHApes Constraint Language (SHACL)13. Similar to JSON Schema, the SHACL de nitions can be used to generate user interfaces.
For de ning constraints over a knowledge graph, SHACL di erentiates two types of shapes, Node shapes and Property shapes. A node shape de nes constraints for instances, and property shapes de ne constraints for the properties of those instances. Node shapes together with property shapes are used to de ne the structure of instances of a speci c type. Listing 15 shows the SHACL shape for the class Person (see Listing 1). ex:Person a sh:NodeShape ; sh:targetClass ex:Person ; sh:property [ sh:path ex:name ; sh:datatype xsd:string ; ] ; sh:property [ sh:path ex:age ; sh:datatype xsd:integer ; ] .
Listing 15: Node shape for the Person schema
Besides de ning the structure of instances, SHACL allows the usage of inference rules for inferring new facts. The SHACL documentation presents SPARQL and Triple rules. Based on the implementation of the underlying reasoning engine, other rule types can be supported. For example, SHACL JavaScript Extensions14 de nes another rule type called JavaScript rules. 13 https://www.w3.org/TR/shacl/ 14 https://www.w3.org/TR/shacl-js/
Web Community based on Horn rules without function symbols. The semantics of RIF is standard rst-order semantics. Datalog extensions in RIF are used to support F-Logic features as objects and frames. RIF is not intended as a rule language for modeling but is intended as a common format for exchanging rules.
XML supporting integrity, derivation, production and reaction rules.
Lite with a subset of the Rule Markup Language. The expressivity of SWRL is equal to OWL DL, which comes at a price of decidability. Also, this makes practical implementations harder. SWRL rules consist of a body and a head. Whenever the conditions in the body are ful lled, the condition in the head must hold as well.
OO-logic supports full Horn logic with negation. Despite using JSON Schema
in contrast to SHACL, our approach is not a constraint language. In OO-logic,
seamlessly embedded built-ins allow for procedural extensions. All Java built-ins
from the Java packages Math and String are integrated systematically. Using a
plugin API built-ins can easily be extended. RIF as an exchange format has
di erent dialects that support negation and a restricted set of built-ins, namely
functions and propositional logic [
This paper presented a proposal for a bottom-up enhancement of JSON, especially JSON Schema, towards a simple ontology language. Therefore, it was necessary to extend the existing functionality of JSON Schema with inheritance and relationships. Relationships are a signi cant concept in Linked Data and therefore also for building knowledge graphs. Besides the extension of JSON Schema, we presented the mapping from JSON towards triples that can be stored in a triple store used to reason over them. This extension towards an ontology language allows describing classes, including properties. Those classes and properties are then accessible by the rules we introduced for JSON. Those rules are based on OO-logic, a successor of F-Logic. Both the extension of JSON Schema and the OO-logic rules are implemented in a deductive database called SemReasoner. However, the extensions without the rules are easily realizable by adapting an existing JSON Schema validator implementation. Finally, we demonstrated a use case using the JSON Schema extensions and OO-logic rules.
Currently, the described concepts and technology are used in several adesso projects. JSON is used in many modern software applications. This has famil15 https://www.w3.org/TR/rif-core/#Overview 16 https://www.w3.org/2005/rules/wg/wiki/R2ML.html 17 https://www.w3.org/Submission/SWRL/ iarity, ease of use, and a short learning period for our software developers as a consequence. Indeed we achieved a high level of acceptance among our software developers in those projects. As a side e ect, our JSON schema export is also used in other applications in forms and adessos form generator for validation purposes. So we see that JSON, together with related technologies, closes the gap between semantic technologies and conventional software engineering. From our projects, we also get valuable feedback for our further work. Currently, we are working on integrating GraphQL as an additional simple query language and a cluster version of SemReasoner.
In future, we plan to publish several papers on SemReasoners reasoning engine describing the reasoning algorithms used and speci c features that are relevant for many of our current use cases.