DOCSLIB.ORG

Deductive Graph Database – Datalog in Action

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Deductive Graph Database – Datalog in Action 2015 International Conference on Computational Science and Computational Intelligence Deductive Graph Database – Datalog in Action Kornelije Rabuzin Faculty of organization and informatics University of Zagreb Varazdin, Croatia [email protected] Abstract—In recent years many NoSQL systems, including • Document oriented databases graph databases, have become available. For large amounts of interconnected data, these systems represent a good choice. • Column oriented databases Deductive databases have been used in order to deduce new • Key value databases pieces of information based on a database that containes large amounts of data. But it is important to keep in mind that such • Graph databases databases were mostly relational, i.e., relations were used to store data upon which deductive mechanisms were used. In this paper, Graph databases store information in nodes and deductive graph databases are proposed. In deductive graph relationships. Each node does not have to contain the same databases, data are stored in a graph database, and Datalog is number of properties (attributes) and the same applies for used for reasoning purposes on a relational representation of a relationships between the nodes. For large amounts of graph database. interconnected data graph databases represent a good choice. They are especially suitable for social network analysis. In the Keywords—databases, SQL, NoSQL, graph databases, Datalog next chapter a small graph database is implemented (Neo4j system is used) and more about graph databases will be I. INTRODUCTION discussed. For additional information on graph databases see [6]. In this paper, we primarily discuss graph databases (other The relational data model has been widely used in the past types are not discussed). 40 years. Many databases were implemented in order to store large amounts of important data. As it turns out, Dr. Codd’s A deductive database uses rules to produce new pieces of vision to store data into relations turned out to be crucial and, knowledge based on facts, which are stored in the database. because of its ideal properties, the relational data model has The next definition can be found in [11]: “A deductive DBD is survived. Although the term “relation” is used in the theory, a triple D = (F, DR, IC), where F is a finite set of ground facts, users that use databases on a daily basis usually claim that a DR a finite set of deductive rules, and IC a finite set of database is, in fact, a set of tables. In order to implement a integrity constraints. The set F of facts is called the extensional database, certain database management systems (DBMS) are part of the DB (EDB), and the sets DR and IC together form required. The rich query interface (Structured Query Language the so-called intensional part (IDB)”. A small example is – SQL) that DBMS supports can be used to work with borrowed from [11]: databases. The ability to store and efficiently manage large amounts of data has turned database management systems into Facts significant parts of many applications and information systems Father(John, Tony) that were developed over the time. Mother(Mary, Bob) SQL is a standardized language that is used to work with databases. All database management system vendors support Father(Peter, Mary) SQL which is declarative and typically, not complex. However, sometimes queries do get quite complex. Furthermore, different databases management systems do not support all the Deductive Rules statements in the same form and some differences may exist. ← For more information on SQL, see [8] and [9]. Parent(x,y) Father(x,y) But, in recent years, the NoSQL movement has become Parent(x,y) ← Mother(x,y) popular. Namely, the relational data model is starting to reveal its weaknesses, and, for some problems, new solutions have to GrandMother(x,y) ← Mother(x,z) ∧ Parent(z,y) be found. The amounts of data that relational databases have to ← store today are beyond their capabilities. Furthermore, a fixed Ancestor(x,y) Parent(x,y) database schema is no longer an option. Because of this, many Ancestor(x,y) ← Parent(x,z) ∧ Ancestor(z,y) NoSQL systems have been developed, and, generally speaking, we distinguish: Nondirect-anc(x,y) ← Ancestor(x,y) ∧ ¬Parent(x,y) 978-1-4673-9795-7/15 $31.00 © 2015 IEEE 114 DOI 10.1109/CSCI.2015.60 Integrity Constraints IC1(x) ← Parent(x,x) IC2(x) ← Father(x,y) ∧ Mother(x,z) Thus, there are three facts and several rules used to define different relationships (parent, grandmother, etc.). Two integrity constraints prevent someone from being parent of his self and preventing a person from being both mother and father at the same time. For more information on deductive databases see [11] or [14]. However, some things that initially occurred in deductive databases are used in SQL today: for example, recursive queries. Some books that cover databases in general are [1], [2], [3], [5] and [12]; other book are available as well. In the next section if this paper, graph databases are defined. Then the Deductive Graph Database is presented and a few Datalog queries are written. Afterward, the discussion is given and the conclusion is presented. Figure 1. Graph database This example stores data about courses and their II. GRAPH DATABASES prerequisites. To list courses and their prerequisites (first level), it is enough to read the graph database. Cypher is used Unlike relational databases, which store data in tables, as a language to read the data from the database. MATCH graph databases use nodes and relationships between nodes. clause is used to start the query; it finds two courses that are Storing data in such a way has certain benefits and it is more connected by means of a relationship, which is called PREREQ natural for large amounts of interconnected data (for example, and then their names are returned in the result: social network analysis). Thus, one cannot say that graph databases are always better or that relational databases are MATCH (n:Course)-[:PREREQ]->(m:Course) always better; it depends on one’s needs. RETURN n.name, m.name Nodes and relationships have properties. In the next n.name m.name section, we define a small graph database (the Neo4j system is used for implementation purposes): Mathematics Programming I CREATE (p1:Course {name: "Mathematics", ects: 7}), Mathematics Databases I (p2:Course {name: "Informatics"}), Informatics Databases I (p3:Course {name: "Programming I", ects: 7}), Databases I Databases II (p4:Course {name: "Databases I"}), Databases II Data warehouses I (p5:Course {name: "Databases II", ects: 6}), (p6:Course {name: "Data warehouses I", ects: 5}), On the second level (as well as on any other level), it is enough to reread the graph database. Now we are looking for (p1)-[:PREREQ]->(p3), three nodes and two relationships between them: (p1)-[:PREREQ]->(p4), MATCH (n:Course)-[:PREREQ]->(m:Course)- (p2)-[:PREREQ]->(p4), [:PREREQ]->(o:Course) (p4)-[:PREREQ]->(p5), RETURN n.name, o.name (p5)-[:PREREQ]->(p6) n.name o.name Mathematics Databases II The visual interpretation of the database defined above is Informatics Databases II shown below: Databases I Data warehouses I Now we are looking for four nodes and three relationships between them: 115 MATCH (n:Course)-[:PREREQ]->(m:Course)- course(mathematics, 7). [:PREREQ]->(o:Course)-[:PREREQ]->(p:Course) course(informatics, null). RETURN n.name, p.name course('programming I', 7). n.name p.name course('databases I', null). Mathematics Data warehouses I course('databases II', 6). Informatics Data warehouses I course('data warehouses I', 5). The first problem is that no recursion is supported in Neo4j and we have the same problem as in SQL before the recursion However, one has to keep in mind that nodes do not have to was added into the SQL standard. In order to merge all the have the same properties. Here, we see that not all courses have queries (listed above) and to find all courses and their the number of ECTS points and, because of that, null is used. prerequisites, we should use the UNION clause (the result is Relationships are stored as facts as well: obvious): prereq(mathematics, 'programming I'). MATCH (n:Course)-[:PREREQ]->(m:Course) prereq(mathematics, 'databases I'). RETURN n.name AS c, m.name AS p prereq(informatics, 'databases I'). UNION prereq('databases I', 'databases II'). MATCH (n:Course)-[:PREREQ]->(m:Course)- prereq('databases II', 'data warehouses I'). [:PREREQ]->(o:Course) RETURN n.name AS c, o.name AS p Regarding the translation, one may ask why perform the UNION translation at all? But the answer may be surprising. Namely, MATCH (n:Course)-[:PREREQ]->(m:Course)- graph databases use different methods to store data [6]: [:PREREQ]->(o:Course)-[:PREREQ]->(p:Course) “Some graph databases use native graph storage that is RETURN n.name AS c, p.name AS p optimized and designed for storing and managing graphs. Not all graph database technologies use native graph storage however. Some serialize the graph data into a relational database, an object-oriented database, or some other general- Recursive queries are supported in Datalog (deductive purpose data store.” databases), however, and we could use them on a graph database in order to more easily find courses and their Thus, we see that the underlying storage model can rely on prerequisites. Deductive databases also provide views. One can relational databases as well as on some other types, but this define a view; in this way, queries may be posed much easier. underpins the idea of translating the graph database into a set of Furthermore, hypothetical queries are supported in Datalog as facts that can be stored in tables in order to use Datalog on such well. Because we see that Cypher has certain problems while a database.
Load more

