Experiences Using Deliberation RuleML 1.01 as Rule Interchange Language Do Rulebases Need an External Vocabulary?

Matthias Tylkowski and Martin M¨uller

Binarypark, Erich-Weinertstr. 1, 03044 Cottbus, Germany

Abstract. After four decades of development, it is now well accepted that rules are one of the most suitable decisioning mechanism for change- intensive applications. Moreover, as web applications are expanding ev- erywhere, rule languages allow to publish, trasmit, deploy, and execute rules on the Web. This paper describes some principles and practices of developing rulebases from computationally independent business models using Deliberation RuleML version 1.01. We present a complete rulebase, based on the UServ Product Derby Case Study, ready to be deployed into rule systems allowing RuleML serialization. We also raise two issues that the next version of Deliberation RuleML may address: i) reference to external domain vocabularies used by rules and ii) distinction be- tween binary object properties, i.e. predicates/relations (whose second argument is a RuleML Ind element), and datatype properties, i.e. pred- icates/relations (whose second argument is a RuleML Data element), as in OWL.

1 Introduction

Rule based applications have a long history starting with the early attempts to make logic an executable language [13], the age of expert system applications [9], the introduction of object orientation [12], and the accommodation of rule-based reasoning into mainstream programming languages [18]. Experiments with rule interchange were pioneered back in 2006-2007 by [10, 14, 16] within a rule interchange framework R2ML, [21, 22]. Inspired by RuleML [5, 8, 20], R2ML provided an approach to integrate the Object Con- straint Language (OCL), the Semantic Web Rule Language (SWRL) and the Rule Markup Language (RuleML). Development of the R2ML language ended in 2008 and after that some progress was made by the W3C RIF activity to achieve a standard for rule interoperability. RuleML continued the development [7] so that by now various families of rule languages are available, including Delibera- tion RuleML [6], Reaction RuleML [17] and Legal RuleML [1, 2]. Towards restarting the debate about rule interoperability, this paper de- scribes a RuleML 1.01 rulebase accommodating the UServ Product Derby Case Study. The UServ study describes rules using natural language, and provides a scenario simulating a vehicle insurance service. The main purpose is to compute an annual premium for a vehicle insurance policy, belonging to an eligible client. Using a business-specific language, UServ divides its business rules into sets, each of them addressing different goals and contexts i.e. calculates the eligibil- ity scores in order to set the eligibility status for a client/driver/car, as well as pricing and cancelation policies at client portfolio level. The goal of this work is to provide a tutorial for practitioners developing business rule applications from natural language descriptions based on core ontological concepts like classes and variables, to target rule systems. UServ was also implemented using R2ML.

2 Mapping the Data Model into Rules

Rules should be based on vocabularies, i.e. the defined universe of discourse. The UServ case identifies classes such as cars, clients, drivers, their subclasses such as ConvertibleCar, YoungDriver and their properties e.g. theftRating, price, age, and so on. We use F-logic [11, 12] as the executable language for UServ rules. We map all universe-of-discourse artefacts according to the mapping rules in- troduced by R2ML. In addition, all vocabulary items (predicates, functions, con- stants) are identified by URIs, e.g. http://userv.org/ontology/price identi- fies the binary predicate price. Throughout this paper we use the RuleML 1.01 NafNegHornlogEq sub-language, where equality is used just because, in general, Deliberation RuleML 1.01 does not allow the direct definition of global constants (more in Section 2.4).

2.1 Mapping Classes

