Semantic Web 1 (0) 1–5 1 IOS Press
1 1 2 2 3 3 4 Gravsearch: transforming SPARQL to query 4 5 5 6 humanities data 6 7 7 8 Tobias Schweizer a,b and Benjamin Geer a,c 8 9 a Data and Service Center for the Humanities, Gewerbestrasse 24, 4123 Allschwil, Switzerland 9 10 b E-mail: [email protected] 10 11 c E-mail: [email protected] 11 12 12 13 13 Editors: Antonis Bikakis, University College London, UK; Beatrice Markhoff, University of Tours, FR; Alessandro Mosca, Faculty of 14 Computer Science, Free University of Bozen-Bolzano, IT; Stephane Jean, University of Poitiers - ENSMA, FR; Eero Hyvönen, University of 14 15 Helsinki, Aalto University, Finland 15 16 Solicited reviews: Pietro Liuzzo, Hiob Ludolf Centre for Ethiopian Studies, Universität Hamburg, Germany; Martin Rezk, DMM.com, Japan; 16 17 Benjamin Cogrel, KRDB, Free University of Bozen-Bolzano, Italy 17 18 18 19 19 20 20 21 21 22 Abstract. RDF triplestores have become an appealing option for storing and publishing humanities data, but available technolo- 22 23 gies for querying this data have drawbacks that make them unsuitable for many applications. Gravsearch (Virtual Graph Search), 23 24 a SPARQL transformer developed as part of a web-based API, is designed to support complex searches that are desirable in 24 humanities research, while avoiding these disadvantages. It does this by introducing server software that mediates between the 25 25 client and the triplestore, transforming an input SPARQL query into one or more queries executed by the triplestore. This design 26 suggests a practical way to go beyond some limitations of the ways that RDF data has generally been made available. 26 27 27 28 Keywords: SPARQL, humanities, querying, qualitative data, API 28 29 29 30 30 31 31 32 1. Introduction proposed here. Gravsearch aims to provide the power 32 33 and flexibility of a SPARQL endpoint, while provid- 33 34 Gravsearch transforms SPARQL queries and results ing better support for humanities data, and integrating 34 35 to facilitate the use of humanities data stored as RDF.1 well into a developer-friendly web-based API. Its ba- 35 36 Efforts have been made to use RDF triplestores for the sic design is of broad relevance, because it suggests 36 37 storage and publication of humanities data [1–3], but a practical way to go beyond some limitations of the 37 38 there is a lack of appropriate technologies for search- ways that humanities data has generally been made 38 39 ing this data for items and relationships that are of in- searchable. 39 40 terest to humanities researchers. A SPARQL endpoint A Gravsearch query is a virtual SPARQL query, i.e. 40 41 backed directly by the triplestore is one option, but it is processed by a server application, which trans- 41 42 presents a number of drawbacks. It can be cumbersome lates it into one or more SPARQL queries to be pro- 42 43 in SPARQL to query certain data structures that are es- cessed by the triplestore. Therefore, it can offer sup- 43 44 pecially useful in the humanities, and there is no stand- port for data structures that are especially useful in 44 45 ard support for permissions or for versioning of data. the humanities, such as text markup and calendar- 45 46 Queries that may return huge results also pose scalabil- independent historical dates, and are not included in 46 47 ity problems. A technical solution to these problems is RDF standards. More generally, a Gravsearch query 47 48 can use data structures that are simpler than the ones 48 49 49 1The source code of the Gravsearch implementation, and its used in the triplestore, thus improving ease of use. A 50 design documentation, are freely available online; see https://www. virtual query also allows the application to filter results 50 51 knora.org. according to user permissions, enforce the paging of 51
1570-0844/0-1900/$35.00 c 0 – IOS Press and the authors. All rights reserved 2 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data
1 results to improve scalability, take into account the ver- DaSCH’s mission is to make all the data it stores inter- 1 2 sioning of data in the triplestore, and return responses operable, so that it is possible to search for data across 2 3 in a form that is more convenient for web applica- projects and academic disciplines in a generic way, re- 3 4 tion development. The input SPARQL is independent gardless of the specific data structures used in each 4 5 of the triplestore implementation used, and the trans- project. For example, many projects store text with 5 6 former backend generates vendor-specific SPARQL markup, and it should be possible to search the markup 6 7 as needed, taking into account the triplestore’s im- of all these texts, regardless of whether they are letters, 7 8 plementation of inference, full-text searches, and the poems, books, or anything else. When markup con- 8 9 like. Instead of simply returning a set of triples, a tains references to other data, it is useful for human- 9 10 Gravsearch query can produce a JSON-LD response ities researchers to search through the markup to the 10 11 whose structure facilitates web application develop- data it refers to, e.g. by searching for texts that refer 11 12 ment. to a person born after a certain date (as in the example 12 13 The current implementation of Gravsearch is closely in Section 2.2). It is therefore desirable to store text 13 14 tied to a particular application, but its design is of more markup in the same way as other data, so they can be 14 15 general interest to developers of RDF-based systems. searched together. 15 16 It demonstrates that, for an application that manages The DaSCH must also mitigate the risks associated 16 17 data in an RDF triplestore and provides a web-based with technological and institutional change. The more 17 18 API, there is considerable value in a SPARQL-based its data storage is based on open standards, the easier 18 19 API, which accepts SPARQL queries from the cli- it will be to migrate data to some other format if it 19 20 ent, transforms them in the application, runs the trans- becomes necessary to do so in the future. 20 21 formed queries in the triplestore, and transforms the With these requirements in mind, the DaSCH has 21 22 results before returning them to the client. It also sug- chosen to store all data in an RDF triplestore as far 22 23 gests solutions to some of the practical issues that arise as possible (the main exceptions being images, au- 23 24 in the development of such a system. Consideration dio, and video). RDF’s flexibility allows it to accom- 24 25 of this approach may lead others to develop similar modate all sorts of data structures. Its standardisation, 25 26 application-specific tools, or to envisage more generic along with the variety of triplestore implementations 26 27 approaches to SPARQL transformation.2 available, helps reduce the risks of long-term preserva- 27 28 tion. Even if RDF technology disappears over time, the 28 29 1.1. Institutional and technical context RDF standards will make it possible to migrate RDF 29 30 graphs to other types of graph storage. 30 31 31 Gravsearch has been developed as part of Knora Knora is therefore based on an RDF triplestore and 32 32 (Knowledge Organization, Representation, and An- a base ontology. The base ontology defines basic data 33 33 notation), an application developed by the Data and types and abstract data structures; it is generic and does 34 5 34 Service Center for the Humanities (DaSCH) [6] to en- not make any assumptions about semantics. Each re- 35 35 sure the long-term availability and reusability of re- search project using Knora must provide one or more 36 36 search data in the humanities.3 The Swiss National ontologies defining the OWL classes and properties 37 37 Science Foundation (SNSF) requires researchers to used in its data, and these ontologies must be derived 38 38 have a plan for making their research data publicly ac- from the Knora base ontology. 39 39 cessible,4 and the DaSCH was created to provide the Knora is a server application written in Scala; it 40 40 necessary infrastructure to meet this requirement. provides a web-based API that allows data to be quer- 41 ied and updated, and supports the creation of virtual re- 41 42 It is not feasible or cost-effective for the DaSCH to 42 maintain a multitude of different data formats and stor- search environments that can work with heterogeneous 43 6 43 age systems over the long term. Moreover, part of the research data from different disciplines. 44 The DaSCH’s mission of long-term preservation re- 44 45 quires it to minimise the risk of vendor lock-in. Knora 45 46 2For some steps in this direction, see [4] and [5]. 46 47 3The DaSCH as an institution is responsible for research data cre- 47 5 48 ated by humanities projects. However, this does not rule out the pos- For details of the Knora base ontology, see the documentation at 48 sibility that the technical solutions developed by the DaSCH are use- https://www.knora.org. 49 49 ful to other fields of research as well. 6For more information on Knora, see https://www.knora.org. A 50 4http://www.snf.ch/en/theSNSF/research-policies/open_ list of projects implemented, planned, or under development using 50 51 research_data/Pages/default.aspx Knora can be found at https://dasch.swiss/projects/. 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 3
1 must therefore, as far as possible, avoid relying on generic storage system for humanities data, as outlined 1 2 any particular triplestore implementation, or on any in Section 1.1, introduces complexities in the the RDF 2 3 type of data storage that has not been standardised and data structures used in the triplestore, and these com- 3 4 does not have multiple well-maintained implementa- plexities should be hidden from clients for the sake of 4 5 tions. This means that as long as there is no widely usability. 5 6 implemented RDF standard for some of the DaSCH’s For example, in humanities research, it is useful 6 7 requirements, such as access control and versioning, to search for dates independently of the calendar in 7 8 Knora has to handle these tasks itself to ensure consist- which they are written in source materials. If an an- 8 9 ent behaviour, regardless of which triplestore is used.7 cient Chinese manuscript records a solar eclipse or a 9 10 It was therefore decided, for example, to use an in- sighting of a comet, and an ancient Greek manuscript 10 11 band approach to storing permissions in a role-based records the same astronomical event at the same time, 11 12 access control model, and to store previous versions of a search for texts mentioning the event and the date 12 13 values as linked lists, all in standard RDF.8 Over time, should find both texts, even though the date was writ- 13 14 if new RDF standards for these features are created and ten in different calendars. Astronomers and historians 14 15 widely supported, it will become possible to remove have long used a calendar-independent representation 15 16 them from Knora and allow the triplestore to handle of dates, called Julian Day Numbers (JDNs), to facilit- 16 17 them. ate such comparisons [10, 11]. A Julian Day Number 17 18 is an integer, and can therefore be efficiently compared 18 19 1.2. Problem definition in a database query. Moreover, historical dates are of- 19 20 ten imprecise, e.g. when only the year is known, but 20 21 Knora’s API required a query language that allows not the month or day, or when a date is known only to 21 22 for complex searches in specific projects, as well as fall within a certain range. 22 23 cross-project searches using ontologies shared by dif- Knora therefore stores each date in the triplestore 23 24 ferent projects, such as FOAF9 or dcterms.10 Re- as an instance of its DateValue class, which con- 24 25 searchers need to be able be to find connections in their tains two JDNs, representing a possibly imprecise date 25 26 data across project boundaries, and developers need to as a date range. Each date in the range (i.e. the start 26 27 present a project’s data online in an interactive way to date and the end date) has a precision (year, month, 27 28 researchers and the interested public. There needs to or day). The date range also indicates the calendar in 28 29 be a flexible way to request particular graphs of data, which the date was originally recorded. This allows 29 30 not only for searches, but also to present combinations a SPARQL query to determine the chronological re- 30 31 of resources that are known to be of interest to users. lationship between two dates, regardless of the calen- 31 32 For example, the Bernoulli-Euler Online project (see dar that they were originally created in. This approach 32 33 Section 3) needed to present a manuscript page aligned cannot handle dates whose JDN cannot be computed 33 34 with different layers of transcription, ranging from dip- (e.g. dates in a calendar system whose points of refer- 34 35 lomatic transcriptions to translations [9]. To maximise ence are not known); these would need to be stored in 35 36 the autonomy of web developers, Knora’s API needs to a different way. It would also be possible to extend this 36 37 make this possible without introducing project-specific system to express different sorts of imprecision. How- 37 38 API routes. ever, the current design is already sufficient for many 38 39 The query language also needs to allow queries to historical research projects. For our purposes here, the 39 40 use data structures that are simpler than the ones stored important point is to illustrate the usefulness of hav- 40 41 in the triplestore. The DaSCH’s requirement to have a ing different internal and external representations of 41 42 dates.11 42 43 43 7One exception is full-text search, which is implemented by the 44 44 triplestore but is not standardised. 11Projects such as GODOT [12] approach this task differently, by 45 8For an overview of different approaches to RDF access control, creating reference entries for calendar dates identified by URIs that 45 46 see [7]. See The Fundamentals of Semantic Versioned Querying for can then be used in online editions to allow for searches for a spe- 46 47 a proposed versioning extension to RDF. The RDF*/SPARQL* re- cific date. In our view, the approach of storing and comparing JDNs 47 48 ification proposal [8] may also lead to new ways of solving these in the triplestore allows for more powerful searches, because JDNs 48 problems. can be compared using operators such as less than and greater than. 49 49 9http://xmlns.com/foaf/spec/ In the future, we would like support period terms. These refer to 50 10https://www.dublincore.org/specifications/dublin-core/ timespans that are not expressed in terms of calendar dates, and can 50 51 dcmi-terms/ be represented as IRIs. For example, historians of mathematics use 51 4 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data
1 JDNs are clearly not a convenient representation for GraphQL [19] is a newer development and – despite 1 2 clients to use. Search requests and responses should in- its name – not restricted to graph databases. It is meant 2 3 stead use whatever calendars the client prefers. The cli- to be a query language that integrates different API en- 3 4 ent should not have to send or receive JDNs itself, or to dpoints. Instead of making several requests to different 4 5 deal with the complexities of comparing JDN ranges in APIs and processing the results individually, GraphQL 5 6 SPARQL. In the Knora API, all dates are input and out- is intended to allow the client to make a single request 6 7 put as calendar dates; Knora converts between JDNs that defines the structure of the expected response. (See 7 8 and calendar dates using the International Components section 2.1 for a discussion of extensions to GraphQL 8 9 for Unicode library.12 for querying RDF.) 9 10 Another example concerns text with markup, which From our perspective, triplestore-backed SPARQL 10 11 Knora stores as RDF data (see Section 3.3). A hu- endpoints and GraphQL both have limitations that 11 12 manities researcher might wish to search a large num- make them unsuitable for Knora and for humanities 12 13 ber of texts for, say, a particular word marked up as a data in general. They assume that the data structures in 13 14 noun. Knora could optimise this search by using a full- the triplestore are the same as the ones to be returned to 14 15 text search index. This also involves rather complex the client. They offer no standard way to restrict query 15 16 SPARQL, which is partly specific to the type of full- results according to the client’s permissions. They do 16 17 text indexing software being used. The client should not enforce the paging of results, but leave this to the 17 18 not have to deal with these details. client. And they provide no way to work with data that 18 19 SPARQL lacks other features required in this con- has a version history (so that ordinary queries return 19 20 text. Knora must restrict access to data according to only the latest version of each item). These require- 20 21 user permissions. It also implements a system for ver- ments led us to develop a different approach. 21 22 sioning data in the triplestore, such that the most re- 22 23 cent version is returned by default, but the version his- 23 24 tory of resources can be requested. To improve scalab- 24 2. A hybrid between a SPARQL endpoint and a 25 ility, Knora should enforce the paging of search results, 25 web API 26 rather than leaving this up to the client as in SPARQL. 26 27 27 28 1.3. Related work One option would be to create a domain-specific 28 29 language, but it was simpler to use SPARQL, lever- 29 30 One way of making RDF data publicly available aging its standardisation and library support, while in- 30 31 and queryable is by means of a SPARQL endpoint tegrating it into Knora’s web API. Gravsearch there- 31 32 backed directly by a triplestore. Prominent examples fore accepts as input a subset of standard SPARQL 32 33 include DBpedia [16], Wikidata [17], and Europeana query syntax, and requires queries to follow certain ad- 33 34 [3]. While this approach offers great flexibility and al- ditional rules. 34 35 lows for complex queries, its drawbacks have been cri- Gravsearch is thus a hybrid between a SPARQL 35 36 ticised. In a widely cited blog post [18], Dave Rogers endpoint and a web API, aimed at combining the ad- 36 37 argues that SPARQL endpoints are an inherently poor vantages of both. By supporting SPARQL syntax, it 37 38 design that cannot possibly scale, and that RESTful enables clients to submit queries based on complex 38 39 APIs should be used instead. For example, a SPARQL graph patterns given in a WHERE clause. By supporting 39 40 endpoint allows a client to request all the data in the re- SPARQL CONSTRUCT queries, it allows each query to 40 41 pository; this could easily place unreasonable demands specify a complex graph structure to be returned in the 41 42 on the server, particularly if many such requests are query results. At the same time, the application is able 42 43 submitted concurrently. to add additional functionality not supported in stand- 43 44 ard SPARQL. The Knora API server processes the in- 44 45 the expression ‘Erste Petersburger Periode’ [13] to refer to the first put query, transforming it into one or more SPARQL 45 46 timespan Leonhard Euler lived in St. Petersburg. Projects such as queries that are executed by the triplestore, using data 46 47 ChronOntology [14] or PeriodO [15] relate period terms to structures that are more complex than the ones in the 47 48 timespans and geographical regions. Period terms can also be made input query. It then processes and transforms the triples 48 to correspond to calendar dates stored as JDNs, as long as the calen- 49 returned by the triplestore, this time converting com- 49 dar date representation can express the imprecision required in each 50 term. plex data structures into simpler ones, to construct the 50 51 12http://site.icu-project.org/home response. 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 5
1 This extra layer of processing enables Gravsearch to ing the query. Moreover, setting a limit on the number 1 2 avoid the disadvantages of SPARQL endpoints backed of triples returned by a CONSTRUCT query can cause 2 3 directly by a triplestore, and to provide additional the triplestore to return incomplete entities, with no in- 3 4 features. Certain data structures can be queried in a dication to the client that the response has been trun- 4 5 more convenient way, results are filtered according to cated. 5 6 the user’s permissions, the versioning of data in the It would be better to reject a badly written query 6 7 triplestore is taken into account (only the most recent without running it, and users would appreciate error 7 8 version of the data is returned), and scalability is im- messages explaining what needs to be changed to im- 8 9 proved by returning results in pages of limited size. prove the query. The presence of an application layer 9 10 that analyses and transforms the input query provides 10 11 2.1. Scope of Gravsearch opportunities to do this. This is why, for example, 11 12 Gravsearch currently does not allow subqueries. It 12 13 Gravsearch was developed as part of Knora and is would also be possible to reject a triple pattern like ?s 13 14 used as part of the Knora API. Knora is an integrated ?p ?o whose variables are not restricted by any other 14 15 system, taking care of creating, updating and reading pattern. We see this kind of analysis as a promising 15 16 data by mediating between the triplestore and the cli- topic for future research. 16 17 ent. Gravsearch is not meant to replace direct commu- Although SELECT queries are not currently suppor- 17 18 nication with a triplestore via a SPARQL endpoint, but ted, if tabular output is desired, (e.g. for statistical ana- 18 19 rather to provide an integrated system with a flexible lysis), the results of a CONSTRUCT query can be con- 19 20 way of querying data. The result of a Gravsearch query verted into a table by combining results pages and con- 20 21 is returned in the same format used by the rest of the verting the RDF output to tabular form. This could be 21 22 Knora API, making it suitable for web applications. done either in the client or on the server. 22 23 HyperGraphQL [20], an extension to GraphQL, 23 24 makes it possible to query SPARQL endpoints using 2.2. Ontology schemas 24 25 GraphQL queries, by converting them to SPARQL. Its 25 26 intended advantages include the reduction of complex- A design goal of Gravsearch is to enable queries to 26 27 ity on the client side and a more controlled way of work with data structures that are simpler than the ones 27 28 accessing a SPARQL endpoint, avoiding some of the actually used in the triplestore, thus hiding some com- 28 29 problems discussed in Rogers’s blog post [21]. A sim- plexity from the user. To make this possible, Knora 29 30 ilar approach has been taken with GraphQL-LD [22], implements ontology schemas. Each ontology schema 30 31 differing from HyperGraphQL in that GraphQL quer- provides a different view on ontologies and data that 31 32 ies are translated to SPARQL on the client-side. We exist in the triplestore. The term internal schema refers 32 33 think that both HyperGraphQL and GraphQL-LD to the structures that are actually in the triplestore, and 33 34 could be viable approaches to generating SPARQL that external schema refers to a view that transforms these 34 35 is further processed before being sent to the triplestore, structures in some way for use in a web API. 35 36 thus integrating with Gravsearch. We consider this a Knora’s built-in ontologies as well as all project- 36 37 promising avenue for future development. specific ontologies are available in each schema, but 37 38 When the full flexibility of SPARQL is needed, pro- in the triplestore, all ontologies are stored only in the 38 39 jects always have the possibility to make their data internal schema; the other schemas are generated on 39 40 openly accessible via a SPARQL endpoint. In such a the fly as needed. An ontology always has a differ- 40 41 case, a named graph can be made for queries but not ent IRI in each schema, but the triplestore sees only 41 42 for updates, and possibly transformed into a simpler the IRIs for the internal schema. In Knora, the IRIs of 42 43 data model than used internally in order to facilitate built-in and project-specific ontologies must conform 43 44 integration with other data sets. to certain patterns; this allows Knora to convert onto- 44 45 It is true that, even with pagination, it is possible logy IRIs automatically, following simple rules, when 45 46 to write ‘inefficient or complex SPARQL that returns converting ontologies and data between schemas. An 46 47 only a few results’ [18], and this could also be true of additional convention is that Knora’s base ontology 47 48 Gravsearch queries. As a last resort, some triplestores is called knora-base in the internal schema, and 48 49 provide a way to set arbitrary limits on execution time knora-api in the external schemas. 49 50 or the number of triples or rows returned, but this still In the internal schema, the smallest unit of research 50 51 means consuming significant resources before reject- data is a Knora knora-base:Value, which is an 51 6 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data
1 RDF entity that has an IRI. Subclasses of Value rep- If the client requested a JSON-LD response in the 1 2 resent different types of data (text, integers, dates, and complex schema, it will look like Listing 3. Here each 2 3 so on). If a client wishes to update a value via the date is represented as a calendar date, the text with its 3 4 Knora API, it needs to know the value’s IRI. How- markup has been converted to an XML document (one 4 5 ever, a Knora Value also contains information that is of several possible representations that the client can 5 6 represented in a way that is not convenient for clients request), and each link to a beol:person resource 6 7 to manipulate (e.g. dates are stored as JDNs, as men- is represented as a JSON-LD object containing the tar- 7 8 tioned above). Therefore, Knora provides an external get resource as a nested object. Each resource is ac- 8 9 schema called the knora-api complex schema, in companied by additional metadata added by the Knora 9 10 which each value has an IRI, but its contents are rep- API server (some of which is not shown here), e.g. an 10 11 resented in more convenient form (e.g. calendar dates ARK URL serving as a permanent link to the resource. 11 12 are used instead of JDNs). This JSON-LD representation in the complex schema 12 13 For clients that need a read-only view of the data, is designed to be convenient to use in the development 13 14 Knora provides a simple schema, in which there is of web applications. The ARK URLs in this listing can 14 15 no Value class; instead, Knora values are represen- be opened in a web browser to show an example of 15 16 ted as literal datatypes such as xsd:string, and the such an application.13 16 17 metadata attached to each value is hidden. An advant- If the client requested a JSON-LD response in 17 18 age of the simple schema is that it facilitates the use of the simple schema, it will look like Listing 4. (The 18 19 standard ontologies such as dcterms, in which val- client can also request an equivalent response in 19 20 ues are typically represented as datatypes without their Turtle or RDF/XML.) Here, the structure of the re- 20 21 own metadata. For example, if a property is defined in sponse has been simplified, so that values are rep- 21 22 dcterms:title 22 Knora as a subproperty of , its ob- resented as simple literals. For example, the object 23 ject in Knora will internally be a Knora TextValue 23 of beol:title is a string literal rather than a 24 with attached metadata, but a Gravsearch query in the 24 TextValue. Moreover, if the client dereferences 25 simple schema can treat it as a literal, in keeping with 25 the BEOL ontology IRI given in the JSON-LD con- 26 its definition in dcterms. 26 text,14 the definition of beol:title says that it 27 Gravsearch queries can thus be written in either of 27 is a datatype property, and that it is a subproperty 28 Knora’s external schemas, and results can also be re- 28 of dcterms:title. A client that knows about 29 turned in either of these schemas. 29 dcterms:title, and processes titles in some par- 30 To illustrate the differences between these schemas, 30 ticular way, can then apply the same processing to 31 Appendix A shows a Gravsearch query that searches 31 the beol:title. As this example shows, the simple 32 for a letter in the Bernoulli-Euler Online (BEOL) pro- 32 schema lends itself to use in applications that rely 33 ject (see Section 3), using the complex schema. The 33 mainly on standard ontologies to integrate data from 34 query searches for a letter from the mathematician An- 34 different sources. 35 ders Johan Lexell (identified by his IRI), specifying 35 36 that the text of the letter must refer to a person whose The simple schema also makes it possible to use 36 37 birthdate is after 1706 CE. To do this, the query in standard ontologies in the Gravsearch query itself. 37 38 Listing 1 searches the triples representing the text’s Listing 5 shows a Gravsearch query that uses the 38 39 standoff markup (see Section 3.3) for a link to a FOAF ontology to search the BEOL project data for 39 40 beol:person resource whose birthdate is greater foaf:Person objects whose foaf:familyName 40 41 than that date. is ‘Euler’, without using the BEOL ontology at all. 41 42 To run this query, the Gravsearch transformer gen- This works because beol:person is a subclass of 42 43 erates a SPARQL CONSTRUCT query; part of the foaf:Person, and beol:hasFamilyName is a 43 44 triplestore’s response is shown in Listing 2 (the full subproperty of foaf:familyName. Depending on 44 45 response contains many more details such as permis- the triplestore’s inference capabilities, Knora either 45 46 sions, timestamps, and so on). A beol:person rep- uses the triplestore’s RDFS inference or expands the 46 47 resenting Leonhard Euler is returned, because he is query itself using property path syntax. 47 48 identified in the text markup and was born after 1706. 48 49 49 Note that the date values are represented as ranges of 13For example, see http://ark.dasch.swiss/ark:/72163/1/0801/ 50 JDNs, and each markup tag is represented as an RDF 25Ro4c5gSIioLstzJ25FiAC for a representation of the letter. 50 51 entity. 14http://api.dasch.swiss/ontology/0801/beol/simple/v2 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 7
1 The query in Listing 5 specifies that the object 2.4. Versioning 1 2 of foaf:familyName is an xsd:string. This 2 3 is consistent with the definition of the subproperty Internally, a resource is connected only to the cur- 3 4 beol:hasFamilyName in the simple schema. In rent version of each of its values. Each value ver- 4 5 the internal schema, the object of that property is the sion is connected to the previous version via the prop- 5 6 IRI of a Knora TextValue, which contains a string erty previousVersion, so that the versions form 6 7 as well as permissions and other metadata. When a linked list. When a client requests a single resource 7 8 Gravsearch generates SPARQL from the input query, with its values via the Knora API, the client can specify 8 9 it transforms the WHERE clause of the input query to a version timestamp. Knora then generates a SPARQL 9 10 10 handle this difference (see Section 2.6). This design query that traverses the linked list to retrieve the values 11 that the resource had at the specified time. 11 allows standard ontologies using simple literal values, 12 Gravsearch is designed to query only current data. 12 such as FOAF, to be used in Gravsearch queries, even 13 This is easily achieved, because the only way to ob- 13 though Knora actually stores values as IRIs with at- 14 tain a value in Gravsearch is to follow the connec- 14 tached metadata. 15 tion between the resource and the value, which is 15 16 In short, Gravsearch transforms queries, ontologies, always the current version. Knora’s external onto- 16 17 and data on the fly according to the ontology schema logy schemas do not expose the version history data 17 18 that the client is using. The implementation is partly structure at all (e.g. they do not provide the prop- 18 19 object-oriented (the Scala classes representing differ- erty previousVersion). Therefore, the client can- 19 20 ent sorts of RDF entities have methods for generat- not use previousVersion to query a past version 20 21 ing representations of themselves in different schemas) of a value, which would be possible if they could 21 22 and partly based on sets of transformation rules for submit SPARQL directly to the triplestore. A specific 22 23 each schema (e.g. to remove certain properties and add (non-Gravsearch) API request enables clients to ac- 23 24 others, and to change OWL cardinalities). Additional cess the version history of a value. The version history 24 25 external schemas could be added in the future. data structure is hidden from clients, enabling it to be 25 26 changed in the future as RDF technology develops. 26 27 2.3. Permissions 27 28 2.5. Gravsearch syntax and semantics 28 29 29 In Knora, each resource and each value has role- 30 Syntactically, a Gravsearch query is a SPARQL 30 based permissions attached to it. Internally, permis- 31 CONSTRUCT query. Thus it supports arbitrarily com- 31 sions are represented as string literals in a compact 32 plex search criteria. One could, for example, search 32 33 format that optimises query performance. For ex- for persons whose works have been published by 33 34 ample, a Knora value could contain this triple: a publisher that is located in a particular city. A 34 35 CONSTRUCT query also allows the client to specify, 35
1 pages of search results, and does not allow LIMIT. new AST. There are different backends for differ- 1 2 The client can use ORDER BY with one or more vari- ent triplestores, which take into account triplestore- 2 3 ables to determine the order in which results will be specific features such as RDFS inference capabilities 3 4 returned, and OFFSET to specify which page of res- and full-text search. We are currently exploring adding 4 5 ults should be returned. (This is different from the an optimisation phase to reorder patterns in the WHERE 5 6 standard SPARQL OFFSET, which counts solutions to clause in cases where the triplestore’s query optimiser 6 7 the pattern in the WHERE clause, rather than pages of may not do so effectively. 7 8 results.) The maximum number of results per page is For the reasons explained in Section 1.2, the gener- 8 9 configurable in the application’s settings, and cannot ated SPARQL is considerably more complex than the 9 10 be controlled by the client. The server indicates that provided Gravsearch query, and deals with data struc- 10 11 more pages of results may be available by including a tures in the internal schema. Each Gravsearch query 11 12 boolean property mayHaveMoreResults in the re- is converted to two SPARQL queries to improve per- 12 13 sponse. To retrieve all results, the client continues re- formance. First, a SELECT query (prequery) is gener- 13 14 questing pages until this property is absent (false); it is ated, to identify a page of matching resources. Then a 14 15 possible that the last page will be empty. CONSTRUCT query (main query) is generated, to re- 15 16 trieve the requested values of those resources. Figure 1 16 17 2.6. Processing and execution of a Gravsearch query illustrates this process graphically. 17 18 18 19 In processing Gravsearch queries, the API server 2.6.1. Generation of the Prequery 19 20 is free to use a SPARQL design that best suits the The prequery’s purpose is to get one page of IRIs 20 21 performance characteristics of the triplestore. For ex- of matching resources and values. It is a SELECT 21 22 ample, as described below, our implementation trans- query whose WHERE clause is generated by transform- 22 23 forms each input query into multiple SPARQL queries ing the statements of the input query’s WHERE clause. 23 24 that are run in the triplestore, and generates different Thus it contains all the restrictions of the input query, 24 25 SPARQL for different triplestores. Clients and users transformed into the internal schema (see 2.2), as well 25 26 need not be aware of this. as additional statements, e.g. to implement RDFS in- 26 27 In theory, such transformations could be implemen- ference if the triplestore’s inference capabilities are 27 28 ted using a more generic rule system, such as Rule In- not adequate, and to ignore resources and values that 28 29 terchange Format (RIF),15 which is intended to be used have been marked as deleted. The prequery’s SELECT 29 30 for this purpose by the GeoSPARQL standard.16 How- clause is generated automatically. 30 31 ever, RIF is not widely implemented, and even most The prequery’s result consists of the IRIs of one 31 32 GeoSPARQL implementations do not support query page of matching main resources, along with their val- 32 33 rewriting [23].17 ues and linked resources. Since correct paging requires 33 34 Rather than introduce an additional programming the query to return one row per matching main re- 34 35 language for query transformation, we chose to imple- source, the results are grouped by main resource IRI, 35 36 ment a traditional compiler design in Scala, taking ad- and the IRIs of matching values and of linked re- 36 37 vantage of the RDF4J18 SPARQL parser and Knora’s sources are aggregated using GROUP_CONCAT. The 37 38 extensive built-in support for working with OWL on- results are ordered by the criteria in the ORDER BY 38 39 tologies. An abstract syntax tree (AST) is construc- clause of the input query, as well as by main resource 39 40 ted, type information is collected from it (see Sec- IRI (to ensure deterministic results). 40 41 tion 2.6.3), and it is passed through a sequence of The following sample Gravsearch query gets all the 41 42 transformations, each of which recursively traverses entries with sequence number equal to 10 from differ- 42 43 the AST, transforming graph patterns to produce a ent manuscripts. 43 44 44 PREFIX beol: 45 15 45 https://www.w3.org/TR/rif-overview/
1 ?entry knora-api:isMainResource true . CONSTRUCT { 1 2 ?entry beol:manuscriptEntryOf ?manuscript . ... 2 3 ?entry beol:seqnum ?seqnum . } 3 4 } WHERE { WHERE { 4 5 ?entry a beol:manuscriptEntry . { 5 ?entry beol:manuscriptEntryOf VALUES ?mainResourceVar { 6 6 ?manuscript .
1 1 Figure 1. Processing and Execution of a Gravsearch Query 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 that are relevant to the compiler.20 It first collects the runs each typeable entity through a pipeline of infer- 17 18 set of all entities whose types need to be determ- ence rules. These include rules such as the following: 18 19 ined (typeable entities) in the WHERE clause of the 19 – The type of a property’s object is inferred from 20 input query. It then runs the WHERE clause through 20 the expected object type of the property (which 21 a pipeline of type inspectors. Each inspector imple- 21 is specified in the definition of each Knora prop- 22 ments a particular mechanism for identifying types, 22 erty). 23 and passes an intermediate result to the next inspector 23 – The expected object type of a property is in- 24 in the pipeline. 24 ferred from the type of its actual object. (Thus if 25 At the end of the pipeline, each typeable entity 25 the query specifies ?book dcterms:title 26 should have exactly one type from the set of types that 26 ?title and ?title a xsd:string, the 27 are relevant to the compiler. Unlike a SPARQL end- 27 rule infers that dcterms:title expects an 28 point, if Gravsearch cannot determine the type of an 28 xsd:string object.) 29 entity, or finds that an entity has been used inconsist- 29 – If a FILTER expression compares two entities, 30 ently (i.e. with two different types in that set), it returns 30 they are inferred to have the same type. 31 an error message rather than an empty response. 31 – Function arguments are inferred to have the re- 32 The first type inspector reads type annotations. Two 32 quired types for the function. 33 annotations are supported: 33 34 Since the output of one rule may allow another rule 34 – rdf:type, used to specify the types of entities 35 to infer additional information, the pipeline of infer- 35 that are used as subjects or objects. 36 ence rules is run repeatedly until no new information 36 – knora-api:objectType, which can be used 37 can be determined. In practice, two iterations are suffi- 37 to specify the expected type of the object of a non- 38 cient for most realistic queries. 38 Knora property such as dcterms:title. 39 Appendix B shows an input query in the simple 39 40 Annotations are needed when a query uses a non- schema. It searches for books that have a particular 40 41 Knora ontology such as FOAF or dcterms. In the publisher (identified by IRI), and returns them along 41 42 future, it would be useful for Knora to take type in- with the family names of all the persons that have some 42 43 formation from standard non-Knora ontologies, mak- connection with those books (e.g. as author or editor). 43 44 ing these annotations unnecessary. In this example, the definition of the property 44 45 The second inspector in the pipeline infers types by hasPublisher specifies that its object must be a 45 46 using class and property definitions in ontologies. It Publisher, allowing Gravsearch to infer the type 46 47 of the resource identified by the specified IRI. Sim- 47 48 ilarly, the definition of hasFamilyName specifies 48 20The Knora base ontology determines the set of types that the 49 Person 49 algorithm needs to identify, and thus simplifies the algorithm. For an that its subject must be a and its object must 50 attempt at more complete type inference for SPARQL queries, see be a Knora TextValue; this allows the types of 50 51 [27]. ?person and ?familyName to be inferred. Once 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 11
1 the type of ?person is known, the object type of ${iaf2}. The result of processing the template is a 1 2 ?linkProp can be inferred. Gravsearch query, which the user interface submits to 2 3 the Knora API server. This query specifies that the au- 3 4 thor and recipient of each matching letter must have 4 5 3. Use case from the Bernoulli-Euler Online one of those two IAF identifiers. The results are sorted 5 6 project by date. The page number ${offset} is initially set to 6 7 0; as the user scrolls, the page number is incremented 7 8 One project that is using Gravsearch is Bernoulli- and the query is run again to load more results. 8 21 9 Euler Online (BEOL), a digital edition project fo- This query is simple enough to be written in the 9 10 cusing on 17th- and 18th-century primary sources in simple schema. For example, this allows the ob- 10 11 mathematics. BEOL integrates written sources relat- ject of beol:hasIAFIdentifier to be treated 11 12 ing to members of the Bernoulli dynasty and Leon- as a string literal. Internally, this is an object prop- 12 13 hard Euler into a web application based on Knora, erty. Its object is an entity belonging to the class 13 14 with data stored in an RDF triplestore. The BEOL knora-base:TextValue, and has predicates and 14 15 web site provides a user interface that enables users to objects of its own. This extra level of complexity is 15 16 search and view these texts in a variety of ways. It of- hidden from the client in the simple schema. After we 16 17 fers a menu of common queries that internally gener- substitute the IAF identifiers of Leonhard Euler and 17 18 ate Gravsearch using templates, and the user can also Christian Goldbach for the placeholders in the tem- 18 19 build a custom query using a graphical search inter- plate, the input query contains: 19 20 face, which also generates Gravsearch internally. 20 21 ?author beol:hasIAFIdentifier 21 ?authorIAF . 22 3.1. Example 1: finding correspondence between two 22 FILTER(?authorIAF = 23 mathematicians 23 "(DE-588)118531379" || 24 ?authorIAF = "(DE-588)118696149") 24 25 Most of the texts that are currently integrated in the 25 26 BEOL platform are letters exchanged between math- Gravsearch transforms these two lines to the follow- 26 27 ematicians. On the project’s landing page, we would ing SPARQL: 27 28 like to present the letters arranged by their authors 28 29 and recipients. With Gravsearch, it is not necessary to ?author beol:hasIAFIdentifier ?authorIAF . 29 30 make a custom API operation for this kind of query ?authorIAF knora-base:isDeleted false . 30 ?authorIAF knora-base:valueHasString 31 in Knora. Instead, a Gravsearch template can be used, 31 ?authorIAF__valueHasString . 32 with variables for the correspondents. 32 Appendix C shows a template for a Gravsearch FILTER(?authorIAF__valueHasString = 33 "(DE-588)118531379"^^xsd:string || 33 query that finds all the letters exchanged between 34 ?authorIAF__valueHasString = 34 35 two persons. Each person is represented as a resource "(DE-588)118696149"^^xsd:string) 35 36 in the triplestore. It would be possible to use the 36 37 IRIs of these resources to identify mathematicians, Since values in Knora can be marked as deleted, the 37 38 but since these IRIs are not yet stable during devel- generated query uses knora-base:isDeleted 38 39 opment, it is more convenient to use the property false to exclude deleted values. It then uses the gen- 39 40 beol:hasIAFIdentifier, whose value is an In- erated variable ?authorIAF__valueHasString 40 41 tegrated Authority File (IAF) identifier (maintained by to match the content of the TextValue. 41 42 the German National Library), a number that uniquely 42 43 identifies that person. This example thus illustrates 3.2. Example 2: a user interface for creating queries 43 44 searching for resources that have links to other re- 44 45 sources that have certain properties. The user chooses Users can also create custom queries that are not 45 46 the names of two mathematicians from a menu in a based on a predefined template. For this purpose, a 46 47 web browser, and the user interface then processes the user-interface widget generates Gravsearch, without 47 48 template, substituting the IAF identifiers of those two requiring the user to write any code (Appendix E). 48 49 mathematicians for the placeholders ${iaf1} and For example, a user can create a query to search 49 50 for all letters written since 1 January 1700 CE (the 50 51 21https://beol.dasch.swiss/ user specifies the Gregorian calendar) by Johann I 51 12 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data
1 Bernoulli, that mention Leonhard Euler but not Daniel 3.3. Example 3: Searching for text markup 1 2 I Bernoulli, and that contain the word Geometria. The 2 3 user can choose to order the results by date. The Here were are looking for a text containing the word 3 4 web-based user interface generates a Gravsearch query Acta that is marked up as a bibliographical reference.22 4 5 based on the search criteria (Appendix D). Knora stores text markup as ‘standoff markup’: each 5 6 In generating SPARQL to perform the requested markup tag is represented as an entity in the triplestore, 6 7 search, the Gravsearch compiler converts the date with start and end positions referring to a substring 7 8 comparison to one that uses a JDN. In the example, in the text. This makes it straightforward to represent 8 9 the input SPARQL requests a date greater than a date non-hierarchical structures in markup,23 and makes it 9 10 literal in the Gregorian calendar: possible for queries to combine criteria referring to 10 11 text markup with criteria referring to other entities in 11 12 FILTER(?date >= the triplestore, including links within text markup that 12 "GREGORIAN:1700-1-1"^^knora-api:Date) 13 point to RDF resources outside the text. Projects may 13 14 define own standoff entities in their project-specific 14 15 Gravsearch converts this to a JDN comparison. The 15 Gregorian date 1 January 1700 is converted to the JDN ontologies, deriving them from the types defined by 16 the Knora base ontology. 16 17 2341973. In the generated SPARQL, a matching date’s 17 end point must be greater than or equal to that JDN: To search for text markup, the input query must be 18 written in the complex schema. The input query uses 18 19 ?date knora-base:valueHasEndJDN the matchTextInStandoff function provided by 19 20 ?date__valueHasEndJDN . Gravsearch: 20 21 FILTER(?date__valueHasEndJDN >= 21 22 "2341973"^^xsd:integer) ?text knora-api:textValueHasStandoff 22 23 ?standoffBibliographyTag . 23 24 Other date comparisons work as follows: ?standoffBibliographyTag a 24 25 beol:StandoffBibliographyTag . 25 – Two DateValue objects are considered equal if FILTER knora-api:matchTextInStandoff( 26 26 there is any overlap between their date ranges. ?text, 27 27 – Two DateValue objects are considered unequal ?standoffBibliographyTag, 28 28 if there is no overlap between their date ranges. "Acta") 29 29 – DateValue A is considered to be less than 30 30 DateValue B if A’s end date is less than B’s Gravsearch translates this FILTER into two opera- 31 31 start date. tions: 32 32 33 To specify that the text of the letter must contain 1. An optimisation that searches in the full-text 33 34 the word Geometria, the input SPARQL uses the func- search index to find all texts containing this 34 35 tion knora-api:matchText, which is provided word. 35 36 by Gravsearch: 2. A regular expression match that determines 36 37 whether, in each text, the word is located within 37 38 FILTER knora-api:matchText(?text, a substring that is marked up as a paragraph. 38 "Geometria") 39 The resulting generated SPARQL looks like this24: 39 40 40 Gravsearch converts this function to triplestore- 41 ?text knora-base:valueHasString 41 specific SPARQL that (unlike the standard SPARQL 42 ?text__valueHasString . 42 CONTAINS 43 function) performs the query using a full- ?text__valueHasString 43 44 text search index. For example, with the GraphDB lucene:fullTextSearchIndex 44 45 triplestore using the Lucene full-text indexer, the gen- 45 erated query contains: 46 22‘Acta’ refers to an article published by Jacob Bernoulli in Acta 46 47 Eruditorum in December 1695. 47 ?text knora-base:valueHasString 23 48 See the TEI guidelines [28, chapter 20, Non-hierarchical Struc- 48 ?text__valueHasString . tures] for a discussion of this problem. 49 49 ?text__valueHasString 24Knora uses 0-based indexes in standoff markup, but SPARQL 50 lucene:fullTextSearchIndex uses 1-based indexes: https://www.w3.org/TR/xpath-functions/ 50 51 "Geometria"^^xsd:string . #func-substring. 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 13
1 "Acta"^^xsd:string . Acknowledgements 1 2 ?standoffTag 2 3 knora-base:standoffTagHasStart This work was supported by the Swiss National Sci- 3 4 ?standoffTag__start . ence Foundation (166072) and the Swiss Data and Ser- 4 ?standoffTag 5 vice Center for the Humanities. 5 knora-base:standoffTagHasEnd 6 6 ?standoffTag__end . 7 BIND(substr(?text__valueHasString, 7 8 ?standoffTag__start + 1, 8 9 ?standoffTag__end - 9 10 ?standoffTag__start) 10 11 AS ?standoffTag__markedUp) 11 12 FILTER(regex(?standoffTag__markedUp, 12 13 "Acta", "i")) 13 14 14 15 15 16 4. Conclusion 16 17 17 18 To ensure the long-term accessibility of research 18 19 data, a case can be made for storing nearly all data 19 20 (with the exception of a few binary file formats) 20 21 in RDF, in a way that works with any standards- 21 22 compliant triplestore, and avoiding non-standard tech- 22 23 nologies and vendor lock-in. However, this approach 23 24 24 implies that clients cannot be given direct access to 25 25 the triplestore, both because the necessary generic data 26 26 structures are inconvenient for clients to use, and be- 27 27 cause features such as versioning and access control 28 28 cannot be handled by the triplestore in a standard way. 29 29 There are also scalability issues associated with using 30 30 a SPARQL endpoint backed directly by the triplestore. 31 31 Yet humanities researchers want to be able to do the 32 32 33 sorts of powerful graph searches that they can do in 33 34 SPARQL. 34 35 The solution proposed here is to let users submit 35 36 SPARQL, but to a virtual endpoint (the Knora API) 36 37 rather than to the triplestore. In this way, the Knora 37 38 API can serve its main purpose of keeping research 38 39 data available for the long term without relying on 39 40 vendor-specific triplestore features, while providing 40 41 flexible, controllable, and consistent access to data. By 41 42 sending SPARQL queries to the Knora API, users can 42 43 access only the data they have permission to see, only 43 44 the current version of the data is served, and imple- 44 45 mentation details are hidden. Results are returned us- 45 46 ing a paging mechanism controlled by the Knora API. 46 47 By default, the query results are returned in a tree 47 48 structure in JSON-LD. This data structure is suitable 48 49 for web application development, while maintaining 49 50 machine-readability of the data as well as interoperab- 50 51 ility with other RDF-based tools. 51 14 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data
1 Appendix A. Ontology schemas 1 2 2 3 3 4 PREFIX knora-api:
1 rdf:object
1 }, 1 2 "beol:hasAuthorValue": { 2 3 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA/values/7ExuBcDbQZyRJRbAcORyKg", 3 "@type": "knora-api:LinkValue", 4 4 "knora-api:linkValueHasTarget": { 5 "@id": "http://rdfh.ch/0801/1PkbSo2nRIeOK9ISp6JSdg", 5 6 "@type": "beol:person", 6 7 "knora-api:arkUrl": { 7 8 "@type": "xsd:anyURI", 8 "@value": "http://ark.dasch.swiss/ark:/72163/1/0801/1PkbSo2nRIeOK9ISp6JSdgr" 9 9 }, 10 "rdfs:label": "Anders Johan Lexell" 10 11 } 11 12 }, 12 13 "beol:hasRecipientValue": { 13 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA/values/wCaspGWvS6SZXeuZy3h9MA", 14 14 "@type": "knora-api:LinkValue", 15 "knora-api:linkValueHasTarget": { 15 16 "@id": "http://rdfh.ch/0801/7z7sHo5aTLqSUeSXR14qpg", 16 17 "@type": "beol:person", 17 18 "knora-api:arkUrl": { 18 "@type": "xsd:anyURI", 19 19 "@value": "http://ark.dasch.swiss/ark:/72163/1/0801/7z7sHo5aTLqSUeSXR14qpgJ" 20 }, 20 21 "rdfs:label": "Le marquis de Condorcet" 21 22 } 22 23 }, 23 "beol:hasText": { 24 24 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA/values/im2jaDG_RKCx999ozN3RZg", 25 "@type": "knora-api:TextValue" 25 26 }, 26 27 "knora-api:textValueAsXml": "[...] Monsieur le Marquis [...]", 27 28 }, 28 "beol:title": { 29 29 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA/values/LWf9YstAQ4iq4CI1MmOzUA", 30 "@type": "knora-api:TextValue" 30 31 }, 31 32 "knora-api:valueAsString": "Annexe 1: Lexell à Condorcet, Saint-Pétersbourg, 2 (13) décembre 1775"32 33 }, 33 "knora-api:arkUrl": { 34 34 "@type": "xsd:anyURI", 35 "@value": "http://ark.dasch.swiss/ark:/72163/1/0801/25Ro4c5gSIioLstzJ25FiAC" 35 36 }, 36 37 "knora-api:hasStandoffLinkToValue": { 37 38 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA/values/aK3JZSkOR6StGyiaIn6Vlg", 38 "@type": "knora-api:LinkValue", 39 39 "knora-api:linkValueHasTarget": { 40 "@id": "http://rdfh.ch/0801/NbmhfOBlQoGbX3HwXuC3Tg", 40 41 "@type": "beol:person", 41 42 "beol:hasBirthDate": { 42 43 "@id": "http://rdfh.ch/0801/NbmhfOBlQoGbX3HwXuC3Tg/values/vtlhBetvSRONLutapTKcaw", 43 "@type": "knora-api:DateValue", 44 44 "knora-api:dateValueHasCalendar": "GREGORIAN", 45 "knora-api:dateValueHasEndDay": 15, 45 46 "knora-api:dateValueHasEndEra": "CE", 46 47 "knora-api:dateValueHasEndMonth": 4, 47 48 "knora-api:dateValueHasEndYear": 1707, 48 "knora-api:dateValueHasStartDay": 15, 49 49 "knora-api:dateValueHasStartEra": "CE", 50 "knora-api:dateValueHasStartMonth": 4, 50 51 "knora-api:dateValueHasStartYear": 1707, 51 T. Schweizer and B. Geer / Gravsearch: transforming SPARQL to query humanities data 17
1 "knora-api:valueAsString": "GREGORIAN:1707-04-15 CE" 1 2 }, 2 3 "knora-api:arkUrl": { 3 "@type": "xsd:anyURI", 4 4 "@value": "http://ark.dasch.swiss/ark:/72163/1/0801/NbmhfOBlQoGbX3HwXuC3Tg_" 5 }, 5 6 "rdfs:label": "Leonhard Euler" 6 7 } 7 8 }, 8 "rdfs:label": "Lexell à Condorcet", 9 9 "@context": { 10 "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", 10 11 "knora-api": "http://api.knora.org/ontology/knora-api/v2#", 11 12 "rdfs": "http://www.w3.org/2000/01/rdf-schema#", 12 13 "beol": "http://api.dasch.swiss/ontology/0801/beol/v2#", 13 "xsd": "http://www.w3.org/2001/XMLSchema#" 14 14 } 15 } 15 16 16 17 Listing 3: Gravsearch response in the complex schema 17 18 18 19 19 20 { 20 21 "@id": "http://rdfh.ch/0801/25Ro4c5gSIioLstzJ25FiA", 21 22 "@type": "beol:letter", 22 23 "beol:creationDate": { 23 "@type": "knora-api:Date", 24 24 "@value": "JULIAN:1775-12-02 CE" 25 }, 25 26 "beol:hasAuthor": { 26 27 "@id": "http://rdfh.ch/0801/1PkbSo2nRIeOK9ISp6JSdg" 27 28 }, 28 "beol:hasRecipient": { 29 29 "@id": "http://rdfh.ch/0801/7z7sHo5aTLqSUeSXR14qpg" 30 }, 30 31 "beol:hasText": "\n Monsieur le Marquis\n Ayant communiqué à Monsieur Euler [...]", 31 32 "beol:title": "Annexe 1: Lexell à Condorcet, Saint-Pétersbourg, 2 (13) décembre 1775", 32 33 "knora-api:arkUrl": { 33 "@type": "xsd:anyURI", 34 34 "@value": "http://ark.dasch.swiss/ark:/72163/1/0801/25Ro4c5gSIioLstzJ25FiAC" 35 }, 35 36 "knora-api:hasStandoffLinkTo": { 36 37 "@id": "http://rdfh.ch/0801/NbmhfOBlQoGbX3HwXuC3Tg" 37 38 }, 38 "rdfs:label": "Lexell à Condorcet", 39 39 "@context": { 40 "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", 40 41 "knora-api": "http://api.knora.org/ontology/knora-api/simple/v2#", 41 42 "rdfs": "http://www.w3.org/2000/01/rdf-schema#", 42 43 "beol": "http://api.dasch.swiss/ontology/0801/beol/simple/v2#", 43 "xsd": "http://www.w3.org/2001/XMLSchema#" 44 44 } 45 } 45 46 46 47 Listing 4: Gravsearch response in the simple schema 47 48 48 49 49 50 PREFIX knora-api:
1 1 2 CONSTRUCT { 2 3 ?person knora-api:isMainResource true . 3 ?person foaf:familyName ?familyName . 4 4 ?person foaf:givenName ?givenName . 5 } WHERE { 5 6 ?person a knora-api:Resource . 6 7 ?person a foaf:Person . 7 8 ?person foaf:familyName ?familyName . 8 ?familyName a xsd:string . 9 9 ?person foaf:givenName ?givenName . 10 ?givenName a xsd:string . 10 11 FILTER(?familyName = "Euler") 11 12 } 12 13 Listing 5: Gravsearch query using FOAF 13 14 14 15 15 16 Appendix B. A simple Gravsearch query 16 17 17 18 18 PREFIX example:
1 } 1 2 ORDER BY ?date 2 3 OFFSET ${offset} 3 4 4 5 5 6 6 7 Listing 7: A Gravsearch template 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 Appendix D. A user-generated query 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 PREFIX beol:
1 Appendix E. GUI widget 1 2 2 3 3 4 4 Figure 2. Advanced Search Widget 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 17 18 18 19 19 20 20 21 21 22 22 23 23 24 24 25 25 26 26 27 27 28 28 29 29 30 30 31 31 32 Appendix F. Searching for text markup 32 33 33 34 34 PREFIX knora-api:
1 [2] ISIDORE platform SPARQL endpoint. https://isidore.science/sparql. 1 2 [3] Europeana SPARQL endpoint. http://sparql.europeana.eu/. 2 3 [4] C. Allocca, A. Adamou, M. d’Aquin and E. Motta, SPARQL Query Recommendations by Example, in: 13th European Semantic Web 3 Conference (ESWC) 2016, Crete, Greece, 2016. http://oro.open.ac.uk/46757/. 4 4 [5] O. Bruneau, E. Gaillard, N. Lasolle, J. Lieber, E. Nauer and J. Reynaud, A SPARQL Query Transformation Rule Language: Applica- 5 tion to Retrieval and Adaptation in Case-Based Reasoning, in: ICCBR 2017: Case-Based Reasoning Research and Development, 25th 5 6 International Conference on Case-Based Reasoning, Trondheim, Norway, 2017. https://hal.inria.fr/hal-01661651. 6 7 [6] L. Rosenthaler, P. Fornaro and C. Clivaz, DASCH: Data and Service Center for the Humanities, Digital Scholarship in the Humanities 30 7 8 (2015), i43–i49, Issue suppl_1. doi:10.1093/llc/fqv051. 8 [7] S. Kirrane, A. Mileo and S. Decker, Access Control and the Resource Description Framework: A Survey, Semantic Web 8(2) (2017), 9 9 311–352. doi:10.3233/SW-160236. 10 [8] O. Hartig and B. Thompson, Foundations of an Alternative Approach to Reification in RDF, Computing Research Repository (CoRR) 10 11 (2014). http://arxiv.org/abs/1406.3399. 11 12 [9] T. Schweizer, S. Alassi, M. Mattmüller, L. Rosenthaler and H. Harbrecht, An Interactive, Multi-layer Edition Of Jacob Bernoulli’s Scientific 12 13 Notebook Meditationes As Part Of Bernoulli-Euler Online, in: Digital Humanities 2019 Conference Abstracts, Utrecht, Netherlands, 2019. 13 https://dev.clariah.nl/files/dh2019/boa/0115.html. 14 14 [10] D.D. McCarthy, The Julian and Modified Julian Dates, Journal for the History of Astronomy 29(4) (1998), 327–330. 15 doi:10.1177/002182869802900402. 15 16 [11] A. Grafton, Some Uses of Eclipses in Early Modern Chronology, Journal of the History of Ideas 64(2) (2003), 213–229. 16 17 doi:10.1353/jhi.2003.0024. 17 18 [12] GODOT, Graph of Dated Objects and Texts. https://godot.date/. 18 [13] E.A. Fellmann, Leonhard Euler, 19 19 Historisches Lexikon der Schweiz (HLS). https://hls-dhs-dss.ch/de/articles/018751/2005-11-22/. 20 [14] chronOntology, iDAI.chronontology. https://chronontology.dainst.org. 20 21 [15] PeriodO, A gazetteer of periods for linking and visualizing data. https://perio.do. 21 22 [16] DBpedia SPARQL endpoint. http://dbpedia.org/sparql. 22 23 [17] Wikidata SPARQL endpoint. https://query.wikidata.org. 23 [18] D. Rogers, The Enduring Myth of the SPARQL Endpoint. https://daverog.wordpress.com/2013/06/04/ 24 24 the-enduring-myth-of-the-sparql-endpoint/. 25 [19] GraphQL, GraphQL. https://www.howtographql.com/. 25 26 [20] HyperGraphQL, HyperGraphQL. https://www.hypergraphql.org/. 26 27 [21] S. Klarman, Querying DBpedia with GraphQL. https://medium.com/@sklarman/querying-linked-data-with-graphql-959e28aa8013. 27 28 [22] R. Taelman, M.V. Sande and R. Verborgh, GraphQL-LD: Linked Data Querying with GraphQL. https://comunica.github.io/ 28 Article-ISWC2018-Demo-GraphQlLD/. 29 29 [23] T. Ioannidis, G. Garbis, K. Kyzirakos, K. Bereta and M. Koubarakis, Evaluating Geospatial RDF stores Using the Benchmark Geographica 30 2, 2019. https://arxiv.org/abs/1906.01933. 30 31 [24] D. Calvanese, P. Liuzzo, A. Mosca, J. Remesal, M. Rezk and G. Rull, Ontology-based data integration in EPNet: Produc- 31 32 tion and distribution of food during the Roman Empire, Engineering Applications of Artificial Intelligence 51 (2016), 212–229. 32 33 doi:10.1016/j.engappai.2016.01.005. 33 [25] D. Calvanese, B. Cogrel, S. Komla-Ebri, R. Kontchakov, D. Lanti, M. Rezk, M. Rodriguez-Muro and G. Xiao, Ontop: Answering SPARQL 34 34 queries over relational databases, Semantic Web 8(3) (2017), 471–487. doi:10.3233/SW-160217. 35 [26] W3C, SHACL. https://www.w3.org/TR/shacl/. 35 36 [27] P. Seifer, M. Leinberger, R. Lämmel and S. Staab, Semantic Query Integration With Reason, The Art, Science, and Engineering of Pro- 36 37 gramming 3(3) (2019). doi:10.22152/programming-journal.org/2019/3/13. 37 38 [28] TEI-Consortium (ed.), Guidelines for Electronic Text Encoding and Interchange, Last updated on 13th February 2020. http://www.tei-c. 38 org/P5/. 39 39 40 40 41 41 42 42 43 43 44 44 45 45 46 46 47 47 48 48 49 49 50 50 51 51