Object oriented logic (abbreviated: OO-logic) combines the advantages of conceptual modelling that comes from object-oriented framebased languages with the declarative style, compact and simple syntax, and the well de ned semantics of a logic-based language. OO-logic supports typing, meta-reasoning, complex objects, properties, classes, inheritance, rules, queries, modularization, and scoped inference. In this paper we describe the capabilities of knowledge representation systems based on OO-logic and illustrate the use of this logic for ontology speci cation. OO-logic is a successor of F-logic. It incorporates the experience of a decade of using F-logic in real life applications. OO-logic simpli es the syntax of F-logic and has its focus on rule based reasoning with large sets of data (billions of triples).
A conceptual model (or an ontology) is an abstract, declarative description of
the information for an application domain. It includes the relevant vocabulary,
constraints on the valid states of the information, and the ways to draw
inferences from that information. As applications grew in sophistication, computing
power increased and our knowledge of algorithms for query processing enriched,
the use of rule-based languages for processing information has become more and
more attractive. A further push came from the Semantic Web, which increased
the awareness of the need for logic-based languages for processing ontologies and
other distributed knowledge on the Web. This awareness led W3C to create a
working group that was chartered with the creation of a Rule Interchange Format
Copyright 2019 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
(RIF) [
In the second section (section 2) we will give a short introduction to OO-logic including the semantics and the implementation of the language. Afterwards in section 3 we compare it to other rule languages and nally in section 4 a rst industrial use case is presented. 2
OO-logic is an object-oriented language and ontologies are modelled in this language in an object-oriented style. One starts with class hierarchies, proceeds with type speci cations, de nes the relationships among classes and objects using rules, and nally populates the classes with concrete objects. The rst part of this example is a small ontology.
The last line of Listing 1 contains a query (1) to the object base. It inquires the sons of Abraham and will return the answer ?Y = Isaac.
Object names and variable names Object names and variable names, also called id-terms, are the basic syntactical elements of OO-logic. To distinguish object names from variable names, the later are pre xed with a ?-sign. Examples of object names are Abraham, Man, father, and of variable names are ?X, ?Y. Complex id-terms are created from function symbols and other id-terms as usual in predicate logic: couple(Abraham, Sarah), f(?X).
Class hierarchies Class hierarchies are de ned with the help of isa-OO-atoms and subclass-OO-atoms. An isa-OO-atom of the form o:c states that an object o is a member of class c. A subclass-OO-atom of the form sc::cl says that the class sc is a subclass of the class cl. In our example it is stated that Man is a sub-class of class Person and Abraham is an instance of class Man. In contrast to other object-oriented languages where an object can be an instance of exactly /* class hierarchy */ Woman::Person. // every woman is a person Man::Person. // every man is a person Person[properties: {father,son}]. // a person has properties father and son father[range: Man]. // property father has values which are men father[minCardinality:1, maxCaridnality:1]. // everybody has exactly one father son[range: Man]. // property son has values which are men /* rules consisting of a rule head and a rule body */ rule1: ?X[son: ?Y] // if ?Y is a man and ?Y has father ?X :- ?Y:Man, ?Y[father: ?X]. // then ?X has son ?Y /* facts */ Abraham:Man.
Isaac:Man.
Isaac[father: Abraham]. /* query */ ?- Abraham[son: ?Y].
// Abraham is a man // Isaac is a man // Isaacs father is Abraham // give me all sons of Abraham (1)
Listing 1: A small ontology in OO-logic one most speci c class (e.g. [12]), OO-logic permits to be an instance in several, possibly incomparable, most speci c classes. Likewise, a class can have several incomparable most speci c super-classes. Thus, the class hierarchy is a directed acyclic graph.
Properties Application of a property to an object is speci ed using data-OOatoms. A remarkable feature of OO-logic is that properties are also denoted by objects and can be handled like regular objects without any special language support. For instance, in Listing 1 the property names father and son are object names just like Isaac and Abraham. A property can have multiple values. Properties are inherited by sub-classes and instances.
Variables Variables are permitted at all positions in isa-, subclass-, and dataOO-atoms, so objects, properties, and classes are represented and queried uniformly using the same language facilities. In this way, OO-logic naturally supports the meta-information facility.
Signatures In contrast to F-logic which provides a sophisticated schema modelling language in OO-logic meta modelling is used. This means that classes and properties itself are seen as objects and we can have properties for these objects as well. This is the main di erence to F-logic. In our previous example we expressed that class Person has properties son and father. For property father we stated that the range is Man. Property father must have at least one value (minCardinality = 1). Meta modelling allows to add various information to such properties.
Predicate Symbols Experience shows that it is convenient to be able to use predicates alongside objects. In OO-logic, predicate symbols are used in the same way as in other deductive languages, e.g., in Datalog. A predicate formula is constructed out of a predicate symbol followed by one or more id-terms separated by commas and included in parentheses. Such a formula is called a P-atom. In the following some P-atoms are shown.
married(Isaac,Rebekah).
male(Jacob).
Built-ins OO-logic supports built-ins which de ne procedural attachments that are seamlessly embedded into OO-Logic. Usually a built-in represents an in nite relation. Built-ins are always preceded by an " \ (underscore). E.g. adding two numbers to a third can be considered as an in nite relation between 3 numbers: _plus(?X,?Y,?Z)
Dependent on two of the three arguments an algorithm behind the built-in computes the third argument. OO-Logic provides among others all methods of the Java packages Math and String as built-ins.
Aggregations Aggregations are special built-ins. In contrast to ordinary builtins they have a whole set of values as input and generate output values dependent on the input. In newer logic like F-logic a special syntax has been introduced for such aggregations:
?N := count{?X | ?X:Person}
This expression means: count all instances of class Person and assign this number to variable ?N.
Such aggregation expressions can also have a grouping variable. This means that the results are grouped according to the values of the grouping variable ?G: r: numberOfPersons(?G,?N) :
?N := count{?X [?G] | ?X:Person, ?X[hasAge: ?G]}.
This rule determines for all occurring ages the number of persons with that age. As an extension to F-logic whole tuples are allowed here in the variable and grouping positions.
Path expressions Path expressions are a standard feature in most objectoriented languages. In OO-logic, a path expression of the form obj.expr denotes the set of objects fa1,a2,...g, such that obj[expr: fa1,a2,...g] is true. Here are some path expressions and the sets of objects they refer to in our example (Listing 1).
Rules Rules are one of the best known technologies for building applications around ontologies. We already have seen examples of rules in Listing 1. In general, a rule is an expression of the form head :- body, where the head of the rule is a Boolean combination of OO-molecules and the body is a Boolean combination of OO-molecules or negated OO-molecules. Conjunctions are represented using commas. Disjunction in the body is represented by semicolons. Molecules may contain variables, and all variables are implicitly 8-quanti ed outside of the rule. Variables can be anonym like ? . Using an anonymous variable in a rule means that the value which instantiates the variable does not matter. Rules in OO-logic have a logical semantics based on the principles developed in the context of logic programming and deductive databases. Consider the following rule from Listing 1: rule1:
?X[son: ?Y] :- ?Y:Man, ?Y[father: ?X].
Scoped Inference: Modularization and Integration The concept of scoped
inference [
Predicates and molecules in a rule can optionally be labeled with module references like this: pred-or-molecule@module-name. A subformula of the form L@N inside body or a rule is a query to module N, which asks whether L is implied by the knowledge base that resides in module N. For instance, some data source, gendata, may provide information about parents of various individuals. One may not be able to (or may not want to) insert new rules into that data source in order to preserve the integrity of that data. However, it is possible to create a di erent module, say mygenealogy, which reference the information in the aforesaid data source. In the following we see queries for information in those two di erent modules: ??
Module names can be arbitrary identi ers. As an extension to F-logic variable names are allowed in module positions as well. Besides modularization, the concept of a module is a potent vehicle for integration of and reasoning about ontologies that reside at di erent sources. If one just unions the rules and the facts found at the sources of interest, as implied by the import mechanism of the OWL language, the rules may contradict each other or have subtle and unintended interactions. In contrast, if di erent sources are treated as separate modules, one can distinguish the information de ned at the di erent sources and then specify the appropriate integration rules. These rules may give preference to some sources, partially or completely disregard information supplied by others, or clearly ag con icting information.
Special syntax For convenience reasons OO-logic provides a special syntax for comparisons and for mathematical expressions: r0: ?X:\todo{blank?} YoungPeople :- ?X[age: ?Z], ?Z < 20. r1: ?X: Teenager :- ?X[age: ?Z], 13 <= ?Z < 20.
An assignment of the value a mathematical expression is given in the following way:
r: ?X[a: ?Y] :- ?X[b: ?Z], ?Y := (?Z+5)*3.
These mathematical expressions allow besides the basic arithmetical operations also functions like sin, cos, sqrt, etc.
Implementation of OO-logic semantics OO-logic is implemented in the
system sem.reasoner, which is a direct successor of OntoBroker [
The main ideas of the actual translation from OO-logic into the relational syntax are as follows: First, molecular expressions are replaced by equivalent conjunctions of atomic molecules. Next, these atomic expressions are represented by rst-order predicates. The resulting set of rules augmented with additional closure rules to capture the speci c semantics of OO-logic. Some rules are needed to express statements such as the transitivity of the subclass relationship. Others implement inheritance, and so on. Table 1 shows the second stage in the above process. Whenever an OO-logic speci cation is split into modules, the predicates type, subclass, member, value, etc., in table are disambiguated for di erent modules by adding an additional attribute.
The following are examples of some of the closure rules added in stage 3 of the above process: // closure rules for ?X :: ?Y a1: subclass(?X, ?Z) :- subclass(?X, ?Y), subclass(?Y, ?Z). // closure rules for ?X : ?C a2: member(?O, ?C) :- subclass(?C1, ?C), member(?O, ?C1). // structural inheritance of signatures a3: value(?C1, properties, ?A) :
subclass(?C1, ?C2), value(?C2, properties,?A).
The resulting set of rules and facts is a set of Horn clauses with negation. This set of logic clauses is then processed using strati ed semantics (minimal model semantics) for rule-based languages [14].
Experience with OntoBroker has shown that implementing a rule based
system on top of a database or a triple store heavily restricts the performance of
the system. Therefore the reasoning engine sem.reasoner has its own proprietary
persistency layer. This persistency layer is based on B+ trees [
In the following we compare OO-logic with F-logic, SWRL, and SPIN - languages used in the semantic web eld.
Comparison to F-logic OO-logic is a successor to F-logic. Nearly a decade of
using F-logic has shown that especially signatures in F-logic have a too complex
syntax. Therefore we chose meta-modelling for de ning properties and
properties of those properties. This seems to be much easier to understand for subject
matter experts. In additon we allow variables at all positions of OO-atoms and
OO-molecules. So even at the property and module positions variables are
allowed. Our special syntax for expressing comparisons, mathematical expressions
was very well adopted from SMEs. Finally to have a full set of built-ins from
Java Math and String library was very important for the applications. In the
same way as it was with OntoBroker built-ins are easily extendible.
Comparison to SWRL SWRL (Semantic Web Rule Language) [
Comparison to SPIN SPIN [
A
rst Industrial Use Case In the following we describe an industrial application \Routing and Reconciliation of SWIFT transactions in a bank" where OO-logic is already applied in.
OO-logic is currently used in a core banking system of a large European bank for reconciliation and routing of SWIFT messages. SWIFT (Society for Worldwide Interbank Telecommunication) is a telecommunication infrastructure for handling international money transactions. SWIFT also de nes messages for those transactions. OO-logic rules are used for describing routing and reconciliation of such messages. Routing means that incoming messages are routed to di erent target systems. Reconciliation means that related messages are checked against each other. For instance a company has two bank accounts A,B in different banks. All incomes go to A, all outcomes go from B. At the end of each month a large amount of money has to be transferred from A to B in order to cover all the salaries. Now it has to be checked whether the money transferred from A to B covers all the outgoing salary transactions. For this purpose a small ontology describing the classes and properties of those SWIFT messages has been created. The incoming SWIFT messages are translated to OO-logic objects and are validated against the ontology. OO-logic rules are used to describe where a SWIFT message has to be routed to and rules do the check for the di erent reconciliation scenarios according to the values of the properties of the SWIFT messages. The standard routing and matching scenarios have been directly described using OO-logic rules. For derived scenarios inductive learning (rule learning) has been applied to automatically create appropriate rules. This application processes up to 100000 transactions a day. A transaction corresponds to one money transfer. This is the whole volume of transactions of the bank for that domain. The application is required to have a maximum down time of 4 hours a year. An example for such a rule is the following: Match3: match(?MT910,?MT103,Match3) :?MT103:MT103, ?MT910:MT910, ?MT103[sendersReference:?R, currency:?C], ?MT910[referenceToRelatedTransaction:?R, currency:?C, value:?V], ?S:= sum{?V [?MT910] | ?MT103:MT103, ?MT910:MT910, ?MT103[sendersReference:?R, currency:?C, value:?V], ?MT910[referenceToRelatedTransaction:?R, currency:?C]}, ?S = ?V.
It states that a message of type MT910 matches with several messages of type MT103 if the sum of the values in MT103 equals to the value in MT910. 5
We have presented OO-logic which is a successor of F-logic. Both languages differentiate conceptual concepts by its syntaxes. OO-logic heavily simpli es the syntax of F-logic, adds additional useful features and adds special syntax for convenience reasons. Among others OO-logic includes all Math and String functionalities of Java as built-ins. OO-logic is implemented by the reasoner sem.reasoner. Its architecture allows to e ciently do reasoning in large data sets. OO-logic is a logical consequence of a decade using F-logic in real world applications. With OO-logic we think we have a mature ontology and rule language. adesso (https://adesso.de) has OO-logic adopted in several of its projects. In future we will focus on the further development of the reasoning engine sem.reasoner. So topics like clustering, data safety, distributed reasoning are on the agenda. 10. Kifer, M., De Bruijn, J., Boley, H., Fensel, D.: A realistic architecture for the semantic web. In: International Workshop on Rules and Rule Markup Languages for the Semantic Web. pp. 17{29. Springer (2005) 11. Kifer, M., Lausen, G., Wu, J.: Logical foundations of object-oriented and framebased languages. Journal of the ACM (JACM) 42(4), 741{843 (1995) 12. Liu, M.: Deductive database languages: problems and solutions. ACM Computing
Surveys (CSUR) 31(1), 27{62 (1999) 13. Sintek, M., Decker, S.: Triplea query, inference, and transformation language for the semantic web. In: International Semantic Web Conference. pp. 364{378. Springer (2002) 14. Van Gelder, A., Ross, K.A., Schlipf, J.S.: The well-founded semantics for general logic programs. Journal of the ACM (JACM) 38(3), 619{649 (1991) 15. Yang, G., Kifer, M., Zhao, C.: Flora-2: A rule-based knowledge representation and inference infrastructure for the semantic web. In: OTM Confederated International Conferences" On the Move to Meaningful Internet Systems". pp. 671{688. Springer (2003)