UServ classes are mapped to RuleML types or unary predicates. These are the two significant options to encode such classes – either by using the @type at- tribute or by using an explicit class definition by means of an atom (we assume a declaration of the namespace prefix us: as the iri http://userv.org/ontology/): C

car C

2.2 Mapping subClassOf Relation

The subClassOf relation is not included by RuleML as a language syntacti- cal construct. However, there are solutions to realize it, either by defining the subClassOf relation axiomatically or by binding the rulebase to an external vocabulary defining this relation. Defining subClassOf Axiomatically

X convertibleCar X car X It is obvious that such an axiom must be added for any pair of classes in the application domain that are subject of in a subClassOf relation. Moreover, as- suming that a translation to an executable language will preserve this axiom in this form, inference will be quite expensive as, usually, the subClassOf verifica- tion is much more of a constraint verification than an inference.

Binding a Rulebase to an External Vocabulary

An elegant solution, also discussed in [3] and [10], and implemented in OO jDREW, is to define this relation at the domain vocabulary level using an ap- propriate knowledge representation language, for example, RDF Schema: ..... Of course, the rulebase must provide a reference to this vocabulary, e.g by using type=”us:ConvertibleCar”, as discussed earlier.

High Order Atom Construct

The Atom content model of the Deliberation RuleML 1.01 could be extended to allow high order constructs1, such as: subClassOf convertibleCar

1 The older RuleML 0.91 was supporting high order constructs via ”Hterm” element. car

Declarative Definition of Instances

Finally, because the application domain has a limited number of (car) in- stances, only few of them may be convertible. In this case, from an inference engine perspective, it is less expensive to explicitly define cars and their convert- ibility as facts:

car car1 car car1

Notice that the above code describes the same individual as being an instance of two types but does not encode any subClassOf relationship between them.

2.3 Mapping Properties

UServ defines object properties and datatype properties. For example, price is a datatype property with a unique value. We map such properties into the traditional first order logic atom:

price C P

Also, to express something like ”the car’s potential theft rating is high”, we encode: theftRating C 4 high The structured datatype including an integer (i.e. 4) is more convenient than the plain symbol (i.e., high) as it allows a computer program to better deal with val- ues and their verbalizations. It is worthwhile to mention the Schema.org2 effort to standardize a large common sense vocabulary for web semantics. Unfortunately, the current version of RuleML does not allow such user-defined datatypes but only pre-defined XML datatypes, e.g. high Allowing external datatypes would be an improvement, as common types become more and more adopted by the Web community. However, the current content model of the RuleML element is xs:any; therefore, above, we were still able to encode the necessary structured data. The values of multi-valued properties such as airbag are mapped into RuleML lists (using ): airbags C driverAirbag frontPassengerAirbag Object-valued properties are mapped following the same principles. While the ”positional” RuleML used above adopted a logic programming syntax, the above method for defining properties (binary predicates) may not be ideal. However, ”slotted” RuleML, inspired by F-logic, as in Object-Oriented RuleML [3] and PSOA RuleML [4], could be used instead. Because UServ is built on an object-oriented approach (as are many other real-life applications), properties are binary relations. Therefore, it is obvious that knowledge representation languages that define vocabularies are more suited for defining such properties. Here is an example using OWL:

2 See http://schema.org and http://lists.w3.org/Archives/Public/public-vocabs/ Such a declaration would allow a rulebase validator to check the consistency of rules, e.g. fail when the below ”multi-priced” atom is encountered: p C 23000 23500

2.4 Mapping Built-in Predicates and Global Constants

UServ deals with all kinds of conditions such as numerical constraints, e.g. ”price is greater than $45,000”, or list membership conditions ”the car model is on the list of High Theft Probability Auto”. The mapping uses external built-in predicates, specifically the ones introduced by the W3C RIF Datatypes and Built-Ins 1.0. gt P 45000 member M HighTheftProbabilityAutoList Unlike logic programming, object oriented applications deal with global con- stants that are available to all objects. Similarly such a construct will greatly improve rulebase readability. Deliberation RuleML cannot directly represent global constants but uses equality to explicitly define a collection as an individual such as the above-used HighTheftProbabilityAutoList, e.g. HighTheftProbabilityAutoList car1 car3 car5 car6 However, such an approach requires the use of a hornlogeg RuleML language (”eq” referring to equality), while there may be applications which do not really require full equality but only the fragment needed for defining global constants. However, from the perspective of interoperability, it may be the responsibility of a translator to identify such constructs and translate them into global constants, while still keeping the rest of the rule translation in the realm of a hornlog RuleMl language.

2.5 Expressing Facts

UServ facts are descriptions of cars such as:

Car 4, 2005 Honda Odyssey, Full Airbags, Alarm System, Price $39,000, Type Luxury Car, Not on "High Theft Probability List" it is obvious to any object oriented modeler that car1 is the id of an object of the type LuxuryCar together with a set of properties (e.g. carModel:’Honda Odyssey’, modelYear:2005). This can be mapped to Deliberation RuleML 1.01 using the traditional logic programming approach: car4 Honda Odyssey car4 39000 car4 car4 driverAirbag frontPassengerAirbag sideAirbag We shall observe that the representation of ”Not on High Theft Probability List” corresponds to negation as failure (no positive fact). In addition, the global constant HighTheftProbabilityAutoList does not contain this car among its values. This solution has the advantage of preserving the logic programming approach, allowing a translator to still use the NafNegHornlog sub-language. There are object-oriented rule languages, notably F-logic, Drools [19], and PSOA RuleML allowing declarative descriptions of objects e.g., car4:LuxuryCar [ price -> 39000; modelYear -> 2005; hasAlarm-> true; airbags -> [’driverAirbag’,’frontPassengerAirbag’, ’sideAirbag’] ]. Deliberation RuleML could achieve such a representation as in Object-Oriented RuleML or by extending the slotted notation to allow relations as slot names: car4 39000 true ...

3 Rules and Rulebases

Deliberation RuleML 1.01 defines rulebases as collections of implications, facts and equations, where the element is specialized to an theftRating C theftRating C 4 high

C price C P gt P 45000 theftRating C 4 high

4 Conclusion and Future Work

This work provides some insight into the Deliberation RuleML 1.01 capabilities to serialize business rule scenarios. We hope that our findings will contribute to improvements in the next RuleML version. We also raise the issue that the next version of Deliberation RuleML may provide: i) reference to external do- main vocabularies used by rules and ii) distinction between binary object proper- ties, i.e. predicates/relations (whose second argument is a RuleML Ind element), and datatype properties, i.e. predicates/relations (whose second argument is a RuleML Data element), as in OWL. Future work will be concerned with a fam- ily of XSLT transformations allowing translation from specific sub-languages of Deliberation RuleML to Prolog and F-logic.

