Free and open digital libraries have been gaining steady momentum as key resources to support practice in Digital Humanities. Project Gutenberg is one of the oldest repositories of such a kind. The DHTK Python library is able to retrieve content from Gutenberg through querying the RDF metadata that Gutenberg itself publishes regularly, however this process is hampered by said metadata constituting a dataset that lacks a documented ontology, is largely unlinked and signi cantly bloated with redundant RDF triples. In this paper we detail the processes that were put in place with the aim of improving ontology-based data access to Gutenberg via DHTK, including (a) bottom-up extraction of the Gutenberg Ontology; (b) cleanup, linking and shrinking of the Gutenberg metadata set; (c) refactoring and alignment of said ontology with common vocabularies and (d) incorporation of the enhancements into the DHTK access routines. Early results show that we were able to reduce the size of the Gutenberg metadata set by nearly 29% whilst linking it with Library of Congress datasets, DBpedia and others.3
Many elds of study in the Humanities, such as literature and history, are
increasingly relying on the availability of text corpora that have reached such a
status as to be published online and copyright-free [
Project Gutenberg6 is the longest-standing digital library of freely accessible
textbooks. Its contribution policy gives volunteers the freedom to choose the
encoding formats, layout and distribution packaging of the eBooks they upload [
The Digital Humanties ToolKit (DHTK) is a Python software library that
was created to ease the access and the exploitation of data and metadata for
the Humanities [
Despite the serialisation format, Gutenberg metadata do not constitute a full- edged linked dataset, lack an ontology that describes their schema, and present a number of issues that limit their usefulness as a medium for accessing Gutenberg content. Using this dataset, the DHTK Gutenberg module is still able to realise its core functionalities, but has to employ costly and aleatory heuristics at runtime to work around the nonstandard and unlinked nature of the underlying metadata. It would be ideal for DHTK to employ ontology-based data access (OBDA), by using a mediating ontology that describes textbook repositories in a standard way, and then exploiting its alignments with Gutenberg-speci c terminologies to parametrise the SPARQL queries that are wrapped into DHTK's Python API. This needs to be backed by an improved Gutenberg metadata set, which not only conforms to said ontology, but that is also as expressive as possible with respect to it, contains linked data and is no larger than necessary.
We have realised the work ow that makes OBDA possible for Project Gutenberg, with particular focus on DHTK and its functionalities for searching and exploring digital libraries and retrieving eBooks, or part of them, in a more standard, yet enriched, form than originally available. We extracted the Gutenberg metadata schema from the ground up, formalised it into an ontology and used it to query and analyse the metadata set to detect pitfalls. Arising issues were addressed through SPARQL transformations that eliminated blank nodes, materialised external alignments and performed other enhancements. The resulting changes to the schema were backported to the Gutenberg ontology, which was then modularised and reasoned upon. Finally, DHTK was adapted to query Gutenberg through using the general module of the ontology, taking alignments into account. This has produced a refactored, linked version of the Gutenberg metadata set that is reduced by nearly 29% in number of triples without loss of information, with alignments to external sources like Library of Congress and 6 Project Gutenberg, http://www.gutenberg.org/ DBpedia, and unstructured data made structured. It also produced a mediating ontology that DHTK can use for querying catalogs using standardised queries.
The rest of the paper is structured as follows: Section 2 describes the Gutenberg metadata and outlines the issues identi ed. Section 3 is an overview of the methodology for OBDA enhancement: its phases and their results are described in Sections 3.1-3.3. Section 4 provides pointers to implementations and related resources. Section 5 describes related work on Gutenberg and on digital libraries in general, before concluding with an insight into use cases and ongoing work. 2
Project Gutenberg does not provide a query service API for its metadata, but regularly publishes a downloadable RDF export7 for loading onto third-party triple stores. The RDF schema mostly covers the following: { contributors in various capacities (authors, editors etc.), with webpage links to language-speci c Wikipedia pages, or occasionally to other custom pages; { publishing metadata, relating primarily to when the eBook was rst published online by Gutenberg; { media types, formats and links to the corresponding downloadable resources; { cataloguing and structure metadata, such as eBook languages, the names of the Gutenberg collections { or bookshelves { an eBook belongs to, and the table of contents of some of the eBooks; { subjects and topics, loosely referencing the LCSH8 and LCC9 thesauri.
The Gutenberg metadata set is best assessed with four out of ve stars.10 Although available in RDF, the data URIs, when existing, are not externally linked as mandated by the 5-star model. The dataset presents a number of other issues, possibly owing to the age of the repository and the underlying database export not being tailored for data linking. Among them we note: 1. undocumented in-house RDFS classes and properties; 2. many blank nodes representing a small number of entities several times over, resulting in a much larger dataset than necessary; 3. links to the Library of Congress thesauri encoded as literals, not referencing subject headings by identi er, or referencing outdated headings; 4. eBook tables of contents being encoded as a single, nonstandard string literal; 5. non-dereferenceable entity URIs, e.g. for authors and agents in general. 7 Gutenberg catalog feeds, https://www.gutenberg.org/wiki/Gutenberg:Feeds 8 Library of Congress Subject Headings, http://id.loc.gov/authorities/ subjects.html 9 Library of Congress Classi cation, https://www.loc.gov/catdir/cpso/lcco/ 10 See the 5-star open data model, https://5stardata.info/
Gutenberg also maintains a curated online wiki,11 but only part of its content is re ected onto the RDF data: for example, the membership of an eBook in a bookshelf is present (and again, only via a blank node pointing to the bookshelf name), but not the hierarchy of bookshelves nor their grouping by language.
In di erent ways, these issues hinder programmatic access to the actual eBook content, be it ontology-based or not. The DHTK module for the Gutenberg catalog relies upon querying in SPARQL the dataset loaded onto a background RDF store, and then fetching the matching content from Gutenberg. However, it has to process a much larger dataset than it needs to be, using bespoke queries that are hard to adapt across repositories and computationally costly heuristics for retrieving book sections. The goal of this work is to analyse, refactor and enhance the Gutenberg metadata set so that it can lend itself to more streamlined processing by DHTK and other tools. In the following, we address issues 1 to 4. 3
To work properly, OBDA assumes the existence of (a) an ontology layer, (b)
a mapping layer and (c) a data source layer [
In-house terms were modularised into a separate, aligned ontology. OWL reasoning was applied to both, and the materialised inferences were loaded into a separate graph (second iteration of ontology and mapping layers). 6. Finally, DHTK queries were refactored to only use terms from the remaining, general ontology, taking inferences into account as well.
These steps, and the issues they address, are described in greater detail in Section 3.1 (steps 1-2), Section 3.2 (steps 3-4) and Section 3.3 (steps 5-6). 3.1
One advantage of OBDA is that it can be used to either (a) issue general SPARQL queries that take inferences into account and can be satis ed by many datasets, or (b) easily parametrise them so that they can be adapted to several datasets that use di erent, but aligned, terms for representing their data. To enable OBDA to a resource, the ontology that represents its data schema is needed, especially any alignments from nonstandard ontological terms in the target dataset to standard ones. The rst step was therefore to build from the ground up the ontology that represents Gutenberg in its original state. This process was also useful for the early detection of pitfalls in the data model.
Lacking a formal description of the in-house Gutenberg terms, the ontology was constructed out of exploratory SPARQL queries on the data themselves, having loaded the Gutenberg metadata onto a triple store with a SPARQL endpoint. Bottom-up schema extraction is made possible by Linked Data not enforcing database schemas. The queries used were adapted from those recommended by VoID for building dataset descriptions,1213 plus other queries to detect (subclasses of) the domains and ranges of properties as utilised in the dataset.
The ontology relies extensively upon terms from the Dublin Core nomenclature (dcterms) and uses classes generated in-house in the Gutenberg namespace (shortened to pgterms), with the addition of Library of Congress terms to indicate speci c contributor roles like editor or translator. Also, pgterms:ebook 12 See VoID legacy wiki at Google Code, https://code.google.com/archive/p/ void-impl/wikis/SPARQLQueriesForStatistics.wiki 13 See also Mark Wallace, Exploratory RDF SPARQL queries. SemApps (2015), http: //semapps.blogspot.com/2015/12/exploratory-rdf-sparql-queries.html is the only type of entities in the data with no incoming links, which allows the whole ontology to be extracted out of navigating the description of eBooks alone. The alignment process and result We leverage the adoption of Dublin Core by both Gutenberg and the DBpedia ontology to build the rst alignment layer. This involved two main linking processes: 1. between Gutenberg and Dublin Core terms; 2. between the terms obtained from the previous step and the DBpedia ones.
To aid comprehensibility, the Dublin Core term ontology was incorporated in the resulting OWL resource. This is freely available for research purposes.14 14 This version of the ontology was rst presented at EADH 2018, Galway, Ireland (unpublished). https://drive.switch.ch/index.php/s/jLV7LcC5m8bGwEP
We used the class-property relationships as extracted for the Gutenberg ontology to perform random sampling of the dataset using SPARQL. We sampled property usage (as object or datatype properties), named and blank nodes, URI patterns and literal values. We tackled the issues emerging from the analysis as follows.
have a large number of object property predicates whose objects are blank nodes. On top of that, most of these blank nodes are used for re-describing the same entities over and over. Blank node statistics can be extracted on a per-property basis by issuing the following exploratory query: Listing 1.1. Exploratory SPARQL query for grouping predicates with blank nodes. S E L E C T ( C O U N T ( D I S T I N C T ? b n o d e ) as ? c ) ? pin ? pout W H E R E { ? x ? pin ? b n o d e . ? b n o d e ? pout []
F I L T E R ( i s B l a n k (? b n o d e )) } G R O U P BY ? pin ? pout O R D E R BY ? pin
The results of this query tell us not only how many distinct blank nodes there are, but also the RDF predicates pout used for describing each. By multiplying c by the number of tuples where the incoming predicate pin is the same, we obtain the number of blank-node triples for each pin in Table 1 (second column).
We observed that each blank node is described by at most two predicates with no outgoing links: one is always rdf:value over a string literal; the other, when present, is a dcam:memberOf predicate15 that indicates the provenance of that value. The objects of this predicate are themselves DC vocabulary schemes. This hinted that the actual combinations of RDF values and provenance vocabularies may be less than the blank nodes used. Indeed, by counting the unique values for each blank property object, the gures of the third column of Table 1 emerged.
From the statistics in the table, the gure for dct:format is the most striking: nearly 2 million triples are used for describing as little as 55 di erent formats. 15 DCAM is a Dublin Core subset of terms for vocabulary descriptions. From the table as a whole, this means that over 2.5m triples are used for describing entities that could be described, potentially even more e ectively, with a largely lower number of triples, were those entities named with URIs. This is not an obstacle to OBDA per se, but still a serious problem of scale and a hurdle to data reconciliation that should be addressed.
The values of dct:format were all HTTP content types, i.e. combinations of MIME types and character sets: they were parsed, decomposed, refactored as instances of ContentType and modelled using the UWA16 and NIE17 vocabularies, which are able to model content types. For bookshelves we minted new URIs and linked them to automatically-generated corresponding Gutenberg Wiki URIs.
For the remaining blank nodes, their provenance predicate values suggested that they could be aligned with external datasets, which is discussed next. External Data Alignments Many provenance triples of blank nodes point to external authorities, such as IMT (media types), the Library of Congress or Dublin Core, which hinted that external links should be created when possible.
The seven distinct dct:type values matched Dublin Core types - as also indicated by their provenance value dcterms:DCMIType - such as Text, StillImage or MovingImage, and were easily transformed into the corresponding URIs. Likewise, language values were all ISO 639-1 and 639-2 codes and were converted to the corresponding Linked Data URIs as published by the Library of Congress.18
The values for dct:subject were less trivial to handle: according to their provenance triples, all the string values were taken from the Library of Congress Classi cation (LCC) or Subject Headings (LCSH). However in the case of LCSH ones the values were the heading titles, not their codes. In addition, they are largely outdated as many subject headings can no longer be found in the current LCSH thesaurus and older ones are no longer published by the LOC. We loaded the latest LCSH RDF dataset onto the same triple store as Gutenberg and performed string manipulation and matching over the heading titles, with a recall of 43%, whereupon we generated owl:sameAs links. Matching the obsolete headings will be part of our future work. Subjects from the LCC were converted directly using the LOC Linked Data URI scheme, however we note that the LOC is still working on turning their classi cation scheme into Linked Data, therefore only part of the generated URIs can be dereferenced at the time of writing.19
Alignments with DBpedia were carried out: (i) for authors, by refactoring
and cross-checking existing Wikipedia page links in Gutenberg; (ii) for eBooks,
using cascaded DHTK heuristics that match book titles and the aforementioned
author links. We refer to our previous work [
Listing 1.2. SPARQL triple pattern for listing book headings (after refactoring). ? book a p g t e r m s : e b o o k
; dct : t a b l e O f C o n t e n t s / rdf : m e m b e r / dct : t i t l e ? h e a d i n g Gutenberg maintains a single-level TOC for its eBooks; we therefore extracted the headings by mining the TOC values for recurring string patterns. This task was carried out programmatically, yet availing ourselves of string manipulation functions available in the Jena SPARQL engine. The task succeeded for 96% of the eBooks with a TOC, for which multiple headings were generated. This makes it possible for DHTK to retrieve sections of a book without resorting to its heuristics for text part detection, which are available but computationally expensive due to acting upon the texts themselves rather than the metadata.
By the end of the entire enhancement process, the refactored Gutenberg metadata set had been reduced by 2,439,332 triples, amounting to nearly 29% of its grand total, while at the same time adding links to external sources and structured versions of previously unstructured data, like content types and TOCs. 3.3
The ontology alignment and the enhancements applied to the Gutenberg metadata set entail changes to the schema used by DHTK for querying its metadata, however some of these changes (such as the usage of UWA and NIE for representing content types) are of interest for digital libraries in general, whereas others { such as pgterms-speci c axioms { make sense for Gutenberg only. We therefore refactored the ontology and alignment layers as follows: { The new ontology layer becomes a general-purpose ontology module that describes access to digital libraries in general (e.g. without Gutenberg terms). { The new alignment layer includes the mappings with pgterms classes and properties, plus the materialised inferences obtained by running the HermiT 1.3.8 reasoner over the general ontology and Gutenberg mappings combined.
This means that DHTK, as well as any other client, can now employ general queries that can be satis ed by multiple digital library metadata sets, without having to hard-wire all the queries in bespoke modules. So for example, the Gutenberg-speci c query that DHTK uses to list the available books by Moliere: Listing 1.3. Retrieval of an author's publications in Gutenberg (before treatment). SELECT DISTINCT ? book ? title WHERE { ? book rdf : type pgterms : ebook ; dct : creator pgagent :791 ; dct : title ? title } }
becomes, considering ontology and data alignments, this cross-dataset query: Listing 1.4. Retrieval of an author's publications across libraries (after treatment). SELECT DISTINCT ? book ? title WHERE { ? book rdf : type / rdfs : su bC la ss Of ? dbo : W r i t t e n W o r k ; dct : creator /^ owl : sameAs ? pgagent :791 ; dct : title ? title where pgagent is pre x for <http://www.gutenberg.org/2009/agents/>.
Note that, in order to capture all subclasses of dbo:WrittenWork, one should use the star operator * on rdfs:subClassOf instead of ?. This would add a signi cant computational overhead on the evaluation of the query: however, having loaded the materialised inferences (including subclass ones) allows us to use the zero-or-one operator instead, which has a negligible impact on query e ciency. 4
The outputs of the work described in this paper are publicly available. An open source project on GitHub groups the scripts and queries used for refactoring the Gutenberg dataset,20 as well as the ontology and alignment layers in the ont directory. The enhanced Gutenberg dataset { sans the DBpedia alignments, which are separate work { can be freely downloaded and used under the same conditions as the original.21
DHTK itself will be released as open source during 2020: its homepage22 will
be updated accordingly as this happens. In the meantime, a Web app named
WeDH,23 which allows the construction of custom corpora, has been made
available to demonstrate the functionalities of DHTK [
Access to Gutenberg's resources is a topic that arouses community interest, due to its wealth of cultural resources. Other works are worth mentioning in this regard, which aim to exploit the Gutenberg.org repository in a variety of ways. 20 gutenberg-ld, https://github.com/alexdma/gutenberg-ld 21 Gutenberg metadata (cleaned), temporary location: https://tinyurl.com/quvrx66 22 Digital Humanities ToolKit, https://dhtk.unil.ch/ 23 WeDH, https://dhtk.unil.ch/WeDH/. The following temporary credentials can be used: USER:demo@dhtk.unil.ch, PWD:DemoWeDH
GutenTag is an NLP-driven tool for digital humanities research that exploits
the Gutenberg corpus. The authors state that the tool exploits the Gutenberg
repository to automatically create corpora by using text part recognition
heuristics [
DHTK and the work presented here is a response to these shortcomings in one solution: to o er programmatic access to Gutenberg resources through a Python SDK, as well as an enrichment of these resources through the reconciliation and integration of data from the Linked Open Data Cloud. 6
In this paper, we described our processes of enabling ontology-based data access to Project Gutenberg. Our use case was for the bene t of our DHTK library, whose access routines were improved thanks to this work, however the outcomes are reusable for other use cases and can be applied in a similar fashion to other bigliographical resources. The retro tting of these enhancements to DHTK calls for particular attention, as one of the further improvements we have planned is the construction and automatic integration of a TEI26 export of the repository.
Another use case of interest to us is the automatic costruction of character
pro les in ction and drama, whose early outcomes are described in [