In the SW Stack, ontological and query knowledge can be supplemented with otherwise inexpressible knowledge deposited in rules. Basically, a rule is a state- ment that includes apremise (orprecondition/precedent) and aconclusion (or post- condition/antecedent), whereas the latter must be valid, when thepremiseis satis- fied (Hitzler, Krötzsch, and Rudolph2009). That means, any sentence of the form “if [...] then [...]” can be regarded as a rule (ibid.).
Rules can be formalized using various rule languages, for example, Semantic Web Rule Language (SWRL)(Horrocks, Patel-Schneider, Boley, et al.2004),F-Logic (Kifer, Lausen, and Wu1995) orDL RulesandDL-Safe Rules(cf.Hitzler, Krötzsch, and Rudolph2009).
Besides, any programming language can obviously express rules. In this disser- tation, we concentrate on rules that are expressed in “Logic Programming” (LP) and rules that are calledbusiness rules (BRs)orproduction rules, i.e., Event Condi- tion Action Rules. Production rules resemble program statements, i.e., they are operational, and are usually executed actively (ibid.), commonly in aBusiness Rule Management System (BRMS).
Definition 2.1 (Business Rule)
“A [BR] is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of
the business” (Business Rules Group2000).
In our context, the following definition is even more helpful, as it has been used in the context of ONTORULE and defines a rule, not only BRs:
Definition 2.2 (Rule)
“[. . .] a rule is a statement expressing a validation or derivation rule. Depending on the context, validation rules (also called constraints) may be seen as part of the ontology, which leaves derivation rules (also called decision rules) as a more
restricted definition” (Hoppenbrouwers, Nijssen, and Van Leeuwen2012).
Validation rules are also called integrity rules (ISO1987). Another meaning for a rule is an instruction for a person, or a combination of the before-mentioned definitions.
Moreover, query languages like SPARQL can be regarded as rules – they can ex- tract information from a given KB and then extend the existing data with new conclusions (Hitzler, Krötzsch, and Rudolph2009), for instance, by making use of SPARQL’sCONSTRUCT statement. Hence, a query can be considered as an antecedent of a rule.
Formalized BRs are heavily used in organizations, where many rules and policies apply, for example, in banks or insurance companies. However, all companies have BRs, even if the company uses them unwittingly. They apply to either cus- tomers, employees, suppliers, processes or other agents, like computer systems. For example, a BR can state that a returning customer can be granted a discount of 5 % on his next purchase. More general, BRs “can specify who can do what un- der specified conditions, the combination of inputs and controls needed, and the resulting outputs” (The Open Group2011). These rules do not necessarily have to be written down formally and certainly not in aBusiness Rules Language (BRL). Nevertheless, following the BRs approach, i.e., creating a formal specification of BRs, for instance, managed and executed in a BRMS, can support companies to discover complex decisions, validate forms and data with constraints or to com- ply with policies and regulations. Therefore, axioms specified in an OWL ontol- ogy can also be regarded as a rule, since they feature a premise and conclusion, such as the statement in Listing 2.6, expressing that if a person is the author of a book then this person belongs to the classBookauthor.
Person⊓ ∃authorO f.Book⊑Bookauthor.
Listing 2.6: An example rule in OWL DL (Hitzler, Krötzsch, and Rudolph2009).
With the publication of OWL 2 in 2009, even more statements in DL could be realized, like expressing an uncle relationship between two entities. However, many statements are not expressible in DL, but in a Domain Specific Language (DSL) for rules, such as calculations and aggregations, e.g.,sum,maxoravgor, for instance, a rule that is defining a classCof children whose parents are married as seen in Listing 2.7.
hasParent(x,y) ∧hasParent(x,z) ∧married(y,z) →C(x)
Approaches that combine DL languages, like OWL, and other formalisms, like F- Logic, an LP language, feature many advantages (Kattenstroth, May, and Schenk
2007; Krötzsch et al.2011).
One appropriate use case, for example, is the ontology and data integration (Kat- tenstroth, May, and Schenk2007).
Combining rule languages and ontologies in general is a current research topic and features many challenges. For example, the integration of OWA from the DL theories and the CWA from rule languages is very difficult, because it can lead to undecidability. An overview of the state-of-the-art issues is given in (De Bruijn et al.2009). Most notably, the new W3C standard RIF (Kifer and Boley2013), which provides a basic logic dialect (Boley and Kifer2013) and a production rule dialect (de Sainte Marie, Hallmark, and Paschke2013), is a promising approach.
Using rules and formalizing them using a rule language can be very beneficial for organizations (Berners-Lee2006; Gougeon2003):
• Separating business knowledge and logic from the remainder, for instance, program source, which empowers the business user to express, manage and automate the business’ driving knowledge. Thus, changes can be performed faster and easier than in an application that incorporates the business logic in the program source.
• They are better understandable than source code by business users, i.e., more accessible.
• The formalized representation is computable, i.e., inference and constraints can be applied. For example, rules can be applied in real time in a rule- based application, for instance, an e-commerce shop system, as exemplified in Listing 2.8.
• IT people get clearer and better quality requirements which leads to less inconsistencies and a better productivity.
• Rule-based systems are interoperable.
• They extend the expressiveness of shared knowledge.
• They interlock with other SW languages, such as RDF, OWL and SPARQL. • “Serendipitous re-use of knowledge in Rule form” (Berners-Lee2006). I F ( o b j e c t . value ≤ u s e r i n p u t . max_value ) THEN ⤦
Ç a d d t o r e s u l t s ( o b j e c t ) .
In order to manage BRs in an enterprise efficiently and correctly, the Business Rules Manifesto has been designed and published (Business Rules Group2003). This document concisely explains the nature of rules, their concerns and how to create and apply them properly.
2.4.1. Rule Languages and Standards
In addition to the DSLs mentioned in this section’s introduction, we briefly present the other languages mentioned and applied in the course of this thesis. Object- LogicandF-Logichave already been explained in the former section 2.3.3.
RIF(Kifer and Boley2013) has been presented as part of the SW Stack. Formerly planned as an interchange format between rule systems and to facilitate rule set synthesis and integration, it is considered a complete rule language today, featur- ing various dialects for specific use cases.
SWRL (Horrocks, Patel-Schneider, Boley, et al. 2004) is enumerated in this sec- tion, because it is a prominent language based ondatalogwhich is based onFOL, just as F-Logic. These languages combine LP and DL. However, since RIF is the new W3C recommendation and SWRL has the drawback of not being decidable without constraints (Krötzsch et al.2011), we omitted its use.
As mentioned, the boundaries between query and rule languages are blurred. In particular,SPARQL Inferencing Notation (SPIN)(Knublauch, Hendler, and Idehen
2011) is a language that integrates SPARQL rules with OWL. SPIN has been ap- plied in the course of this thesis for the prototypical modeling and integration of a method ontology (cf.chapter 4) and a Product Development Process (PDP) ontology.
Furthermore, during the ONTORULE project, we realized a particular use case with the WebSphere IBM/ILOG JRulesBRMS5together with our partners.
The final important standard for this thesis isSemantics of Business Vocabulary and Business Rules (SBVR)(Object Management Group 2015). SBVR/Structured En- glish (SE), a textual SBVR representation for the English language, has been ap- plied to model and validate parts of our case studies. For the future, upcoming Object Management Group (OMG) standards like Decision Model And Notation (DMN) (Object Management Group 2014) or Semantic Information Modeling for
5http://www-01.ibm.com/software/integration/business-rule-management/
Federation (SIMF)(Casanave 2012) offer promising approaches. Alternatively to rule languages, business logic can also be formalized with decision trees, tables or other models. Besides, rules can be expressed in General Purpose Languages (GPLs) and DSLs from other domains, likeUML, Business Process Execution Lan- guage (BPEL)orBusiness Process Model and Notation (BPMN).
2.4.2. Rule Engines and Management Software
As mentioned, formalized BRs are commonly executed in a rule engine, often part of a BRMS which is a “piece of software that supports [and manages] a large part of the [BRs] lifecycle within an organization” (Berrueta et al.2011). Typical popular representatives of rule engines are, for instance, Drools6, Jess7 and Web-
Sphere ILOG JRules BRMS8.
A major part of production rule engines rely on the evaluation strategy Rete (Forgy 1982). This algorithm performs forward and, in more recent versions, backward chaining in order to infer the knowledge. Nevertheless, several other, in some cases more modern, rule algorithms are applied. Besides, rule engines typically can perform side-effects on the runtime environment, e.g., modify the working memory(cf. Brachman and Levesque2004, chap. 7), print values or exe- cute other arbitrary system commands, depending on their access rights.
However, in this dissertation, we also apply LP languages that exhibit rules. For example, a management and development software for RDFS, OWL 2 (RL), F-Logic and Objectlogic is OntoStudio9, supported by the semantic middle ware and inference machine OntoBroker10.
In the context of ONTORULE (cf.section 2.5), a BRMS is able to draw on a KB in the form of an ontology that stores the facts (ABox) and conceptual data (TBox). Rule engines take a (derivation) rule set and the facts as input and interpret them in order to perform Create, Read, Update, Delete (CRUD) operations on the ABox, i.e., they create a set of assertions (Wood2010). Usually, they do not alter the rules themselves or the ontology’s TBox.
6http://www.drools.org/(visited on 08/05/2015) 7http://www.jessrules.com/(visited on 08/05/2015) 8http://www-01.ibm.com/software/integration/business-rule-management/ jrules-family/(visited on 08/05/2015) 9http://www.semafora-systems.com/en/products/ontostudio/(visited on 08/05/2015) 10http://www.semafora-systems.com/en/products/ontobroker/(visited on 08/05/2015)
Besides, management software for rules and ontologies usually feature various other vital functions, such as model testing, conflict resolution, constraints and verification, i.e., it checks “whether a proposed domain-specific model is in ac- cordance with all the rules of the generic conceptual model” (Hoppenbrouwers, Nijssen, and Van Leeuwen2012). The validation of the model, on the other hand, “is the process to check with the stakeholders (in their preferred language) who have the knowledge about the model, either implicit or explicit, that the proposed model is in accordance with the business reality” (ibid.).