Digital publications host a large amount of data that currently is not harvested, due to its unstructured nature. However, manually annotating these publications is tedious. Current tools that automatically analyze unstructured text are too ne-grained for larger amounts of text such as books. A workable machine-interpretable version of larger bodies of text is thus necessary. In this paper, we suggest a work ow to automatically create and publish a machine-interpretable version of digital publications as linked data via DBpedia Spotlight. Furthermore, we make use of the Everything is Connected Engine on top of this published linked data to link digital publications using a Web application dubbed \StoryBlink". StoryBlink shows the added value of publishing machineinterpretable content of unstructured digital publications by nding relevant books that are connected to selected classic works. Currently, the time to nd a connecting path can be quite long, but this can be overcome by using caching mechanisms, and the relevancy of found paths can be improved by better denoising the DBpedia Spotlight results, or by using alternative disambiguation engines.
Digital publications such as digital books (e-books) and online articles house
a vast amount of content. Meanwhile, the amount of published content is
rising more than ever, due to advancements in communication technologies. This
situation leads to a (harmful) information overload for end users [
Current systems for nding relevant publications are largely based on two
systems [
The contribution of this paper is twofold. First, we describe a system for the automatic creation of relevant tags using Natural Language Processing (NLP) techniques. Second, we apply these tags to a proof-of-concept that detects publications linked between two publications that are relevant based on their content.
In Section 1, we will review the state of the art and introduce some important relevant technologies. Afterwards, we present the two contributions in Section 2 and Section 3 respectively. These contributions are evaluated in Section 4, after which we conclude in Section 5. 1
In this section, we rst have a look at systems that create machine-interpretable representations of natural language text, and link these representations to the Semantic Web (Subsection 1.1). Second, we review the used and relevant technologies for creating our proof-of-concept (Subsection 1.2). 1.1
To link entities to Semantic data sources, these entities rst need to be
recognized in the text through Named Entity Recognition (NER). Then, a second
analysis is needed to disambiguate these recognized entities into places,
people, or other types (Named Entity Disambiguation or NED) [
GERBIL[
Digital books Digital books are usually distributed in a format so that they
can be read o ine. EPUB, version 3 [
A notable part of the EPUB speci cation is the speci cation of the EPUB
Canonical Fragment Identi er (CFI) [
Triple Pattern Fragments Triple Pattern Fragments are a way of hosting
and querying linked data in an a ordable and reliable way [
freme-project.eu/, respectively).
when hosting such servers compared to standard SPARQL endpoints4. Because
of the reliability of Triple Pattern Fragments servers, linked data applications can
be built on top of live endpoints, whereas the uptime of other query endpoints
is often not reliable enough to be used as back-end for linked data applications.
Everything is Connected The Everything is Connected engine (EiCE) is a
path nding engine [
Our overall goal is to provide a linked data endpoint that houses a relevant view
of the content of a digital publication. To this end, we use DBpedia Spotlight [
To solve these problems, we extract the text from the HTML les in the EPUB le, in reading order. Important to note is that correct handling of whitespace is important, as stripping the HTML tags could result in wrongly concatenated words, which in turn would result in wrong results from DBpedia Spotlight. Listing 2 shows how naively stripping the tags of a (valid) HTML document can introduce errors. Namely, the list [f; i; n; l] is wrongly concatenated with the word and, which results in the word nland, changing the original text You have following letters [f, i, n, l] and all are part of the latin alphabet to You have following letters nland all are part of the latin alphabet. For the stripped sentence, DBpedia Spotlight will return \Finland" and \Latin alphabet" as disambiguated results, of which \Finland" is wrongly identi ed. Thus, depending on the context (i.e., whether it is phrasing content or only ow content), additional whitespace should be added to the original HTML or not6.
After all text is extracted from the EPUB le, this text is split up into text
parts manageable by DBpedia Spotlight. If we wouldn't split up the text, the
4 99:999% uptime between November 2014 and February 2015 [
content in HTML5, and see https://github.com/bjdmeest/node-html-to-text for a possible HTML-to-text implementation. <p>You have following letters <ul><li>f</li><li>i</li><li>n</li><li>l</li></ul>and all are part of the latin alphabet. </p> after stripping: You have following letters finland all are part of the latin alphabet.
Listing 2. Whitespace should be taken into account when stripping the tags of an HTML document DBpedia Spotlight instance would need to analyze the entire text of a publication in one run, which could result in either server response time-outs or out-ofmemory errors. As DBpedia Spotlight only takes limited contextualization into account, this splitting up in sentences will have little to no e ect on the results of the NER and NED done by DBpedia Spotlight. For this paper, we split the text minimally on sentence boundaries, with a maximal substring length of 15007.
The \annotate"-function of DBpedia Spotlight { which recognizes entities to annotate and returns a single identi er for each recognized entity { returns a list of identi ers, which are sorted in order of appearance. We use this order to reconnect these results with the original HTML les. By comparing the original text of the detected concept with the words in the text nodes in HTML, in order, we can reconstruct the range of the original detection. We then generate the EPUB CFI of this range and use this CFI in the semantic representation of the content of the publication.
By making use of the NIF and ITS ontologies, we use well-de ned publicly available ontologies that are already being used in business environments. In our case, we used nif:sourceURL on the one hand to indicate the link between the detected range and the original book this range originated from, and itsrdf: taIdentRef on the other hand to indicate the DBpedia link that was detected from the text in this range (see Listing 3 for an abbreviated resulting semantic representation). 3
Based on the previously described methodology, we have provided an automatic way of describing the content of (digital) publications as linked data. This linked data is not meant to be granular, i.e., describe every sentence in the publication, 7 For each following chunk of text, we split o the next 1500 characters, and look for the last occurrence of a sentence boundary, which is the last dot (.), question mark (?) or exclamation mark (!). If no match is found, the full 1500 characters are used as next chunk of text. @prefix schema: <http://schema.org/> . @prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nifcore#> . @prefix itsrdf: <http://www.w3.org/2005/11/its/rdf#> . @prefix dbr: <http://dbpedia.org/resource/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . <http://www.gutenberg.org/ebooks/84.epub#book> a schema:Book . <http://www.gutenberg.org/ebooks/84.epub#epubcfi(/6/12!/4/2/4)> itsrdf:taIdentRef dbr:Chamois ; nif:sourceUrl <http://www.gutenberg.org/ebooks/84.epub> . <http://www.gutenberg.org/ebooks/84.epub#epubcfi(/6/2!/4/46[chap01 ]/16/42)> itsrdf:taIdentRef dbr:Chamois ; nif:sourceUrl <http://www.gutenberg.org/ebooks/84.epub> . <http://www.gutenberg.org/ebooks/84.epub#epubcfi(/6/12!/4/2/6)> itsrdf:taIdentRef dbr:Desert ; nif:sourceUrl <http://www.gutenberg.org/ebooks/84.epub> . ...
Listing 3. Sample abbreviated output of the entity extraction method that links the Gutenberg books with their detected concepts using the ITS and NIF ontologies. but it is meant to provide a high-level overview of the relevant concepts of a publication in an automatic and machine-interpretable way.
This extracted information is published using a Triple Pattern Fragments server8, from hereon called the books endpoint. Using the HTML interface of the books endpoint, you can explore the mentioned concepts per book. We use this published linked data set in our proof-of-concept: StoryBlink. Through StoryBlink, we enable the discovery of stories by linking books based on their content.
StoryBlink is a Web application that allows users to nd relevant books based on two books selected by the user. EiCE nds the paths between these two books, where the nodes are related books, and the links are built using the common concepts as detected in the books. 3.1
The data to feed the Web application was extracted from twenty classic books as found on Project Gutenberg. The resulted linked data was published as the books endpoint, used as endpoint for the Everything is Connected engine.
When opening StoryBlink9, the user needs to choose two books as endpoints. The Everything is Connected engine will then use the books endpoint to look for a path of books between the rst book and the second book (Figure 1).
Storyblink exploring stories through linked books
How are famous classics works connected to each other? Find out! First, select a starting book...
Select startpoint:
NotreDame De Paris Then, select an ending book...
Select endpoint:
Les Misérables
NotreDame De Paris
And now...
StoryBlink! War and Peace The Time Machine The Count of Monte Cristo, Illustrated A Journey to the Centre of the Earth
The War of the Worlds
Tarzan of the Apes Frankenstein; Or, The Modern Prometheus
Les Misérables Barry Lyndon Twenty Thousand Leagues Under the Seas: An Underwater Tour of the World
The advantage of using the EiCE is that this engine aims at nding relevant yet surprising links between concepts. This way, StoryBlink returns contentbased recommendations based on these books, without returning too obvious results. For example, recommending a publication because it is also of the type Book is not the desired result. The (semantic) commonalities between two linked books can easily be found using a SPARQL query as shown in Listing 4, and is also visualized in StoryBlink when clicking on a link between two books. These visualized commonalities allow the user to personally assess the relevancy between two books on a content level, e.g., one user can assess a book to be relevant because it mentions the same locations, whilst another user can assess another book to be relevant because it mentions the same religion.
SELECT DISTINCT * { </book1> ?predicate1 ?object .
</book2> ?predicate2 ?object . }
Listing 4. SPARQL query to nd the commonalities between two books. @prefix schema: <http://schema.org/> . @prefix nif: <http://persistence.uni-leipzig.org/nlp2rdf/ontologies/nifcore#> . @prefix itsrdf: <http://www.w3.org/2005/11/its/rdf#> . @prefix dbr: <http://dbpedia.org/resource/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix pg84: <http://www.gutenberg.org/ebooks/84.epub#> . pg84:book a schema:Book . pg84:book itsrdf:taIdentRef dbr:Chamois, dbr:Desert, ...
Listing 5. The extracted linked data can greatly be reduced.
The books endpoint as described above introduces performance issues, not only in reasoning time, but also in quality of the results: the EiCE returns a lot of paths, and takes too much time to do it. This has two causes: the fact that the data model uses a two-step link between a book and its concepts, and the fact that a lot of unimportant concepts are taken into account.
Two-step link The data model, as discussed in Section 2, invokes a two-step link between a book and its detected concepts. First, the book has a certain range, as de ned by its CFI, and second, this CFI references to a certain concept in DBpedia. However, when we want to provide a high-level overview of a digital publication, we do not care where in the book the concept was detected, but just that it was detected. We can thus cut the data model short as shown Listing 5. This not only greatly reduces the amount of needed triples, it also enables a direct link between a book and its detected concepts.
Keeping all detected concepts There are two issues with keeping all detected concepts within a book in the data set, namely that (i) the data set grows larger, and (ii) concepts that are detected only a few times are irrelevant for the highlevel overview of a book.
As the data set grows larger, the performance of the Everything is Connected engine becomes more troublesome. Indeed, when more data is available, the amount of potential paths found increases, and thus also the searching time of the path nding algorithm. And as this large data set contains a lot of irrelevant concepts, the path nding algorithm also returns a lot more irrelevant paths.
To improve on this, we only keep the top X% of mentioned concepts. As the initial analysis results kept all references of a detected concept, we can easily count the amount of mentions of a concept, and use those counts to only keep the most mentioned concepts. We keep the top 50% of mentioned concepts, as this is the ideal compromise between execution time and found paths (see Section 4).
Furthermore, we remove all Project Gutenberg speci c mentions. As these books all originate from Project Gutenberg, they all have an identical disclaimer at the beginning. Thus, all books have the concept Project Gutenberg detected. However, this link is irrelevant to the content of the book, which is why we remove all Project Gutenberg mentions out of the database.
The aformentioned two optimizations have been implemented in the nal proof-of-concept, running at http://uvdt.test.iminds.be/storyblink/. 4
The proposed methodology allows for automatic analysis and extraction of relevant metadata, alleviating the need for manual annotations. The Everything is Connected engine uses these semantic annotations with no preference for popular or unpopular works, and thus avoids the long tail e ect. However, the performance of StoryBlink is poor when taking into account all mentioned concepts, which is why we propose to only keep the top X% of all mentioned concepts. To nd a good cuto value, we evaluate the path nding algorithm in terms of time and amount of paths found, whilst varying this cuto value (Figure 2)10. Given that the amount of triples per cuto value rises exponentially, it is no surprise that the computation time also rises exponentially. In fact, the correlation between amount of triples taken into consideration and average path nding time is 99:45%. The number of paths found saturates around the 50% cuto value.
When we would keep all detected concepts, we see how the path nding algorithm reaches the 60s timeout value. This results in a calculation time of 60s with 0 paths found, which is why we see a clear decrease in found paths when we keep all detected concepts in the books endpoint. In Figure 2, we can see how the graph has a noticeable breakpoint at the 50% mark. We also see that, after that mark, there is very little gain in the amount of found paths. If we compare the maximum of found paths with the amount of found paths at the 50% mark, we see how 94:06% of all potential paths can be found in about one eight of the time, i.e., 5:28s.
Taking into account the large correlation between path nding time and amount of triples in the data set, we can calculate the linear regression between these variables, i.e., executionT ime(ms) = 2:2195 triples + 2194:7. Given that in the test data set there were on average 54:55 triples per book, we can compute that we can take into account at most 64 books when trying to nd a path with #paths 14 12 10 8 6 4 2 0 0 20 40 60 80 Amount of considered concepts (%) 100 60 a response time lower than 10s. This can be done by, e.g., picking 62 books at random out of a catalog besides the two already selected books. However, these calculations do not need to be done for every request, as the data set is a static data source. Therefore, caching (part of) the responses could in uence the response times greatly, thus allowing StoryBlink to take more books into account. 5
By using engines such as DBpedia Spotlight, it is possible to extract detected concepts from a digital publication, and as such, provide a high-level overview from the content of this publication. In this paper, we presented our methodology to achieve an automatic extraction and publication of detected concepts of a (digital) publication.
However, taking into account every detected concept harms the resulting data set, as unrelevant concepts are also taken into account. By extracting a simpli ed subset of all detection results, we were able to fuel a content-based recommendation system based on the Everything is Connected engine. This engine can connect digital publications with each other by trying to nd relevant yet surprising paths between two concepts. The result is a novel way of content recommendation, no longer tied to social recommendation systems, thus avoiding the long tail e ect.
The path nding algorithm takes on average 5:28s to nd all relevant books for a data set of 20 books, which will make our Web application usable for book catalogs of maximally 64 books. It is clear that this is not ready for real-life catalogs. However, this problem can easily be resolved by caching the results. As the data set is xed and not prone to a lot of change, this is a possible solution.
This work could be further improved as following. { The choice of keeping the top 50% of mentioned concepts biases the books endpoint towards common concepts. Future work is to compare this method with similar metrics that do not bias towards common concepts, such as term frequency-inverse document frequency (tf-idf). { Instead of selecting two books to nd a paths between them, StoryBlink could be adapted to start from only one book . This way, StoryBlink can become a recommendation system, suggesting linked books based on a starting book.
This implies making changes to the Everything is Connected engine.
{ DBpedia Spotlight could be replaced by other NER and NED engines, to
see how this in uences the perceived quality of StoryBlink. We can evaluate
how using, e.g., Babelfy [
Acknowledgements The research activities described in this paper were funded by Ghent University, iMinds, the IWT Flanders, the FWO-Flanders, and the European Union, in the context of the project \Uitgeverij van de Toekomst" (Publisher of the Future).