Recommended publications
  • Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects
    Empirical Study on the Usage of Graph Query Languages in Open Source Java Projects Philipp Seifer Johannes Härtel Martin Leinberger University of Koblenz-Landau University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Software Languages Team Institute WeST Koblenz, Germany Koblenz, Germany Koblenz, Germany [email protected] [email protected] [email protected] Ralf Lämmel Steffen Staab University of Koblenz-Landau University of Koblenz-Landau Software Languages Team Koblenz, Germany Koblenz, Germany University of Southampton [email protected] Southampton, United Kingdom [email protected] Abstract including project and domain specific ones. Common applica- Graph data models are interesting in various domains, in tion domains are management systems and data visualization part because of the intuitiveness and flexibility they offer tools. compared to relational models. Specialized query languages, CCS Concepts • General and reference → Empirical such as Cypher for property graphs or SPARQL for RDF, studies; • Information systems → Query languages; • facilitate their use. In this paper, we present an empirical Software and its engineering → Software libraries and study on the usage of graph-based query languages in open- repositories. source Java projects on GitHub. We investigate the usage of SPARQL, Cypher, Gremlin and GraphQL in terms of popular- Keywords Empirical Study, GitHub, Graphs, Query Lan- ity and their development over time. We select repositories guages, SPARQL, Cypher, Gremlin, GraphQL based on dependencies related to these technologies and ACM Reference Format: employ various popularity and source-code based filters and Philipp Seifer, Johannes Härtel, Martin Leinberger, Ralf Lämmel, ranking features for a targeted selection of projects.
    [Show full text]
  • A Fuzzy Datalog Deductive Database System 1
    A FUZZY DATALOG DEDUCTIVE DATABASE SYSTEM 1 A Fuzzy Datalog Deductive Database System Pascual Julian-Iranzo,´ Fernando Saenz-P´ erez´ Abstract—This paper describes a proposal for a deduc- particular, non-logic constructors are disallowed, as the cut), tive database system with fuzzy Datalog as its query lan- but it is not Turing-complete as it is meant as a database query guage. Concepts supporting the fuzzy logic programming sys- language. tem Bousi∼Prolog are tailored to the needs of the deductive database system DES. We develop a version of fuzzy Datalog Fuzzy Datalog [9] is an extension of Datalog-like languages where programs and queries are compiled to the DES core using lower bounds of uncertainty degrees in facts and rules. Datalog language. Weak unification and weak SLD resolution are Akin proposals as [10], [11] explicitly include the computation adapted for this setting, and extended to allow rules with truth de- of the rule degree, as well as an additional argument to gree annotations. We provide a public implementation in Prolog represent this degree. However, and similar to Bousi∼Prolog, which is open-source, multiplatform, portable, and in-memory, featuring a graphical user interface. A distinctive feature of this we are interested in removing this burden from the user system is that, unlike others, we have formally demonstrated with an automatic rule transformation that elides both the that our implementation techniques fit the proposed operational degree argument and the explicit call to fuzzy connective semantics. We also study the efficiency of these implementation computations in user rules. In addition, we provide support for techniques through a series of detailed experiments.
    [Show full text]
  • Dedalus: Datalog in Time and Space
    Dedalus: Datalog in Time and Space Peter Alvaro1, William R. Marczak1, Neil Conway1, Joseph M. Hellerstein1, David Maier2, and Russell Sears3 1 University of California, Berkeley {palvaro,wrm,nrc,hellerstein}@cs.berkeley.edu 2 Portland State University [email protected] 3 Yahoo! Research [email protected] Abstract. Recent research has explored using Datalog-based languages to ex- press a distributed system as a set of logical invariants. Two properties of dis- tributed systems proved difficult to model in Datalog. First, the state of any such system evolves with its execution. Second, deductions in these systems may be arbitrarily delayed, dropped, or reordered by the unreliable network links they must traverse. Previous efforts addressed the former by extending Datalog to in- clude updates, key constraints, persistence and events, and the latter by assuming ordered and reliable delivery while ignoring delay. These details have a semantics outside Datalog, which increases the complexity of the language and its interpre- tation, and forces programmers to think operationally. We argue that the missing component from these previous languages is a notion of time. In this paper we present Dedalus, a foundation language for programming and reasoning about distributed systems. Dedalus reduces to a subset of Datalog with negation, aggregate functions, successor and choice, and adds an explicit notion of logical time to the language. We show that Dedalus provides a declarative foundation for the two signature features of distributed systems: mutable state, and asynchronous processing and communication. Given these two features, we address two important properties of programs in a domain-specific manner: a no- tion of safety appropriate to non-terminating computations, and stratified mono- tonic reasoning with negation over time.
    [Show full text]
  • A Comparison Between Cypher and Conjunctive Queries
    A comparison between Cypher and conjunctive queries Jaime Castro and Adri´anSoto Pontificia Universidad Cat´olicade Chile, Santiago, Chile 1 Introduction Graph databases are one of the most popular type of NoSQL databases [2]. Those databases are specially useful to store data with many relations among the entities, like social networks, provenance datasets or any kind of linked data. One way to store graphs is property graphs, which is a type of graph where nodes and edges can have attributes [1]. A popular graph database system is Neo4j [4]. Neo4j is used in production by many companies, like Cisco, Walmart and Ebay [4]. The data model is like a property graph but with small differences. Its query language is Cypher. The expressive power is not known because currently Cypher does not have a for- mal definition. Although there is not a standard for querying graph databases, this paper proposes a comparison between Cypher, because of the popularity of Neo4j, and conjunctive queries which are arguably the most popular language used for pattern matching. 1.1 Preliminaries Graph Databases. Graphs can be used to store data. The nodes represent objects in a domain of interest and edges represent relationships between these objects. We assume familiarity with property graphs [1]. Neo4j graphs are stored as property graphs, but the nodes can have zero or more labels, and edges have exactly one type (and not a label). Now we present the model we work with. A Neo4j graph G is a tuple (V; E; ρ, Λ, τ; Σ) where: 1. V is a finite set of nodes, and E is a finite set of edges such that V \ E = ;.
    [Show full text]
  • Introduction to Graph Database with Cypher & Neo4j
    Introduction to Graph Database with Cypher & Neo4j Zeyuan Hu April. 19th 2021 Austin, TX History • Lots of logical data models have been proposed in the history of DBMS • Hierarchical (IMS), Network (CODASYL), Relational, etc • What Goes Around Comes Around • Graph database uses data models that are “spiritual successors” of Network data model that is popular in 1970’s. • CODASYL = Committee on Data Systems Languages Supplier (sno, sname, scity) Supply (qty, price) Part (pno, pname, psize, pcolor) supplies supplied_by Edge-labelled Graph • We assign labels to edges that indicate the different types of relationships between nodes • Nodes = {Steve Carell, The Office, B.J. Novak} • Edges = {(Steve Carell, acts_in, The Office), (B.J. Novak, produces, The Office), (B.J. Novak, acts_in, The Office)} • Basis of Resource Description Framework (RDF) aka. “Triplestore” The Property Graph Model • Extends Edge-labelled Graph with labels • Both edges and nodes can be labelled with a set of property-value pairs attributes directly to each edge or node. • The Office crew graph • Node �" has node label Person with attributes: <name, Steve Carell>, <gender, male> • Edge �" has edge label acts_in with attributes: <role, Michael G. Scott>, <ref, WiKipedia> Property Graph v.s. Edge-labelled Graph • Having node labels as part of the model can offer a more direct abstraction that is easier for users to query and understand • Steve Carell and B.J. Novak can be labelled as Person • Suitable for scenarios where various new types of meta-information may regularly
    [Show full text]
  • Handling Scalable Approximate Queries Over Nosql Graph Databases: Cypherf and the Fuzzy4s Framework
    Castelltort, A. , & Martin, T. (2017). Handling scalable approximate queries over NoSQL graph databases: Cypherf and the Fuzzy4S framework. Fuzzy Sets and Systems. https://doi.org/10.1016/j.fss.2017.08.002 Peer reviewed version License (if available): CC BY-NC-ND Link to published version (if available): 10.1016/j.fss.2017.08.002 Link to publication record in Explore Bristol Research PDF-document This is the author accepted manuscript (AAM). The final published version (version of record) is available online via Elsevier at https://www.sciencedirect.com/science/article/pii/S0165011417303093?via%3Dihub . Please refer to any applicable terms of use of the publisher. University of Bristol - Explore Bristol Research General rights This document is made available in accordance with publisher policies. Please cite only the published version using the reference above. Full terms of use are available: http://www.bristol.ac.uk/pure/about/ebr-terms *Manuscript 1 2 3 4 5 6 7 8 9 Handling Scalable Approximate Queries over NoSQL 10 Graph Databases: Cypherf and the Fuzzy4S Framework 11 12 13 Arnaud Castelltort1, Trevor Martin2 14 1 LIRMM, CNRS-University of Montpellier, France 15 2Department of Engineering Mathematics, University of Bristol, UK 16 17 18 19 20 21 Abstract 22 23 NoSQL databases are currently often considered for Big Data solutions as they 24 25 offer efficient solutions for volume and velocity issues and can manage some of 26 complex data (e.g., documents, graphs). Fuzzy approaches are yet often not 27 28 efficient on such frameworks. Thus this article introduces a novel approach to 29 30 define and run approximate queries over NoSQL graph databases using Scala 31 by proposing the Fuzzy4S framework and the Cypherf fuzzy declarative query 32 33 language.
    [Show full text]
  • A Deductive Database with Datalog and SQL Query Languages
    A Deductive Database with Datalog and SQL Query Languages FernandoFernando SSááenzenz PPéérez,rez, RafaelRafael CaballeroCaballero andand YolandaYolanda GarcGarcííaa--RuizRuiz GrupoGrupo dede ProgramaciProgramacióónn DeclarativaDeclarativa (GPD)(GPD) UniversidadUniversidad ComplutenseComplutense dede MadridMadrid (Spain)(Spain) 12/5/2011 APLAS 2011 1 ~ ContentsContents 1.1. IntroductionIntroduction 2.2. QueryQuery LanguagesLanguages 3.3. IntegrityIntegrity ConstraintsConstraints 4.4. DuplicatesDuplicates 5.5. OuterOuter JoinsJoins 6.6. AggregatesAggregates 7.7. DebuggersDebuggers andand TracersTracers 8.8. SQLSQL TestTest CaseCase GeneratorGenerator 9.9. ConclusionsConclusions 12/5/2011 APLAS 2011 2 ~ 1.1. IntroductionIntroduction SomeSome concepts:concepts: DatabaseDatabase (DB)(DB) DatabaseDatabase ManagementManagement SystemSystem (DBMS)(DBMS) DataData modelmodel (Abstract) data structures Operations Constraints 12/5/2011 APLAS 2011 3 ~ IntroductionIntroduction DeDe--factofacto standardstandard technologiestechnologies inin databases:databases: “Relational” model SQL But,But, aa currentcurrent trendtrend towardstowards deductivedeductive databases:databases: Datalog 2.0 Conference The resurgence of Datalog inin academiaacademia andand industryindustry Ontologies Semantic Web Social networks Policy languages 12/5/2011 APLAS 2011 4 ~ Introduction.Introduction. SystemsSystems Classic academic deductive systems: LDL++ (UCLA) CORAL (Univ. of Wisconsin) NAIL! (Stanford University) Ongoing developments Recent commercial
    [Show full text]
  • Comparative Study of Database Modeling Approaches
    COMPARATIVE STUDY OF DATABASE MODELING APPROACHES Department of Computer Science Algoma University APRIL 2014 Advisor Dr. Simon Xu By Mohammed Aljarallah ABSTRACT An overview and comparative study of different database modeling approaches have been conducted in the thesis. The foundation of every structure is important and if the foundation is weak the whole system can collapse and database is the foundation of every software system. The complexity and simplicity of this core area of software development is also a very important issue as different modeling techniques are used according to the requirements of software and evaluation of these techniques is necessary. The approach of the thesis is a literature survey and background of data modeling techniques. All the requirements of data modeling and database systems are encapsulated here along with the structure of database. The foundation of the thesis is developed by discussing some of the cases studies regarding the database models from the practical field to develop an understanding of database systems, models and techniques from the practical perspective. The study of database system and most of the models are investigated in the thesis to establish a scenario in which these modeling approaches could be compared in a more innovative and better way. Relational database modeling approach is one of the important techniques used to develop the database system and the technique that could be used as replacement of relational model as single or in hybrid way is also an interesting aspect of survey. The comparisons of traditional and modern database modeling methodologies are also discussed here to highlight the features of current database management systems.
    [Show full text]
  • DATALOG and Constraints
    7. DATALOG and Constraints Peter Z. Revesz 7.1 Introduction Recursion is an important feature to express many natural queries. The most studied recursive query language for databases is called DATALOG, an ab- breviation for "Database logic programs." In Section 2.8 we gave the basic definitions for DATALOG, and we also saw that the language is not closed for important constraint classes such as linear equalities. We have also seen some results on restricting the language, and the resulting expressive power, in Section 4.4.1. In this chapter, we study the evaluation of DATALOG with constraints in more detail , focusing on classes of constraints for which the language is closed. In Section 7.2, we present a general evaluation method for DATALOG with constraints. In Section 7.3, we consider termination of query evaluation and define safety and data complexity. In the subsequent sections, we discuss the evaluation of DATALOG queries with particular types of constraints, and their applications. 7.2 Evaluation of DATALOG with Constraints The original definitions of recursion in Section 2.8 discussed unrestricted relations. We now consider constraint relations, and first show how DATALOG queries with constraints can be evaluated. Assume that we have a rule of the form Ro(xl, · · · , Xk) :- R1 (xl,l, · · ·, Xl ,k 1 ), • • ·, Rn(Xn,l, .. ·, Xn ,kn), '¢ , as well as, for i = 1, ... , n , facts (in the database, or derived) of the form where 'if;; is a conjunction of constraints. A constraint rule application of the above rule with these facts as input produces the following derived fact: Ro(x1 , ..
    [Show full text]
  • Some Experiments on the Usage of a Deductive Database for RDFS Querying and Reasoning
    Some experiments on the usage of a deductive database for RDFS querying and reasoning Giovambattista Ianni1;2, Alessandra Martello1, Claudio Panetta1, and Giorgio Terracina1 1 Dipartimento di Matematica, Universit`adella Calabria, I-87036 Rende (CS), Italy, 2 Institut fÄurInformationssysteme 184/3, Technische UniversitÄatWien Favoritenstra¼e 9-11, A-1040 Vienna, Austria fianni,a.martello,panetta,[email protected] Abstract. Ontologies are pervading many areas of knowledge represen- tation and management. To date, most research e®orts have been spent on the development of su±ciently expressive languages for the represen- tation and querying of ontologies; however, querying e±ciency has re- ceived attention only recently, especially for ontologies referring to large amounts of data. In fact, it is still uncertain how reasoning tasks will scale when applied on massive amounts of data. This work is a ¯rst step toward this setting: based on a previous result showing that the SPARQL query language can be mapped to a Datalog, we show how e±cient querying of big ontologies can be accomplished with a database oriented exten- sion of the well known system DLV, recently developed. We report our initial results and we discuss about bene¯ts of possible alternative data structures for representing RDF graphs in our architecture. 1 Introduction The Semantic Web [4, 11] is an extension of the current Web by standards and technologies that help machines to understand the information on the Web so that they can support richer discovery, data integration, navigation, and au- tomation of tasks. Roughly, the main ideas behind the Semantic Web aim to (i) add a machine-readable meaning to Web pages, (ii) use ontologies for a precise de¯nition of shared terms in Web resources, (iii) make use of KR technology for automated reasoning on Web resources, and (iv) apply cooperative agent technology for processing the information of the Web.
    [Show full text]
  • Constraint-Based Synthesis of Datalog Programs
    Constraint-Based Synthesis of Datalog Programs B Aws Albarghouthi1( ), Paraschos Koutris1, Mayur Naik2, and Calvin Smith1 1 University of Wisconsin–Madison, Madison, USA [email protected] 2 Unviersity of Pennsylvania, Philadelphia, USA Abstract. We study the problem of synthesizing recursive Datalog pro- grams from examples. We propose a constraint-based synthesis approach that uses an smt solver to efficiently navigate the space of Datalog pro- grams and their corresponding derivation trees. We demonstrate our technique’s ability to synthesize a range of graph-manipulating recursive programs from a small number of examples. In addition, we demonstrate our technique’s potential for use in automatic construction of program analyses from example programs and desired analysis output. 1 Introduction The program synthesis problem—as studied in verification and AI—involves con- structing an executable program that satisfies a specification. Recently, there has been a surge of interest in programming by example (pbe), where the specification is a set of input–output examples that the program should satisfy [2,7,11,14,22]. The primary motivations behind pbe have been to (i) allow end users with no programming knowledge to automatically construct desired computations by supplying examples, and (ii) enable automatic construction and repair of pro- grams from tests, e.g., in test-driven development [23]. In this paper, we present a constraint-based approach to synthesizing Data- log programs from examples. A Datalog program is comprised of a set of Horn clauses encoding monotone, recursive constraints between relations. Our pri- mary motivation in targeting Datalog is to expand the range of synthesizable programs to the new domains addressed by Datalog.
    [Show full text]
  • Evaluating a Graph Query Language for Human-Robot Interaction Data in Smart Environments
    Evaluating a Graph Query Language for Human-Robot Interaction Data in Smart Environments Norman K¨oster1, Sebastian Wrede12, and Philipp Cimiano1 1 Cluster of Excellence Center in Cognitive Interactive Technology (CITEC) 2 Research Institute for Cognition and Robotics (CoR-Lab), Bielefeld University, Bielefeld Germany fnkoester,swrede,[email protected], Abstract. Solutions for efficient querying of long-term human-robot in- teraction data require in-depth knowledge of the involved domains and represents a very difficult and error prone task due to the inherent (sys- tem) complexity. Developers require detailed knowledge with respect to the different underlying data schemata, semantic mappings, and most im- portantly the query language used by the storage system (e.g. SPARQL, SQL, or general purpose language interfaces/APIs). While for instance database developers are familiar with technical aspects of query lan- guages, application developers typically lack the specific knowledge to efficiently work with complex database management systems. Addressing this gap, in this paper we describe a model-driven software development based approach to create a long term storage system to be employed in the domain of embodied interaction in smart environments (EISE). The targeted EISE scenario features a smart environment (i.e. smart home) in which multiple agents (a mobile autonomous robot and two virtual agents) interact with humans to support them in daily activities. To support this we created a language using Jetbrains MPS to model the high level EISE domain w.r.t. the occurring interactions as a graph com- posed of nodes and their according relationships. Further, we reused and improved capabilities of a previously created language to represent the graph query language Cypher.
    [Show full text]