Translators for Interoperating and Porting Object-Relational …ruleml.org/talks/GenZou-TransInterPortObjRelKnowledge... · 2018. 4. 20. · neighborRel(Outer1,Inner) ( betweenRel(Outer1,Inner,Outer2)

Translators for Interoperating and PortingObject-Relational Knowledge

RuleML WebinarApril 27, 2018

Gen Zou

Faculty of Computer Science,University of New Brunswick, Fredericton, Canada

1 / 49

Outline

1 Background & Related Work

2 Revising PSOA RuleML for Version 1.0

3 Interoperating and Porting PSOA RuleML

4 Use Cases

5 Evaluation

6 Conclusions and Future Work

2 / 49

Outline



3 Interoperating and Porting PSOA RuleMLInteroperation and Portation ArchitecturePSOA Transformation StepsInteroperation from PSOA to TPTPInteroperation from PSOA to PrologSemantics-Preservation Proofs

4 Use CasesPort Clearance RulesOfficeProspector

5 EvaluationEvaluation of PSOA RuleML 1.0Evaluation of PSOATransRun Instantiations


Rule Languages

Provide a foundation for data and knowledge representationas well as problem solving in AI, Semantic Web, and IT at largeUsed to express

Knowledge for semantic data accessAssociations among dataPrivacy/security/trust policiesBusiness logicsLegal normsBiomedical concept definitions...

Paradigms of modeling entity connectionsRelationalObject-centeredCombined

Since systems have been developed on top of languages withdifferent paradigms, it is often necessary to translate, integrate,and reuse Knowledge Bases (KBs) expressed in differentlanguages and/or different paradigms

3 / 49

Relational Rule Languages (1)

Widely used for representing, e.g., First-Order Logic (FOL) andLogic Programming (LP)Model dependency among n entities as an atom, here asan n-ary predicate applied to a tuple, which is a sequence of npositional arguments

Example of Fact and Rules (in an abstract syntax):Symmetry and Projection

betweenRel(canada, usa, mexico)∀Outer1, Inner , Outer2 :

betweenRel(Outer2, Inner , Outer1) ⇐ betweenRel(Outer1, Inner , Outer2)

∀Outer1, Inner , Outer2 :neighborRel(Outer1, Inner) ⇐ betweenRel(Outer1, Inner , Outer2)

4 / 49

Relational Rule Languages (2)

Based on predicate logic, especially FOL and its variants/subsetsTPTP-FOF

Dialect of TPTP (Thousands of Problems for Theorem Provers),a widely used language for interoperating KBs between automatedtheorem proversCan express the First-Order Formulas (FOF) of FOL

PrologWidely used LP language, with an ISO standardPure Prolog can also be seen as a subset of FOL

5 / 49

Object-Centered Rule Languages (1)

Receive increasing attention because of expanding research anddevelopment in linked data on the Web, graph / knowledge stores,and big data in NoSQL DBsAn object is represented by a unique Object IDentifier (OID) typedby zero or more classes and described by an unordered collectionof slots, each being a pair of a name and a fillerAn OID-describing slotted atom in AI is called a frame

Example of Fact and Rule: Slot Introduction

Syntax: “#” denotes membership; “→” connects the slot name and filler

b1#betweenObj(outer1 → canada; inner → usa; outer2 → mexico)

∀B, Out1, In :

Out1#space(neighborSlot → In) ⇐ B#betweenObj(outer1 → Out1; inner → In)

6 / 49

Object-Centered Rule Languages (2)

Notation 3 (N3)Initially defined by Tim Berners-LeeExtends RDF, a W3C language representing information in theWeb, with rules

7 / 49

Object-Relational Rule Languages

Combine the object-centered and relational paradigms, either in aheterogeneous or a homogeneous wayHeterogeneous

1 Allow atoms in both object-centered and relational forms, evenmixed in the same rule

2 Flora-2/F-logic and RIFHomogeneous

1 In addition to item Heterogeneous, sub-item 1, integrateobject-centered and relational atoms to a unified form

2 PSOA RuleML

Example of Fact and Rule: Slot Introduction

b1#betweenObjRel(canada, usa, mexico; dim → 2; orient → northSouth)∀B, Out1, In, Out2 :

Out1#space(neighborSlot → In) ⇐ B#betweenObjRel(Out1, In, Out2)

8 / 49

Related Work on Rule Interoperation

Standardized languages for interoperation: RuleML, W3C RIF,ISO Common Logic, OMG OntoIOpTranslations between different languages/logics

RuleML-facilitated translation between N3 and PrologRelational data in DBs exposed as RDFFOL subsets to Answer Set Programs (ASPs)Object-centered language Knowledge Machine to ASPs

9 / 49

Open Problems

There were few studies on the syntax and semantics of languagesconstituting homogeneous object-relational combinationsThe interoperation between these, as exemplified by PSOA,on one hand and purely relational or purely object-centeredrule languages on the other hand was not investigated.In particular, it was an open question whether the translationsrequired for interoperation are semantics-preservingThere was no reasoning system available for answering queriesposed to KBs in PSOA RuleML. It was open whethertranslator-based implementation/portation is appropriate not onlyfor reusability and maintainability but alsofor use cases and applications

10 / 49

Objectives (1)

Overall architectureDesign a translator-based architecture forinteroperating and porting object-relational knowledge

Translations and translator-based reasoning systemsStudy the interoperation from PSOA RuleML to the purely relationallanguages TPTP and Prolog as well as from the purelyobject-centered N3 to PSOA RuleMLCharacterize sublanguages of PSOA RuleML for which thetranslations are semantics-preserving, i.e. sound and completeFocusing on semantically compatible sublanguages, realizetranslators based on the proposed translationsUsing the translators, on top of multiple runtime engines, realizeprototype reasoning systems for PSOA RuleML query answering

11 / 49

Objectives (2)

Evaluation through use cases and test casesApply the PSOA RuleML language and its translator-basedreasoning systems to use casesDevelop test cases and evaluate the realizedreasoning systems for PSOA

Revision of PSOA RuleMLRevise the syntax and semantics of PSOA RuleML based onfindings in the development and the evaluation. Update thetranslators accordingly

12 / 49

Outline







PSOA RuleML Prior to Version 1.0

Positional-Slotted Object-Applicative (PSOA) RuleML permitsatom to apply predicate – possibly identified by OID typed bypredicate – to bag of tupled descriptors (tuples) and to bag ofslotted descriptors (slots)

General case (multi-tuple):

Oidless : f([t1,1 . . . t1,n1] . . . [tm,1 . . . tm,nm] p1->v1 . . . pk->vk)

Oidful : o#f([t1,1 . . . t1,n1] . . . [tm,1 . . . tm,nm] p1->v1 . . . pk->vk)

Special cases (single-tuple brackets andmembership parentheses are optional):

Relationship: f([t1 . . . tn])Frame: o#f( p1->v1 . . . pk->vk)Combined: o#f([t1 . . . tn] p1->v1 . . . pk->vk)Membership: o#f()

The predicate f can be Top, denoting the root predicate

13 / 49

New Kinds of Descriptors in Psoa Atoms

Orthogonally to the tupled vs. slotted distinction, a descriptor in anatom can be independent or dependent on the atom’s predicate:http://ruleml.org/talks/PSOAPerspectivalKnowledge-talk.pdf

Descriptors dependent on predicate are sensitive to predicatescope, and can only be queried with the same predicateDescriptors independent from predicate are not sensitive topredicate scope, and can be queried with a different predicateOidless-vs.-oidful and tupled-vs.-slotted-vs.-tupled+slotteddimensions of atoms are augmented by 3rd dimension ofperspectivity:

Perspeneutral: having one or more independent descriptorsPerspectival: having one or more dependent descriptorsPerspeneutral+perspectival: combining one or more independentplus one or more dependent descriptors

14 / 49

http://ruleml.org/talks/PSOAPerspectivalKnowledge-talk.pdf

Presentation Syntax of General Psoa Terms(Atoms and Expressions)

Four “ . . . ”-subsequences for four kinds of descriptors, wheresuperscripts indicate subterms that are part of dependent (+) vs.independent (-) descriptors (m+,m-,k+,k- ≥ 0, n+i+ ,n-i- ≥ 0for any i+ and i- such that 1 ≤ i+ ≤ m+ and 1 ≤ i- ≤ m-):

o#f(+[t+1,1 . . . t+1,n+1] . . . +[t+m+,1 . . . t+m+,n+m+]

-[t-1,1 . . . t-1,n-1] . . . -[t-m-,1 . . . t-m-,n-m-]

p+1+>v+1 . . . p+k++>v

+k+

p-1->v-1 . . . p-k-->v

-k-)

