The full paper is published at the Resource Track of ISWC 2020 [14] VKG. The Virtual Knowledge Graph (VKG) approach, also known in the literature as Ontology-Based Data Access (OBDA) [8,12], has become a popular paradigm for accessing and integrating data sources [13]. In such approach, the data sources, which are normally relational databases, are virtualized through a mapping and an ontology, and presented as a unified knowledge graph, which can be queried by end-users through a vocabulary they are familiar with. At query time, a VKG system translates user queries over the ontology to SQL queries over the database. This approach frees end-users from the low-level details of data organization, so that they can concentrate on their high-level tasks. As it is gaining more importance, the VKG paradigm has been implemented in several systems [1,2,9,11] and adopted in a wide range of use cases. Here, we present the latest major release, Ontop v4, of a popular VKG system. Ontop v1. The development of Ontop has spanned the past decade. Developing such a system is highly non-trivial and requires both a theoretical investigation of the semantics and strong engineering efforts to implement all the required features. Ontop started in 2009, only one year after the first version of SPARQL had been standardized, while OWL 2 QL [6] and R2RML [4] appeared 3 years later, in 2012. At that time, the VKG research focused on union of conjunctive queries (UCQs) as a query language. With this target, Ontop v1 relied on non-recursive Datalog as its core data structure [10] because it perfectly fit the UCQ-based setting. The development of Ontop was boosted by the EU FP7 project Optique (2013-2016), during which the compliance with the relevant W3C recommendations became a priority, and significant progress was made in this direction. The last release of Ontop v1 was v1.18 in 2016 [1]. New challenges. A natural requirement that emerged during the Optique project were aggregates introduced in SPARQL 1.1 [5]. The Ontop development team spent a major effort, internally called Ontop v2, on implementing this
query language feature. However, it became exceedingly clear that the Datalog representation was not well suited for this implementation. Some prototypes of Ontop v2 were used in the Optique project for internal purposes, but never reached the level of a public release. During this development, as Ontop moved towards supporting the W3C recommendations for SPARQL and R2RML, we have identified the following new challenges: – In contrast to the usual DL encoding with unary and binary predicates for classes and properties, in SPARQL triple pattern variables can occur in positions of class and property names, which means that there are effectively only two ‘predicates’: triple for triples in the RDF dataset default graph, and quad for named graphs. – More importantly, SPARQL is based on a rich algebra, which goes beyond the expressivity of CQs. Non-monotonic features like optional and minus, cardinality-sensitive query modifiers (distinct) and aggregation (group by with functions such as sum, avg, count) are difficult to model even in extensions of Datalog. – Even without SPARQL aggregation, cardinalities have to be treated carefully: the SQL queries in a mapping produce bags of tuples, but their induced RDF graphs contain no duplicates and thus are sets of triples; however, when a SPARQL query is evaluated, it results in a bag of solutions mappings. These challenges turned out to be difficult to tackle in the Datalog setting. Ontop v4. To address the challenges posed by aggregation, and others that had emerged in the meantime, we started to investigate an alternative core data structure. The outcome has been what we call intermediate query (IQ), an algebra-based data structure that unifies both SPARQL and relational algebra. Using IQ, we reimplemented most of the Ontop code base. After two beta releases in 2017 and 2018, we released the stable version of Ontop v3 in 2019. Following Ontop v3, the development focussed on improving compliance and adding several major features. In particular, aggregates have now been supported since Ontop v4-beta-1, released in late 2019. The stable version of Ontop v4 was released in July 20201. The documentation is provided at the official website2. Evaluation. Ontop v4 has greatly improved its compliance with relevant W3C recommendations and provides good performance in query answering. It supports almost all the features of SPARQL 1.1, R2RML, OWL 2 QL, and SPARQL entailment regime, and the SPARQL 1.1 HTTP Protocol. In particular, in Table 1, we present a summary of Ontop v4 compliance with SPARQL 1.1, where rows correspond to sections of the WC3 recommendation. Most of the features are supported, but some are unsupported or only partially supported. Note that most of the missing SPARQL functions (Section 17.4) are not so challenging to implement but require a considerable engineering effort to carefully define their translations into SQL. We will continue the process of implementing them gradually and track the progress in a dedicated issue3. Recently, two indepen1 https://github.com/ontop/ontop 2 https://ontop-vkg.org/ 3 https://github.com/ontop/ontop/issues/346 8. Negation 9. Property Paths 10. Assignment 11. Aggregates 12. Subqueries 13. RDF Dataset 14. Basic Federated Query 16. Query Forms 17.4.1. Functional Forms 17.4.2. Fns. on RDF Terms 17.4.3. Fns. on Strings
Subqueries
SERVICE
PredicatePath, InversePath, ZeroOrMorePath, . . .
15. Solution Seqs. & Mods.
Coverage 4/4 1/2 0 2/2 6/6 1/1 1/2 0 6/6 4/4 6/11 9/13 14/14 5/5 8/9 5/5 0 0 The Virtual Knowledge Graph System Ontop (Extended Abstract) 17.4.4. Fns. on Numerics
abs, round, ceil, floor, RAND 17.4.5. Fns. on Dates&Times now, year, month, day, hours,
minutes, seconds, timezone, tz 17.4.6. Hash Functions 17.5. XPath Constructor Fns. casting 17.6. Extensible Value Testing user defined functions
MD5, SHA1, SHA256, SHA384, SHA512
dent evaluations [
Xiao et al.