=Paper=
{{Paper
|id=Vol-1211/paper8
|storemode=property
|title=Experiences Using Deliberation RuleML 1.01 as Rule Interchange Language
|pdfUrl=https://ceur-ws.org/Vol-1211/paper8.pdf
|volume=Vol-1211
|dblpUrl=https://dblp.org/rec/conf/ruleml/TylkowskiM14
}}
==Experiences Using Deliberation RuleML 1.01 as Rule Interchange Language==
https://ceur-ws.org/Vol-1211/paper8.pdf
Experiences Using Deliberation RuleML 1.01 as
Rule Interchange Language
Do Rulebases Need an External Vocabulary?
Matthias Tylkowski and Martin Müller
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çois Lévy, 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 ruleml: 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ütter, 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érôme Euzenat,
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ürr,
Dániel Varró, and Gergely Varró, 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ásio, 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çois Bry, François Fages, Massimo
Marchiori, and Hans Jürgen Ohlbach, editors, Principles and Practices of Seman-
tic Web Reasoning, volume 05371 of Dagstuhl Seminar Proceedings. Internationales
Begegnungs- und Forschungszentrum für Informatik (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