Relationships now have the form f(+[t+1,1 . . . t+1,n+1]),

where brackets can be omitted for n+1 ≥ 1

15 / 49

Rich TA Example (Facts Only): Graphical View

Individual OID John described independently and under theperspectives of predicates Teacher, TA, Student

16 / 49

Rich TA Example (Rule Added): Presentation SyntaxDocument (...Group (_Teacher##_Scholar % Taxonomy_Student##_Scholar_TA##_Teacher_TA##_Student_John#_Teacher(+[_Wed _Thu] % Data

_coursehours+>12 _dept+>_Physics_salary+>29400 _income->29400)

_John#_Student(+[_Mon _Tue _Fri] -[1995 8 17]_coursehours+>20 _dept+>_Math _gender->_male)

Forall ?o ?ht ?hs ( % Rule?o#_TA(_workload+>_high) :- % ":-" stands for "⇐"

And(?o#_Teacher(_coursehours+>?ht)math:greaterThan(?ht 10) % ?ht>10?o#_Student(_coursehours+>?hs)math:greaterThan(?hs 18)) % ?hs>18

))

) 17 / 49

Revision of Semantics: Old Semantics

Cannot formalize perspectival knowledge, e.g. for Rich TAExampleCan only interpret an oidless psoa term after applying staticobjectificationCannot deal with an expression term – which returns an arbitraryvalue – since giving it an OID would make the function act as theclass of the OID and lead to a truth valueCauses reasoning overhead for an atom whose predicate in theKB clauses is used only as a Prolog-like relation, e.g. does notoccur with an OID or slots

