1 / 30

PathLP – Path-based Logic Programming

PathLP is a compact logic programming language inspired by object-oriented logic programming languages. It supports reasoning over guarded path expressions and typing notions like hierarchy and membership, aiming for formal support in Model-Level Integrated Development Environments. PathLP enables users to verify UML diagrams, specify design patterns, and perform model refactoring. With constructs including path expressions, facts, rules, and constraints, PathLP facilitates advanced modeling and reasoning tasks. It allows for the creation of object path expressions and query formulas, incorporating cardinality constraints for precise modeling. Developed by Mira Balaban, Igal Khitron, and Michael Kifer, PathLP is a valuable tool for enhancing the efficiency and accuracy of modeling processes.

tolson
Download Presentation

PathLP – Path-based Logic Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PathLP – Path-based Logic Programming Mira Balaban, IgalKhitron Computer Science Department Ben-Gurion University Mini-project-course Fall 2013

  2. PathLP • A compact logic programminglanguage • Inspired from • Object-Oriented Logic Programming languages: • F-Logic (Kifer, Lausen, Wu 1995) • FLORA-2 (http://flora.sourceforge.net/, 2009) • Object-Oriented databaseandwebquery languages : • XSQL(Kifer, Kim, Sagiv 1992) • XPATH – a query language over XML documents (http://www.w3schools.com/xpath/). • Supports reasoning over guarded path expressions • Supports typing notions: • Hierarchy • Membership Mini-project-course Fall 2013

  3. PathLP status • PathLP is still under development by Mira Balaban, Igal Khitron, Michael Kifer (alphabetical order). • Intended for: • Formal support for Model-Level Integrated Development Environments: • Simultaneous reasoning over multiple models • Reasoning over applications that support hierarchical structures, like • Access policy in Network Management • Publications: • Mira Balaban and Michael Kifer: "An Overview of F-OML: An F-Logic Based Object Modeling Language", ECEASST'11 36. • Mira Balaban and Michael Kifer: "Logic Based Model-Level Software Development with F-OML", MoDELS'2011. • IgalKhitron, Michael Kifer, Mira Balaban: “PathLP: A Logic Programming Language of Path Expressions”, PLDE 2012. • Application: Version 1.4 PathLP1.4 Mini-project-course Fall 2013

  4. Model-level IDE – Needed modeling services • Provide a modeling constraint language for extending UML diagrams: • Object Constraint Language (OCL) • PathLP • Verification of UML diagrams • Specification of design patterns. • Reasoning about UML diagrams • TestingUML diagrams • Model refactoring • Meta-modeling: • DSML specification • Formalize UML specification Mini-project-course Fall 2013

  5. Model-level IDE – Integration with a modeling platform • Diagrammatic models • concrete external syntax. UML development platform model1 … modeln transformations model1-module … modeln-module Underlying formal modeling language Modeling services Mini-project-course Fall 2013

  6. Model-level IDE – Integration with a modeling platform • Diagrammatic models • concrete external syntax. UML development platform model1 … modeln transformations model1-module … modeln-module F-OML PathLP Modeling services Mini-project-course Fall 2013

  7. PathLP constructs • Path expressions • Facts • Rules • Constraints • Queries Mini-project-course Fall 2013

  8. PathLP: Object path expressions • Consist of constants, variables, ., guards • Denote objects ?C.friend.student[?S].name • The names of a student s of a friend of c, for some bindings s and c to variables ?S and ?C constant guard variable name student s friend … name student … friend c … student denotation Mini-project-course Fall 2013

  9. PathLP: Object path expressions & Query formulas elementary formula • Query formula: John.childWith(Mary)[?C].name[?N], ?C:Student,?C.ageAt(2010)<20 • The name ?N of ?C, who is a child with Mary of John, is a student and whose age at 2010 is less than 20 elementary formula elementary formula name … ?N childWith(Mary) ?C denotation name … John ageAt(2010) Student n<20 Mini-project-course Fall 2013

  10. PathLP: Type path expressions Cardinality constraint Person!spouse[Person]{0..1} • The type of spouses of nodes of type Person (nodes pointed by spouse edges) is Person (or a subtype of Person), and there is at most 1 such edge • Assume • ?n1.spouse[?n2] ?n2 spouse ?n1 Mini-project-course Fall 2013

  11. PathLP: Type path expressions Person!spouse[Person]{0..1} • The type of spouses of nodes of type Person is Person (or a subtype of Person), and there is at most 1 such edge • Assume • ?n1.spouse[?n2] • ?n1:Person Person ?n2 spouse ?n1 Mini-project-course Fall 2013

  12. PathLP: Type path expressions Person!spouse[Person]{0..1} • The type of spouses of nodes of type Person is Person (or a subtype of Person), and there is at most 1 such edge • Assume • ?n1.spouse[?n2] • ?n1:Person  ?n2:Person Person ?n2 spouse ?n1 and IF THEN at most 1 spouse edge Mini-project-course Fall 2013

  13. PathLP: Type path expressions Person!spouse[Person]{0..1} • The type of spouses of nodes of type Person is Person (or a subtype of Person), and there is at most 1 such edge • Assume • ?n1.spouse[?n2] • ?n1:Person  ?n2:Person spouse spouse Type edge Person … ?n2 spouse ?n1 and IF THEN at most 1 spouse edge Mini-project-course Fall 2013

  14. PathLP: Facts – specify assertions • John.spouse[Mary]; John.child[Bob]; John.child[Bill]; • John has a spouseMary and children Bob and Bill (and possibly others) • Type hierarchyand membership assertions: Bob:CS_teaching_committee; CS_teaching_committee::Teaching_committee; Teaching_committee:Committee; Committee::Group; • Bob CS_teaching_committeeTeaching_committee Committee Group • A type assertion:Person!spouse[Person]{0..1}; • The type of spouses of Person is Person, or one of its subtypes, and the cardinality constraint is {0..1} Mini-project-course Fall 2013

  15. PathLP: Rules, Constraints, Queries • Rules – specify implications: • ?A:advisor :- ?T:Thesis, ?T.author.advisor[?A].read[?T],?A:Professor; • ?A is an advisor if ?A has read a thesis ?T of an author that ?A advises • Constraints – restrict legal states: • !- ?P:Professor, not ?P.degree[PhD]; • forbid states with a professor ?P that does not have a PhD degree • Queries – trigger computation • ?- ?A:Professor, ?A.review[?Thesis], ?A.supervise.thesis-of[?Thesis]; • Find aprofessor that reviews a thesis of somebody s/he supervises. A more compact expression: ?- ?A:Professor,?A.review.author.advisor[?A]; Mini-project-course Fall 2013

  16. PathLP – as a basis for Object-Oriented modeling • Defines entities: • Inter-related by paths • Possiblytyped • inclusion “::” • membership“:” • Multi-levelmodeling: • Unrestricted “::“ and “:“ • Polymorphism: • Parameterized path expressions • Type hierarchy Object navigation Class Class hierarchy Object creation; Testing Reflection • Patterns • Model query • Static analysis Mini-project-course Fall 2013

  17. PathLP – implementation • Beta version 1.4: • pathlp.sf.net (IgalKhitron) • Compiler and interpreter • In XSB prolog • open source tabling prolog • supports well-founded negation • Windows, Linux, Unix • Large test cases: 200,000 facts Mini-project-course Fall 2013

  18. Mini-Project subject – Develop a Graph Services library in PathLP • An example library: JGraphT From the JGraphT home page: • JGraphT is a free Java graph library that provides mathematical graph-theory objects and algorithms. JGraphT supports various types of graphs including: • directed and undirected graphs. • graphs with weighted / unweighted / labeled or any user-defined edges. • various edge multiplicity options, including: simple-graphs, multigraphs, pseudographs. • unmodifiable graphs - allow modules to provide "read-only" access to internal graphs. • listenable graphs - allow external listeners to track modification events. • subgraphs graphs that are auto-updating subgraph views on other graphs. • all compositions of above graphs. • Although powerful, JGraphT is designed to be simple and type-safe (via Java generics). For example, graph vertices can be of any objects. You can create graphs based on: Strings, URLs, XML documents, etc; you can even create graphs of graphs! This code example shows how. Mini-project-course Fall 2013

  19. Mini-Project subject – Develop a Graph Services library in PathLP • Why having “yet another JGraphT” in PathLP? Mini-project-course Fall 2013

  20. Mini-Project subject – Develop a Graph Service library in PathLP • Why having “yet another JGraphT” in PathLP? • What are the special features of Logic Programming languages? • Reasoning! • Answer queries! • Analysis! Mini-project-course Fall 2013

  21. Graph representation in PathLP • Directed graph: • Facts: n1.edge[n2]; n1.edge[n3]; n1.edge[n4]; n2.edge[n3]; n2.edge[n5]; n4.edge[n2]; n4.edge[n4]; n5.edge[n2]; n5.edge[n4]; n2 n1 n4 n3 ?n5 n5 Mini-project-course Fall 2013

  22. Querying the directed graph • Directed graph: • Facts: n1.edge[n2]; n1.edge[n3]; n1.edge[n4]; n2.edge[n3]; n2.edge[n5]; n4.edge[n2]; n4.edge[n4]; n5.edge[n2]; n5.edge[n4]; • Queries: ?- n1.edge[?N]; ?- ?N1.edge[?N2]; ?- ?N1.edge[?_N2],?_N2.edge[?N1]; ?- ?n.edge[?n]; ?- not n1.edge[n2]; ?- ?N._size(edge)[?edge_number],?edge_number<2; n2 n1 n4 n3 ?n5 n5 Mini-project-course Fall 2013

  23. Reasoning about the directed graph • Paths in the directed graph: • Rules: ?n1.path[?n2]:- ?n1.edge[?n2]; ?n1.path[?n2]:- ?n1.path[?n3],?n3.edge[?n2]; • Facts: n1.edge[n3]; n4.edge[n2]; n1.edge[n4]; n4.edge[n4]; n2.edge[n3]; n5.edge[n2]; n2.edge[n5]; n5.edge[n4]; • Queries: ?- n5.path[n5]; ?- ?N.path[n5]; ?- ?N.path[n5],?N != n5; ?- ?n.path[?n]; ?- not(n1.path[n1]); ?- n1.path[?N],not(?N.path[?N]); • Rule:?n.selfPath[true]:- ?n.path[?n]; • Query:?- ?N._size(selfpath)[?path_num],?path_num>1; n2 n1 n4 n3 ?n5 n5 Mini-project-course Fall 2013

  24. Reasoning about the directed graph • Adding path details and node typing: • Rules: ?N1.path([?N1,?N2])[?N2]:- ?N1.edge[?N2]; ?N1.path([?N1|?P])[?N3]:- ?N1.edge[?N2],?N2.path(?P)[?N3]; ?N1.loop[?N2]:- ?N1.edge[?N2],?N2.edge[?N1]; ?N.origin[true]:- ?N:Node,not ?N.enter_edge[true]; ?N.enter_edge[true]:- ?N1.edge[?N]; ?N.sink[true]:- ?N:Node,not ?N.leaving_edge[true]; ?N.leaving_edge[true]:- ?N.edge[?N1]; isolated(?N)[true] :- origin(?N)[true],sink(?N)[true]; • Facts: n1:Node; n2:Node; n3:Node; n4:Node; n5:Node; n6:Node; n1.edge[n3]; n4.edge[n2]; n1.edge[n4]; n4.edge[n4]; n2.edge[n3]; n5.edge[n2]; n2.edge[n5]; n5.edge[n4]; • Queries: ?- n5.path(?P)[n5]; ?- ?N.path(?P)[n5]; ?- ?N.path(?_P)[n5]; is the same as ?- ?N.path[n5]; ?- ?N.path(?_P)[n5],not ?_P.member[n4]; ?- ?N.loop[n5]; ?- ?N1.origin[true],?N2.origin[true],?N1!=?N2; ?- ?_N.isolated[true]); n2 n1 n4 n3 ?n5 n5 n6 Mini-project-course Fall 2013

  25. Reasoning about the directed graph • Adding labeled edges, edge typing, path typing: • Rules: ?P:Path :-?N1.path(?P)[?N2]; % Bad modeling! Why? ?P.nodes[?P] :- ?P:Path,?N1.path(?P)[?N2]; ?P.node[?N] :- ?P.nodes[?Node_list],?Node_list.member[?N]; ?E:Edge :- ?N1.edge(?E)[?N2]; ?E.source[?N] :- ?E:Edge,?N.edge(?E)[?N1]; • Facts: n1:Node; n2:Node; n3:Node; n4:Node; n5:Node; n6:Node; n1.edge[n3]; n4.edge[n2]; n1.edge[n4]; n4.edge[n4]; n2.edge[n3]; n5.edge[n2]; n2.edge[n5]; n5.edge(e54)[n4]; • Note the different design decision about the status of nodes and edges: • Node typing is mandatory • Edge typing is inferred n2 n1 n4 n3 ?n5 n5 e54 n6 Mini-project-course Fall 2013

  26. Reasoning about the directed graph • Improved path modeling: • Rules: path(?node_list):Path :-?N1.path(?node_list)[?N2]; path(?node_list).nodes[?node_list] :-?N1.path(?node_list)[?N2]; ?P.node[?N] :- ?P.nodes[?Node_list], ?Node_list.member[?N]; ?P.first[?N] :- ?P:Path, ?P.nodes[ [?N|?rest_nodes] ]; ?P.last[?N] :- ?P:Path, ?P.nodes[?node_list], ?node_list.reverse[[?N|?rest_nodes]]; • Constraints: !- ?P:Path, ?P.first[?N1], ?P.last[?N2], ?P.nodes[?node_list], not ?N1.path(?node_list)[?N2]; • Facts: n1:Node; n2:Node; n3:Node; n4:Node; n5:Node; n6:Node; n1.edge[n3]; n4.edge[n2]; n1.edge[n4]; n4.edge[n4]; n2.edge[n3]; n5.edge[n2]; n2.edge[n5]; n5.edge(e54)[n4]; n2 n1 n4 n3 ?n5 n5 e54 n6 Mini-project-course Fall 2013

  27. Reasoning about the directed graph • Adding more constraints: • Rules: path(?node_list):Path :-?N1.path(?node_list)[?N2]; path(?node_list).nodes[?node_list] :-?N1.path(?node_list)[?N2]; ?E:Edge :- ?N1.edge(?E)[?N2]; ?E.source[?N] :- ?E:Edge,?N.edge(?E)[?N1]; • Constraint: !- ?E.source[?N1],?E.source[?N2], ?N1!=?N2; !- ?N1.path(?P)[?N2], ?P.member[?N],not ?N:Node; A single labeled edge between nodes: !- ?N1.edge(?L1)[?N2], ?N1.edge(?L2)[?N2], ?L1 != ?L2; A single labeled edge leaving a node: !- Node!edge(?L)[Node]{0..1}; n2 n1 n4 n3 ?n5 n5 e54 n6 Mini-project-course Fall 2013

  28. Reasoning about the directed graph • Adding path properties and sub-typing: • Rules: path(?node_list):Compact_Path :- path(?node_list):Path, ?node_list.compactList[true]; ?List.compactList[true] :- not ?L1.append([?N],?L2,[?N],?L3)[?List]; ?P:Cycle :- ?P:Path,?P.first[?N],?P.last[?N]; path(?node_list).length[?number] :- ?node_list.length[?number]; Compact_Path :: Path; Cycle :: Path; • Constraints: !- path(?node_list):Compact_Path, not ?node_list.compactList[true]; !- ?P:Cycle, ?P.first[?N1], ?P.last[?N2], ?N1 != ?N2; n2 n1 n4 n3 ?n5 n5 e54 n6 Mini-project-course Fall 2013

  29. Reasoning about the directed graph • Adding multiple graphs: • Rules: ?G.node[?N] :-?G.nodes[?Node_list],?Node_list.member[?N]; ?N.graph[?G] :-?G.node[?N]; ?G1.intersection(?G2)[?G] :- ?G1.nodes[?Ns1],?G2.nodes[?Ns2], ?G1.edges[?Es1],?G2.edges[?Es2], ?Ns1.intersection(?Ns2)[?Ns], ?Es1.intersection(?Es2)[?Es], ?G:Directed_graph,?G.nodes[?Ns],?G.edges[?Es]; ?G.is_empty[true] :- ?G:Directed_graph,?G.nodes[ [] ]; ?G1.disjoint[?G2] :- ?G1.intersection(?G2)[?G], ?G.is_empty[true]; ?G.path[?P]:- ?P.nodes[?Nodes_P],?G.nodes[?Nodes_G], ?Nodes_G.contains[?Nodes_P]; ?G:Cyclic_directed_graph :- ?G.path[?P],?P:Cycle; ?G:DAG :- not ?G:Cyclic_directed_graph; • A different modeling approach – using functional constructors: intersection(?G1,?G2):Directed_graph :- ?G1:Directed_graph,?G2:Directed_graph; intersection(?G1,?G2).nodes[intersection(?Ns1,?Ns2)] :- ?G1.nodes[?Ns1],?G2.nodes[?Ns2]; • A type Constraint: Directed_graph!nodes[List]{1..1}; • Facts: g1:Directed_graph; g1.nodes[[n1,n2,n3,n4,n5,n6]]; g1.edges[[e12,e13,e14,e25,e52,e23,e42,e44]]; ?n5 Mini-project-course Fall 2013

  30. Mini-project-course Fall 2013

More Related