Acknowledgments

We would like to thank to Tara Athan, Harold Boley, Adrian Giurca and Adrian Paschke for their essential feedback and insights that made this work possible.

References

1. Tara Athan, Harold Boley, Guido Governatori, Monica Palmirani, Adrian Paschke, and Adam Wyner. Legalruleml: From metamodel to use cases - (a tutorial). In Leora Morgenstern, Petros S. Stefaneas, Fran¸coisL´evy, Adam Wyner, and Adrian Paschke, editors, RuleML, volume 8035 of Lecture Notes in Computer Science, pages 13–18. Springer, 2013. 2. Tara Athan, Harold Boley, Guido Governatori, Monica Palmirani, Adrian Paschke, and Adam Wyner. Oasis legalruleml. In Enrico Francesconi and Bart Verheij, editors, ICAIL, pages 3–12. ACM, 2013. 3. Harold Boley. Object-oriented : User-level roles, uri-grounded clauses, and order-sorted terms. In Michael Schroeder and Gerd Wagner, editors, RuleML, volume 2876 of Lecture Notes in Computer Science, pages 1–16. Springer, 2003. 4. Harold Boley. A rif-style semantics for ruleml-integrated positional-slotted, object- applicative rules. In Nick Bassiliades, Guido Governatori, and Adrian Paschke, editors, RuleML Europe, volume 6826 of Lecture Notes in Computer Science, pages 194–211. Springer, 2011. 5. Harold Boley, Mike Dean, Benjamin N. Grosof, Michael Kifer, Said Tabet, and Gerd Wagner. Ruleml position statement. In Rule Languages for Interoperability. W3C, 2005. 6. Harold Boley, Rolf Gr¨utter, Gen Zou, Tara Athan, and Sophia Etzold. A datalog + plus ruleml 1.01 architecture for rule-based data access in ecosystem research. In Antonis Bikakis, Paul Fodor, and Dumitru Roman, editors, RuleML, volume 8620 of Lecture Notes in Computer Science, pages 112–126. Springer, 2014. 7. Harold Boley, Adrian Paschke, and Omair Shafiq. Ruleml 1.0: The overarching specification of web rules. In Mike Dean, John Hall, Antonino Rotolo, and Said Tabet, editors, RuleML, volume 6403 of Lecture Notes in Computer Science, pages 162–178. Springer, 2010. 8. Harold Boley, Said Tabet, and Gerd Wagner. Design rationale for ruleml: A markup language for semantic web rules. In Isabel F. Cruz, Stefan Decker, J´erˆomeEuzenat, and Deborah L. McGuinness, editors, SWWS, pages 381–401, 2001. 9. Randall Davis, Bruce G. Buchanan, and Edward H. Shortliffe. Production rules as a representation for a knowledge-based consultation program. Artif. Intell., 8(1):15–45, 1977. 10. Adrian Giurca and Gerd Wagner. Rule modeling and interchange. In Negru et al. [15], pages 485–491. 11. Michael Kifer. Rules and ontologies in f-logic. In Norbert Eisinger and Jan Maluszynski, editors, Reasoning Web, volume 3564 of Lecture Notes in Computer Science, pages 22–34. Springer, 2005. 12. Michael Kifer and Georg Lausen. F-logic: A higher-order language for reasoning about objects, inheritance, and scheme. In James Clifford, Bruce G. Lindsay, and David Maier, editors, SIGMOD Conference, pages 134–146. ACM Press, 1989. 13. Robert A. Kowalski. Predicate logic as programming language. In IFIP Congress, pages 569–574, 1974. 14. Milan Milanovic, Dragan Gasevic, Adrian Giurca, Gerd Wagner, and Vladan Devedzic. Towards sharing rules between owl/swrl and uml/ocl. ECEASST, 5, 2006. 15. Viorel Negru, Tudor Jebelean, Dana Petcu, and Daniela Zaharie, editors. Proceed- ings of the Ninth International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, SYNASC 2007, Timisoara, Romania, September 26-29, 2007. IEEE Computer Society, 2007. 16. Oana Nicolae, Adrian Giurca, and Gerd Wagner. On interchange between jboss rules and jess. In Costin Badica and Marcin Paprzycki, editors, IDC, volume 78 of Studies in Computational Intelligence, pages 135–144. Springer, 2007. 17. Adrian Paschke, Harold Boley, Zhili Zhao, Kia Teymourian, and Tara Athan. Re- action ruleml 1.0: Standardized semantic reaction rules. In Antonis Bikakis and Adrian Giurca, editors, RuleML, volume 7438 of Lecture Notes in Computer Sci- ence, pages 100–119. Springer, 2012. 18. Mark Proctor. Relational declarative programming with jboss drools. In Negru et al. [15], page 5. 19. Mark Proctor. Drools: A rule engine for complex event processing. In Andy Sch¨urr, D´anielVarr´o,and Gergely Varr´o,editors, AGTIVE, volume 7233 of Lecture Notes in Computer Science, page 2. Springer, 2011. 20. Gerd Wagner, Grigoris Antoniou, Said Tabet, and Harold Boley. The abstract syn- tax of ruleml - towards a general web rule language framework. In Web Intelligence, pages 628–631. IEEE Computer Society, 2004. 21. Gerd Wagner, Carlos Viegas Dam´asio,and Grigoris Antoniou. Towards a general web rule language. Int. J. Web Eng. Technol., 2(2/3):181–206, 2005. 22. Gerd Wagner, Adrian Giurca, and Sergey Lukichev. A general markup frame- work for integrity and derivation rules. In Fran¸coisBry, Fran¸coisFages, Massimo Marchiori, and Hans J¨urgenOhlbach, editors, Principles and Practices of Seman- tic Web Reasoning, volume 05371 of Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum f¨urInformatik (IBFI), Schloss Dagstuhl, Ger- many, 2005. A UServProductDerbyCaseStudy.ruleml