18 / 49

Revision of Semantics: New Semantics

Allow direct interpretation and truth evaluation of oidless psoatermsAdd objectification restriction

TValI (f(...)) = t

if and only if

TValI (Exists ?O (?O#f(...))) = t

Incorporate semantics of independent and dependent descriptorsfor psoa termsUpdate describution restriction for independent and dependentdescriptors (cf. later)

19 / 49

Outline







Outline







PSOA-Centered Interoperation Framework

Employs PSOA as the canonical language and implementations ofbidirectional translations between PSOA and any designated language

PSOA Ld1

Ld2

Ld3

Ldn-1

· · ·

Ldi -to-Ldj translation can be composed fromLdi -to-PSOA translation and PSOA-to-Ldj translation

20 / 49

Specialization of Interoperation Framework

Specialization of interoperation framework for N3, Prolog, and TPTP

PSOA(Pure) Prolog N3

TPTP

Implemented translations indicated by solid arrows:Translations composed of a normalization within source languageand a conversion from normalized source to target languageNormalization within PSOA composed of modularized steps

21 / 49

PSOATransRun Portation Framework

PSOATransRun[PSOA2Lt ,runtime] framework providesimplementations of PSOA RuleML query answering(through porting PSOA KBs and queries) by

Translating input KB and query into already implemented Lt ,using the translator component PSOA2LtExecuting translated query against translated KB in runtimereasoning engine to get the answersTranslating the answers in Lt back to PSOA, using a (partial)translator from Lt to PSOA that acts only on base terms but notnecessarily KBs and formulas. This component is dependent onthe translator PSOA2Lt and can be implemented as a supplementto PSOA2Lt , hence is omitted from the bracketed notation

Instantiations of PSOATransRun (project repository of sources:https://github.com/RuleML/PSOATransRunComponents)

PSOATransRun[PSOA2TPTP,VampirePrime]: Lt = TPTP,combining PSOA2TPTP and VampirePrime enginePSOATransRun[PSOA2Prolog,XSBProlog]: Lt = Prolog,combining PSOA2Prolog and XSB Prolog engine

22 / 49

https://github.com/RuleML/PSOATransRunComponents

Semantics-Preserving Translation

For a translation trLs ,Ltfrom the source language Ls to the target

language Lt :Sound: all entailments that hold after translation to Lt alreadyhold in Ls

Complete: all entailments in Ls still hold after translation to Lt

Semantics preserving = sound + completeSemantics-preserving translation required for porting KBs andqueries in Ls to Lt :

ΦLs

BQLs

ΦLt

BQLt

| Ls | Lt

trLs ,Lt

trLs ,Lt

23 / 49

Outline







Unnesting

Embedded psoa atomsWidely used in object-centered languages such as RDF, N3, andFlora-2/F-logic as a shorthand notationPSOA RuleML supports the use of embedded oidful atoms, e.g.o1#c(p->f(o2#d))

Unnesting transformation decomposes nested atomic formulasinto equivalent conjunctions

Unnest(o1#c(p->f(o2#d)))= And(o2#d o1#c(p->f(o2)))

24 / 49

Objectification: Systematics

Objectification transformation realizes the objectification restrictionby transforming KBs and queries such that entailments can beestablished under a relaxed semantics in which the restriction isno longer requiredSystematics of objectification transformation of KBs/queries

Static: generate explicit OIDs for all of the KB’s oidless atomsUndifferentiated: uniformly transforms oidless atoms everywhereusing explicit existentialsDifferentiated: transforms oidless atoms based on their occurrencesusing Skolem-like constants etc.

Static/Dynamic (novel enhancement): avoid generating explicitOIDs for relational predicates, instead constructing virtual OIDs asquery variable bindings

25 / 49

Static vs. Dynamic Objectification of Atoms

KB: _work(_Kate _Rho4biz "Director")

Query: ?O#_work(?P ?C ?J)

(Users can pose oidless/oidful queries regardless of whether the underlyingKB clauses have OIDs or not)

Static: Generate explicit OID(transform above KB ground atom, use query unchanged):

Undifferentiated (using existential OID variable):Exists ?1 (?1#_work(_Kate _Rho4biz "Director"))

Differentiated (using fresh OID constant):_1#_work(_Kate _Rho4biz "Director")

Dynamic: Virtualize OID with ‘_oidcons’ function and equality ‘=’(keep above KB unchanged, transform query atom):And(_work(?P ?C ?J)

?O=_oidcons(_work ?P ?C ?J))

26 / 49

Describution Transformation

Realizes describution restriction of semantics by replacing everyoidful psoa atom having general form

o#f(+[t+1,1 . . . t+1,n+1] . . . +[t+m+,1 . . . t+m+,n+

m+]

-[t-1,1 . . . t-1,n-1] . . . -[t-m-,1 . . . t-m-,n-m-]

p+1+>v+1 . . . p+k++>v

+k+

p-1->v-1 . . . p-k-->v

-k-)

with the conjunction

And(o#f

o#f(+[t+1,1 . . . t+1,n+1]) . . . o#f(+[t+m+,1 . . . t+m+,n+m+])

o#Top(-[t-m-,1 . . . t-m-,n-m-]) . . . o#Top(-[t-m-,1 . . . t-m-,n-m-])

o#f(p+1+>v+1) . . . o#f(p+k++>v

+k+)

o#Top(p-1->v-1) . . . o#Top(p-k-->v

-k-))

27 / 49

Other Transformation Steps

Skolemization: Eliminates existentially quantified formulas in ruleconclusions by replacing existential variables with Skolem functionapplicationsSubclass transformation

Subclass axiomatization: Adds axiomatization rules to each KBSubclass rewriting (employed for implementation): Replaces eachsubclass formula with a rule

Flattening external expressions: Extracts each embeddedexternal expression as a separate equalityConjunctive conclusion splitting: Splits each rule withconjunctive conclusion into multiple rules

28 / 49

Outline







FOL-Targeting Normalization and Conversion

FOL-targeting normalization: Sequential composition ofunnesting, subclass rewriting, objectification, and descributionConversion from FOL-Normalized PSOA to TPTP:

PSOA/PS Formulas TPTP Formulaso#Top(-[t1...tn]) tupterm(ζ ′(o),ζ ′(t1),...,ζ ′(tn))o#f(+[t1...tn]) prdtupterm(ζ ′(o),ζ ′(f),ζ ′(t1),...,ζ ′(tn))o#Top(p->v) sloterm(ζ ′(o), ζ ′(p), ζ ′(v))o#f(p+>v) prdsloterm(ζ ′(o), ζ ′(f), ζ ′(p), ζ ′(v))

o#c memterm(ζ ′(o),ζ ′(c))

f(+[t1...tn])

{ζ ′(f) n = 0ζ ′(f) (ζ ′(t1) , . . . , ζ ′(tn)) n > 0

And(τ1 . . . τn) (ζ ′(τ1) & ... & ζ ′(τn))Or(τ1 . . . τn) (ζ ′(τ1) | ... | ζ ′(τn))

Exists ?X1 . . .?Xn (τ) ?[ζ ′(X1),...,ζ ′(Xn)]: ζ ′(τ)Forall ?X1 . . .?Xn (τ) ![ζ ′(X1),...,ζ ′(Xn)]: ζ ′(τ)

τ1 :- τ2 ζ ′(τ1) <= ζ ′(τ2)τ1 = τ2 ζ ′(τ1) = ζ ′(τ2)

29 / 49

Outline







LP-Targeting Normalization and Conversion

LP-targeting normalization: FOL-targeting normalization followed bySkolemization, external flattening, and conjunctive conclusion splitting

Conversion from LP-Normalized PSOA to Prolog:PSOA/PS Formulas Prolog Formulas

o#Top(-[t1...tn]) tupterm(ρ′(o),ρ′(t1),...,ρ′(tn))o#f(+[t1...tn]) prdtupterm(ρ′(o),ρ′(f),ρ′(t1),...,ρ′(tn))o#Top(p->v) sloterm(ρ′(o), ρ′(p), ρ′(v))o#f(p+>v) prdsloterm(ρ′(o), ρ′(f), ρ′(p), ρ′(v))

o#c memterm(ρ′(o),ρ′(c))

f(+[t1...tn])

{ρ′(f) n = 0ρ′(f) (ρ′(t1) , . . . , ρ′(tn)) n > 0

τ1 = τ2

{is(ρ′(τ1) , ρ′(τ2)) if τ2 is External(...)’=’(ρ′(τ1) , ρ′(τ2)) otherwise

And(τ1 . . . τn) (ρ′(τ1),...,ρ′(τn))Or(τ1 . . . τn) (ρ′(τ1);...;ρ′(τn))

Exists ?X1 . . .?Xn (τ) ρ′(τ)Forall ?X1 . . .?Xn (τ) ρ′(τ)

External(τ) ρ′(τ)τ1 :- τ2 ρ′(τ1) :- ρ′(τ2)

30 / 49

Outline







Proving Semantics Preservation of Translations

A sufficient condition for proving semantics preservation of PSOAtransformations is givenFor each transformation step, the appropriate PSOA sublanguageis defined and semantics-preservation theorems are provedBased on that, semantics preservation of their compositions isproved for FOL- and LP-targeting normalizations with respect toappropriate sublanguagesFinally, semantics preservation is proved(1) for the PSOA2TPTP translation with respect tothe FOL semantics and(2) for the PSOA2Prolog translation with respect tothe declarative semantics of logic programs

31 / 49

Outline







Outline







Decision Management Challenges

Decision Management (DM) Community has been runningChallenges about decision modeling problems since 2014The DM Challenge of March 2016 consisted of creating decisionmodels from the structured text of English Port Clearance Rules,available onlineIndependently given use case

32 / 49

https://dmcommunity.org/challenge/challenge-march-2016/

Port Clearance Rules

Jacob Feldmanpointed us to thisDM Challenge onThe Game ofRules / PortClearance Rules

Decide whether a ship can entera Dutch port on a certain dateTen English rules inspired by theinternational Ship and Port FacilitySecurity Code, originally developed bySilvie Spreeuwenberg et al. for“The Game of Rules”The English of each one ofthese independently given rulesis moderately controlled,some having a structured ‘if’ partWe formalized the rules inPSOA RuleML, added facts (data)directly in PSOA, queried resultin PSOATransRun, and proposegeneralized decision models

33 / 49

https://dmcommunity.org/challenge/challenge-march-2016/

http://www.buildingbusinesscapability.com/presentations/2015/2200.pdf

Examples of Port Clearance Facts

Since the DM Challenge has introduced only ship rules,we have developed ship facts for systematic testing of rules usingPSOATransRun[PSOA2Prolog,XSBProlog]Examples of ship facts

% Ship 1 - No, registry has expired:ship1#:Ship(:registryExpirationDate->phys:date(2017 5 1)

:totalLength->20:hold->:h1#:ShipHold(:residualCargoMeasurement->0.2

:hull->:single))

% Ship 7 - Yes, hold clean and double-hulled:ship7#:Ship(:registryExpirationDate->phys:date(2020 1 1)

:totalLength->90:hold->:h7#:ShipHold(:residualCargoMeasurement->0.4

:hull->:double))

34 / 49

http://wiki.ruleml.org/index.php/PSOA_RuleML#Prolog_Instantiation

Visualization of PSOA’s Formal Decision Model (1)

An object-relational And-Or DAG with rule names as nodes andconclusion predicates as side labels of nodes

Rule 2

Rule 3

Rule10

Rule 7

MayEnterDutchPortUnloaded

CompliesInspectionRequirementsUnloaded

HasValidCertificate

Rule 9 Rule 4

size

Rule1&5

Rule 8

statusstatus

MeetsSafetyRequirementsUnloadedMeetsSafetyRequirementsUnloaded

small largesize hull

doubleclean

35 / 49

Visualization of PSOA’s Formal Decision Model (2)

For the not side-labeled nodes, the root-class predicate Top isunderstood, while slot names are shown as labels of incomingarcs and top labels of the rule nodes (for the slot name :hull thefiller :double does not require any further rule)The blank, unlabeled node represents the only ‘Or’ branch in thismodel, where Rules 8 and 7 are – operationally speaking –‘pre-invoked’ via the conclusion predicate:MeetsSafetyRequirementsUnloaded, having conditionswith a first conjunct immediately determining whether the slot:size is :small or :large, so that only either Rule 8 or Rule 7,respectively, can be ‘fully invoked’, causing near-deterministicbehaviorThe model is object-relational in that the upper part running to theconclusions of Rules 8 and 7 involves unary relations applied toships while the lower part involves frames with ship OIDsdescribed by slots