1 2 11 12 13 14 17 18 HighTheftProbabilityAutoList 19 20 car1 21 car3 22 car5 23 car6 24 25 26 27 28 29 30 X 31 32 33 driver 34 X 35 36 37 38 person 39 X 40 41 42 43 44 45 46 X 47 48 49 youngDriver 50 X 51 52 53 54 driver 55 X 56 57 58 59 60 61 62 X 63 64 65 seniorDriver 66 X 67 68 69 70 driver 71 X 72 73 74 75 76 77 78 X 79 80 81 seniorDriver 82 X 83 84 85 86 youngDriver 87 X 88 89 90 91 92 93 94 95 X 96 97 98 youngDriver 99 X 100 101 102 103 seniorDriver 104 X 105 106 107 108 109 110 111 112 113 114 115 116 car4 118 Honda Odyssey 119 120 121 price 122 car4 124 39000 125 126 127 128 car4 130 131 132 133 car4 135 136 driverAirbag 137 frontPassengerAirbag 138 sideAirbag 139 140 141 142 143 144 145 146 Sara 148 female 149 150 151 152 153 Sara 155 38 156 157 158 159 160 Sara 162 163 164 165 166 Sara 168 Arizona 169 170 171 172 173 Sara 175 0 176 177 178 179 180 Sara 182 1 183 184 185 186 187 Sara 189 0 190 191 192 193 194 195 196 197 198 199 200 theftRating 201 202 203 204 205 206 C 207 208 209 210 convertibleCar 211 C 212 213 214 215 216 theftRating 217 C 218 219 220 4 221 high 222 223 224 225 226 227 228 232 233 C 234 235 236 237 price 238 C 239 P 240 241 242 gt 243 P 244 45000 245 246 247 248 theftRating 249 C 250 251 252 4 253 high 254 255 256 257 258 259 263 264 C 265 266 267 268 carModel 269 C 270 M 271 272 273 member 274 M 275 HighTheftProbabilityAutoList 276 277 278 279 theftRating 280 C 281 282 283 4 284 285 286 287 288 289 294 295 C 296 297 298 299 300 price 301 C 302 P 303 304 305 ge 306 P 307 25000 308 309 310 le 311 P 312 45000 313 314 315 carModel 316 C 317 M 318 319 320 321 member 322 M 323 HighTheftProbabilityAutoList 324 325 326 327 328 329 330 theftRating 331 C 332 333 334 3 335 moderate 336 337 338 339 340 341 342 347 348 C 349 350 351 352 353 price 354 C 355 P 356 357 358 359 carModel 360 C 361 M 362 363 364 365 lt 366 P 367 25000 368 369 370 371 372 member 373 M 374 HighTheftProbabilityAutoList 375 376 377 378 379 380 381 theftRating 382 C 383 384 385 1 386 low 387 388 389 390 391 392 393 394 395 396 397 injuryRating 398 399 400 401 405 406 C 407 408 409 airbags 410 C 411 412 413 414 415 416 injuryRating 417 C 418 419 5 420 extremely high 421 422 423 424 425 426 430 431 C 432 433 434 435 hasRollBar 436 C 437 438 439 440 injuryRating 441 C 442 443 5 444 extremely high 445 446 447 448 449 450 454 455 C 456 457 458 airbags 459 C 460 461 driver 462 463 464 465 injuryRating 466 C 467 468 4 469 high 470 471 472 473 474 475 479 480 C 481 482 483 airbags 484 C 485 486 driver 487 frontPassenger 488 489 490 491 injuryRating 492 C 493 494 3 495 moderate 496 497 498 499 500 501 505 506 C 507 508 509 airbags 510 C 511 512 driver 513 frontPassenger 514 sidePanel 515 516 517 518 injuryRating 519 C 520 521 1 522 low 523 524 525 526 527 528 529 530 531 532 533 534 eligibility 535 536 537 538 542 543 C 544 545 546 injuryRating 547 C 548 549 5 550 551 552 553 eligibility 554 C 555 556 0 557 not eligible 558 559 560 561 562 563 566 567 C 568 569 570 injuryRating 571 C 572 573 4 574 575 576 577 eligibility 578 C 579 580 1 581 provisional 582 583 584 585 586 587 588 589 C 590 591 592 theftRating 593 C 594 595 596 4 597 598 599 600 eligibility 601 C 602 603 1 604 provisional 605 606 607 608 609 610 611 616 617 C 618 619 620 621 622 eligibility 623 C 624 625 0 626 627 628 629 630 631 eligibility 632 C 633 634 1 635 636 637 638 639 640 eligibility 641 C 642 643 2 644 eligible 645 646 647 648 649 650 651 652 653 654 655 656 youngDriver 657 658 659 660 661 662 D 663 664 665 666 male 667 D 668 male 669 670 671 age 672 D 673 A 674 675 676 lt 677 A 678 25 679 680 681 682 youngDriver 683 D 684 685 686 687 688 689 D 690 691 692 693 female 694 D 695 female 696 697 698 age 699 D 700 A 701 702 703 lt 704 A 705 20 706 707 708 709 710 youngDriver 711 D 712 713 714 715 716 717 718 719 720 721 722 seniorDriver 723 724 725 726 727 728 D 729 730 731 732 age 733 D 734 A 735 736 737 738 gt 739 A 740 70 741 742 743 744 745 seniorDriver 746 D 747 748 749 750 751 752 753 754 755 756 757 isEligible 758 759 760 761 762 763 D 764 765 766 767 768 trainingCertifcation 769 770 D 771 772 773 774 youngDriver 775 D 776 777 778 779 780 isEligible 781 D 782 783 784 785 786 787 788 D 789 790 791 792 793 hasTrainingCertifcation 794 795 D 796 797 798 799 seniorDriver 800 D 801 802 803 804 805 isEligible 806 D 807 808 809 810 811 816 817 D 818 819 820 821 Driver 822 D 823 824 825 826 827 youngDriver 828 D 829 830 831 832 833 834 seniorDriver 835 D 836 837 838 839 840 841 isEligible 842 D 843 844 845 846 847 848 849 850 851 852 853 854 hasTrainingCertification 855 856 857 858 859 862 863 D 864 865 866 867 hasTrainingFromSchool 868 869 D 870 871 872 873 874 hasTrainingCertifcation 875 876 D 877 878 879 880 881 885 886 D 887 888 889 890 hasTrainingFromLicensedDriverTrainingCompany 891 892 D 893 894 895 896 897 hasTrainingCertifcation 898 899 D 900 901 902 903 904 908 909 D 910 911 912 913 hasSeniorDriverRefresherCourse 914 915 D 916 917 918 919 920 hasTrainingCertifcation 921 922 D 923 924 925 926 927 928 929 930 931 932 933 driverRiskRating 934 935 936 937 940 941 D 942 943 944 945 noOfDUI 946 D 947 DUI 948 949 950 951 gt 952 DUI 953 0 954 955 956 957 958 driverRiskRating 959 D 960 961 4 962 high 963 964 965 966 967 968 972 973 D 974 975 976 977 noOfAccidents 978 D 979 accidents 980 981 982 983 gt 984 accidents 985 2 986 987 988 989 990 driverRiskRating 991 D 992 993 4 994 high 995 996 997 998 999 1000 1004 1005 1006