36 / 49

Examples of Port Clearance Rules8. A ship only meets the safety requirements for small unloaded ships if the shipcomplies with all of the following: a) the ship is categorized as small;b) the hold of the ship is clean.7. A ship only meets the safety requirements for large unloaded ships if the shipcomplies with all of the following: a) the ship is categorized as large;b) the hold of the ship is clean; c) the hold of the ship is double hulled.

% Object-relational size-switched safety rules check status (small)or status and hull (large)

% Rule 8 (includes disjunct of original Rule 6)Forall ?s ?h (:MeetsSafetyRequirementsUnloaded(?s) :-?s#:Ship(:size->:small

:hold->?h#:ShipHold(:status->:clean)))

% Rule 7 (includes disjunct of original Rule 6)Forall ?s ?h (:MeetsSafetyRequirementsUnloaded(?s) :-?s#:Ship(:size->:large

:hold->?h#:ShipHold(:status->:clean:hull->:double))

)37 / 49

Queries that Answer DM Challenge Questions

Queries for Port Clearance questions are ground, using top-levelpredicate :MayEnterDutchPortUnloaded applied to specificship instances

:MayEnterDutchPortUnloaded(:ship1)No

:MayEnterDutchPortUnloaded(:ship7)Yes

Generalized non-ground query can also be posed:MayEnterDutchPortUnloaded(?w)?w=<http://psoa.ruleml.org/usecases/PortClearance#ship14>?w=<http://psoa.ruleml.org/usecases/PortClearance#ship2>?w=<http://psoa.ruleml.org/usecases/PortClearance#ship12>?w=<http://psoa.ruleml.org/usecases/PortClearance#ship7>?w=<http://psoa.ruleml.org/usecases/PortClearance#ship4>

38 / 49

Outline







Overview of OfficeProspector

Aims to help companies find office suites for theirbusinessesEnriches office-suite data with public (e.g., geospatial) datasets in different modeling paradigms in order to enable userqueries, e.g. for finding office suites based on informationabout building surroundings

39 / 49

Outline







Outline







Comparing PSOA RuleML 1.0 withFlora-2/F-logic and RIF-BLD

PSOA RuleML allows more kinds of atoms and more flexibility inknowledge representation, e.g. dependent-slotted atomsPSOA RuleML supports objectificationFlora-2/F-logic supports more schema-level formulas, e.g. forsignature declarations. In PSOA and RIF-BLD, their usage astop-level KB formulas can be expressed as rulesExpressivity

PSOA RuleML 1.0: Hornlog with existentials and equalityRIF-BLD: Hornlog with equalityFlora-2/F-logic: Hornlog with equality extended by various kinds ofnegations and extra-logicals

40 / 49

Outline







First Experiment

A unit-test suite of test cases with a total of 54 KBs and 302queries, covering all PSOA features that we have implementedEach test case consists of one KB, multiple queries, anduser-provided expected answers to each queryAnswers to each query are obtained from PSOATransRuninstantiations and compared to expected answers automaticallyProlog instantiation passed all test cases, while the TPTPinstantiation passed all test cases except the 11 tests that containexternal built-ins, which cannot be expressed in TPTP-FOF

41 / 49

Second Experiment (1)

Employs (rule-)Chain test cases for exploring performancedifferences between differently modeled KBsFour groups of test cases, each using one of the four major kindsof atoms: dependent-tuple, independent-tuple, dependent-slot,and independent-slotEach group has test cases distinguished by the number k of KBrules and each test case includes one KB and one query of thesame dependency kindIn the dependent-tuple group, each generated KB consists of thefact _r0(_a1 _a2 _a3) (short for _r0(+[_a1 _a2 _a3]))and k rules of the form (i = 1, . . . , k , i ′ = i - 1):Forall ?X1 ?X2 ?X3 (_ri(?X1 ?X2 ?X3):-_ri ′(?X1 ?X2 ?X3)

)

The query is _rk(?X ?Y ?Z), which has one answer?X=_a1 ?Y=_a2 ?Z=_a3

42 / 49


Starting with k = 0 rules and incrementing in steps of 50 rulesuntil reaching k = 500 rules, we generated 11 test cases for eachgroup and measured the average query execution timeFor the dependent-tuple group, we also compared query executiontime between static vs. static/dynamic objectification setupsResults

Figure: Execution time of 11 TupledChain test cases for Prologinstantiation.

Figure: Execution time of 11 SlottedChain test cases for Prologinstantiation.

43 / 49


Results show thatFor descriptors that need to be defined across different predicatesvia different rules, dependent modeling is more efficientFor arguments that often go together (e.g., _a1 _a2 _a3in the Chain tests), tupled modeling is more efficient thanslotted modelingFor dependent-tuple group, static/dynamic objectification fullyretains the efficiency of relational rules, hence is faster than staticobjectificationFor simple test cases, TPTP instantiation is faster because of thecommunication overhead in the Prolog instantiationFor non-simple test cases, Prolog instantiation is faster

44 / 49

Third Experiment

Employs NDChain test cases, which extend each tupled test casein the second experiment with one fact and k Non-DeterministicChain rulesResults are similar to the second experiment except that TPTPinstantiation is faster

45 / 49

Outline







Major Contributions

Revised the PSOA RuleML language, achieving Version 1.0Created an architecture for both interoperating and portingintegrated object-relational knowledgeFormalized and implemented translations, as well as proved theirsemantics preservationCombined the PSOA2TPTP and PSOA2Prolog translatorswith runtime engines into two PSOATransRun instantiationsimplementing PSOARealized use cases and performed evaluation on test cases

46 / 49

Major Contributions – Expanded (1)

Revised the PSOA RuleML language, achieving Version 1.0Introduced independent vs. dependent distinction for descriptorsand defined perspectivity dimension of atomsRevised EBNF syntax and model-theoretic semantics

Created an architecture for both interoperating and portingintegrated object-relational knowledgeFormalized and implemented translations, as well as proved theirsemantics preservation

Formalized and implemented PSOA transformation steps that canbe reused for further PSOA-sourced translationsFollowing up on these, formalized and implemented the translationsfrom PSOA sublanguages to TPTP and to PrologFormalized the translation from an N3 sublanguage, N3Basic, toPSOA and implemented the translation for N3 factsProved semantics preservation of transformation steps,conversions to TPTP and Prolog, as well as their compositions forappropriate sublanguages

47 / 49

Major Contributions – Expanded (2)

Combined the PSOA2TPTP and PSOA2Prolog translatorswith runtime engines into two PSOATransRun instantiationsimplementing PSOA

Download:http://wiki.ruleml.org/index.php/PSOA_RuleML#PSOATransRun

Realized use cases and performed evaluation on test casesApplied PSOA and PSOATransRun to realistic use cases,Port Clearance Rules and OfficeProspectorDeveloped test cases and evaluated the PSOA languageas well as PSOATransRun instantiations through threeexperiments

48 / 49

http://wiki.ruleml.org/index.php/PSOA_RuleML#PSOATransRun

http://wiki.ruleml.org/index.php/PSOA_RuleML#PSOATransRun

Future Work

PSOA RuleML language can be orthogonally expanded to includerelevant features (e.g., NAF) from other rule languagesExtend PSOA2TPTP and PSOA2Prolog translations for PSOAwith conclusion equalitiesStudy and implement (inverse) translators from Prolog and TPTPto PSOA, and from PSOA to N3Further optimize the transformation steps, e.g. dynamicobjectificationFinalize and release schema specification of the PSOA RuleML1.0/XML serialization syntax in Relax NGExtend translators for XML serialization of PSOA RuleMLProof-explanation facility could be added to PSOATransRun,providing visualization, presentation, and serialization formats forqueries derived from facts

49 / 49

Backup Slides

50 / 49

Trade-offs for Realized Architecture

Canonical-language-centered interoperation frameworkAdvantages

Fewer translators needed compared with all-to-all mappingsAllow reuse of modules among translators

Translator-based portation frameworkAdvantage

Rapid prototyping and easier to maintainDisadvantage

Harder to incorporate specific reasoning optimizations

Modularized translator implementationAdvantage

Easier to test, maintain, and reuseDisadvantage

Translators could be less efficient

51 / 49

N3Basic and its Translation to PSOA

We defined a sublanguage of N3, N3Basic, that corresponds to arule language extending RDF with (head-)existential rulesNormalization of N3 transforms the input so that it consists of onlytriples or rules built on top of triplesConversion of normalized N3 to PSOA

Blank nodes are converted to local constants or existentialvariables according to their contextsEach triple is converted to a single-slot frame or a membershipin PSOAN3 rules are converted to PSOA rules

Translation currently implemented for facts (corresponding to theRDF/Turtle language)

52 / 49

N3Basic Exemplified

Example of Fact and Rule: Slot Introduction:b1 :outer1 :canada;

:inner :usa;:outer2 :mexico.

@forAll B,Out,In.{B a :betweenObj;:outer1 Out;:inner In.

} => { Out :neighborSlot In. }

53 / 49

Revision of EBNF for Presentation Syntax

Extends CLAUSE, Implies, and HEAD productions forclosure under objectification and describution transformations(explained later)Reflects use of

oidless and oidful psoa terms as Atoms in/as FORMULAsoidful Atoms (for unnesting, leaving behind the OID term)as TERMs in Atoms and Expressionsoidless psoa terms as Expressions

Refines all descriptors for distinction of Dependent vs.Independent tuples (TUPLEDI) and slots (SLOTDI)

54 / 49

Revised EBNF Grammar: Rule Language

Rule Language:

Document ::= ’Document’ ’(’ Base? Prefix* Import* Group? ’)’Base ::= ’Base’ ’(’ ANGLEBRACKIRI ’)’Prefix ::= ’Prefix’ ’(’ Name ANGLEBRACKIRI ’)’Import ::= ’Import’ ’(’ ANGLEBRACKIRI PROFILE? ’)’Group ::= ’Group’ ’(’ (RULE | Group)* ’)’RULE ::= (’Forall’ Var+ ’(’ CLAUSE ’)’) | CLAUSECLAUSE ::= Implies | HEADImplies ::= HEAD ’:-’ FORMULAHEAD ::= ATOMIC | ’Exists’ Var+ ’(’ HEAD ’)’ | ’And’ ’(’ HEAD* ’)’PROFILE ::= ANGLEBRACKIRI

55 / 49

Revised EBNF Grammar: Condition Language

Condition Language:

FORMULA ::= ’And’ ’(’ FORMULA* ’)’ |’Or’ ’(’ FORMULA* ’)’ |’Exists’ Var+ ’(’ FORMULA ’)’ |ATOMIC |’External’ ’(’ Atom ’)’

ATOMIC ::= Atom | Equal | SubclassAtom ::= ATOMOIDLESS | ATOMOIDFULATOMOIDLESS ::= PSOAOIDLESSATOMOIDFUL ::= PSOAOIDFULEqual ::= TERM ’=’ TERMSubclass ::= TERM ’##’ TERMPSOA ::= PSOAOIDLESS | PSOAOIDFULPSOAOIDLESS ::= TERM ’(’ (TERM* | TUPLEDI*) SLOTDI* ’)’PSOAOIDFUL ::= TERM ’#’ PSOAOIDLESSTUPLEDI ::= (’+’ | ’-’) ’[’ TERM* ’]’SLOTDI ::= TERM (’+>’ | ’->’) TERMTERM ::= Const | Var | ATOMOIDFUL | Expr | ’External’ ’(’ Expr ’)’Expr ::= PSOAOIDLESS...

56 / 49

OfficeProspector Partonomy-Taxonomy

SpaceNeighborhood|_ Building

|_ Suite|_ Office

ClosedOfficeCubicleOpenOffice

|_ MeetingSpaceClosedMeetingSpaceOpenMeetingSpace

|_ KitchenClosedKitchenOpenKitchen

|_ Reception|_ Room

ClosedOfficeClosedMeetingSpaceClosedKitchen

|_ OpenSpace...

57 / 49

OfficeProspector Data Sets

Internal data set: Generated data of offices and buildingsExternal data sets

Relational data set containing information of Toronto’s 140neighborboodsRelational data set containing coordinates of addresses in WGS84geodetic longitude-latitude spatial reference system used by theGlobal Positioning SystemAn object-centered data set in N3 syntax containing information ofamenities in Toronto, extracted from LinkedGeoData

58 / 49

OfficeProspector Rules

Object(-relational) integration rules using knowledge enrichmentObject-centered vocabulary-extension rulesOther object(-relational) rules, e.g. for matching constraints inqueries and for converting measures

59 / 49

OfficeProspector Example QueryFind any suite ?s that satisfies the following:1) the monthly rent of ?s is at most 5000 CAD;2) the HVAC system of ?s has a rating of at least basic;3) ?s has Internet.4) ?s is a part of a building ?b that satisfies:4.1) the distance to the nearest public transport of ?b is at most 1000 meters;4.2) the completion year of ?b is at least 1985And(?s#:Suite(:constrain(:monthlyRent)->:atmost(:measure(5000 :cad)):constrain(:hvac)->op-rtg:atleast(op-rtg:basic):utility->:internet:partOf->?b

)?b#:Building(:constrain(:publicTransAccessDistance)->

:atmost(:measure(1000 :m)):constrain(:yearBuilt)->:atleast(1985)

))

60 / 49

Documents

Translators for Interoperating and Porting Object-Relational …ruleml.org/talks/GenZou-TransInterPortObjRelKnowledge... · 2018. 4. 20. · neighborRel(Outer1,Inner) ( betweenRel(Outer1,Inner,Outer2)