by Tobias Schweizer and Sepideh Alassi
1. Introduction
Bernoulli-Euler Online (BEOL) is a platform for early modern mathematical texts. BEOL presents the works and correspondences of Leonhard Euler and members of the Bernoulli dynasty. BEOL is funded by the Swiss National Science Foundation. In the scope of this three year project, only a small selection of texts could be considered. Following the end of the project, more material can be added reusing the developed functionality. BEOL is a prototype for a digital edition that is integrated in a virtual research environment so that research can be carried out on the platform. The developed functionality is generic and not limited to historical mathematical texts.
BEOL is being developed as part of a generic infrastructure that receives long term support from the Data and Service Center for the Humanities (DaSCH) in Switzerland. This infrastructure consists of various software components. Knora is a software framework for storing, sharing, and working on primary sources and data in the humanities. Data is stored as RDF in a triplestore. Knora makes this data available through its API, allowing for reading, creating and updating data without having to deal with the complexity of the internal representation of the data. Knora also supports several data exchange formats. The Knora base ontology defines basic types that can be used for project specific modelling. The BEOL GUI is based on Angular and Angular Material and makes use of modules from Knora-ui. Knora-ui provides software packages available on npm that communicate with the Knora API and deal with the basic data types defined in the Knora base ontology to search for and display data.
2. Representing a Digital Edition in RDF
2.1 Markup and Metadata
Texts and their markup are stored as RDF using a standoff approach. The markup is stored separately from the text, referring to ranges and positions of the text via start and end indexes. Markup is stored like any other data, reusing concepts from the Knora base ontology. Knora unifies the handling of metadata and markup.
With project ontologies, concepts in research projects can be modelled, e.g., a historical person that has a name (string), a lifespan (birth and death date) and other biographical information. Likewise, texts and their markup are included in this modelling approach.
Figure 1: Letter with standoff link
BEOL consists of several hundred letters that are represented in RDF. With RDF, the representation of this network of letters is quite natural, since representation of linked data structures is one of the strengths of RDF. Figure 1 shows a letter from BEOL that has an author, a recipient, a text, and a date. It is the first letter that Leonhard Euler sent to Christian Goldbach, on 13 October 1729 (Julian calendar). Both the letter’s author and recipient are expressed as references from the letter to resources representing those persons. Similarly, when the text of the letter mentions Daniel I Bernoulli it too is expressed as a reference to a resource of type person.1
The letter shown in Figure 1 is part of the BEOL graph. A person can be the author or recipient of many letters. With the representation in RDF, these relations are made explicit and can be queried and processed by machines. The Knora API provides ways to interact with RDF data over HTTP.
2.2 Accessing Information via the API
Knora provides an application layer to interact with the RDF data without having to deal with the complexity of the internal representation of the data in the RDF-triplestore. Furthermore, Knora provides versioning and permission control. With the Knora API, the contents of BEOL are made available as LOD.
The Knora API makes RDF data available in different serialisation formats. Our preferred format is JSON-LD, but also RDF/XML and Turtle are supported.2Resources such as a letter or a person are identified by an IRI. Given the IRI of a resource acquired, for example by doing a search, a representation of the resource can be obtained through a request to the resources route of the Knora API.
Listing 1: Representation of a letter serialised as JSON-LD
Download this code: letter.json
{
“@id”:”http://rdfh.ch/0801/letter-L001″,
“@type”:”beol:letter”,
“rdfs:label”:”L001 Original”,
“beol:creationDate”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/creationDate”,
“@type”:”knora-api:DateValue”,
“knora-api:dateValueHasCalendar”:”JULIAN”,
“knora-api:dateValueHasEndDay”:13,
“knora-api:dateValueHasEndEra”:”CE”,
“knora-api:dateValueHasEndMonth”:10,
“knora-api:dateValueHasEndYear”:1729,
“knora-api:dateValueHasStartDay”:13,
“knora-api:dateValueHasStartEra”:”CE”,
“knora-api:dateValueHasStartMonth”:10,
“knora-api:dateValueHasStartYear”:1729,
“knora-api:valueAsString”:”JULIAN:1729-10-13 CE”
},
“beol:hasAuthorValue”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/author”,
“@type”:”knora-api:LinkValue”,
“knora-api:linkValueHasTarget”:{
“@id”:”http://rdfh.ch/0801/Leonhard-Euler”,
“@type”:”beol:person”,
“rdfs:label”:”Leonhard Euler”
}
},
“beol:hasRecipientValue”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/recipient”,
“@type”:”knora-api:LinkValue”,
“knora-api:linkValueHasTarget”:{
“@id”:”http://rdfh.ch/0801/Christian-Goldbach”,
“@type”:”beol:person”,
“rdfs:label”:”Christian Goldbach”
}
},
“beol:hasText”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/text”,
“@type”:”knora-api:TextValue”,
“knora-api:textValueAsHtml”:”<div><p>Vir Celeberrime</p> … <a href=\”http://rdfh.ch/0801/Daniel-Bernoulli\”>…</a> … </div>”,
},
“knora-api:hasStandoffLinkToValue”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/standoffLink”,
“@type”:”knora-api:LinkValue”,
“knora-api:linkValueHasTarget”:{
“@id”:”http://rdfh.ch/0801/Daniel-Bernoulli”,
“@type”:”beol:person”,
“rdfs:label”:”Daniel I Bernoulli”
}
}
“@context”:{
“rdf”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#”,
“knora-api”:”http://api.knora.org/ontology/knora-api/v2#”,
“rdfs”:”http://www.w3.org/2000/01/rdf-schema#”,
“beol”:”http://dasch.swiss/ontology/0801/beol/v2#”,
“xsd”:”http://www.w3.org/2001/XMLSchema#”
}
}
Listing 1 above shows the JSON-LD serialisation of the letter depicted in Figure 1. For simplicity and readability reasons, not all the information is shown and the IRIs are human-friendly. The RDF triples representing the letter are organised hierarchically by the principle of resources and properties. The resource is represented by the top level structure of the JSON-LD document. Its properties are listed as members of the letter. Each property can have one or more values, depending on the cardinality defined in the ontology. Each value is of a certain type defined in the Knora base ontology. All ontology information can be obtained from Knora by making a request to the ontology route of the Knora API. E.g., the client can ask Knora about beol:letter to get the label for this resource class and cardinalities for its properties.
The text of the letter is sent directly to the client as HTML, so it can be displayed without further processing. The standoff link, however, is not only contained in the HTML as an ordinary hyperlink, but is also present as a value in the JSON-LD document. For that value, the client is informed about the target’s IRI, its label and its type. With the IRI of the target, more detailed information can be obtained from Knora. Currently, standoff markup is turned into XML or is transformed into HTML before serving it to the client. In the future, we would like to serve standoff in a native API format, rather than embed XML or HTML in the API response.
The response format as shown in Listing 1 is generic, i.e. it is also used for other types of responses, e.g., a search result. To provide the client with a powerful search, we have developed Virtual Graph Search (Gravsearch).3A Gravsearch query is a Sparql Construct query that is further processed by the Knora API, and then executed in the triplestore. In a Gravsearch query, the client can ask about the relation between resources and specify which information should be returned. The response is one or more resources with properties serialised as JSON-LD or another format supported by the Knora API.
Listing 2: Representation of a link with additional properties on the target resource serialised as JSON-LD
Download this code: Euler.json
{
“beol:hasAuthorValue”:{
“@id”:”http://rdfh.ch/0801/letter-L001/values/author”,
“@type”:”knora-api:LinkValue”,
“knora-api:linkValueHasTarget”:{
“@id”:”http://rdfh.ch/0801/Leonhard-Euler”,
“@type”:”beol:person”,
“beol:hasIAFIdentifier”:{
“@id”:”http://rdfh.ch/0801/Leonhard-Euler/values/iaf”,
“@type”:”knora-api:TextValue”,
“knora-api:valueAsString”:”(DE-588)118531379″
},
“rdfs:label”:”Leonhard Euler”
}
}
}
Listing 2 above shows the link from the letter resource to its author, as already shown in Listing 1. But in this case, the target of the reference has an additional property: the author’s IAF identifier. With Gravsearch, the client can specify that the link from a letter to its author and additional information about the author should be returned, while maintaining one generic format suitable for processing by clients, like a web browser.
2.3 Export to TEI/XML
TEI/XML is a widely accepted standard for electronically encoded texts in the humanities. Knora provides a functionality, so that resources with texts can be exported as a TEI/XML file.4 Given the configuration for a specific resource class – e.g., a letter from the BEOL project – a TEI/XML file can be automatically created from the RDF data. Two separate configurations have to be provided: one for the metadata – the header of the TEI/XML file – and one for the text itself – the body of the TEI/XML file as shown in Figure 2.
Figure 2: Export to TEI/XML
For the metadata, a Gravsearch query has to be provided that gets the necessary information from the triplestore. The response is returned as RDF/XML. The XML data is converted into the header structure by means of an XSL transformation that must also be provided. For the markup, a virtual mapping has to be provided in order to turn the standoff annotations into XML. This mapping can be different from the mapping that was used to create the standoff from the originally given XML. Also in this case, an XSL transformation is needed for post processing of the XML. Hence, TEI/XML markup can be created also if the original XML was not TEI/XML compliant. Most of the texts contained in the BEOL platform are the result of conversions: non XML sources like LaTeX or MediWiki markup were converted to XML before importing them into BEOL (Schweizer et al. 2017; Alassi et al. 2018). By mapping them all to the same standoff tags and properties, they are standardised, and so is their conversion to TEI/XML.
Listing 3: Support of correspSearch
Download this code: correspDesc.xml
<correspDesc ref=”http://rdfh.ch/0801/letter-L001″>
<correspAction type=”sent”>
<persName ref=”http://d-nb.info/gnd/118531379″>Euler, Leonhard</persName>
<date when=”1729-10-24″/>
</correspAction>
<correspAction type=”received”>
<persName ref=”http://d-nb.info/gnd/118696149″>Goldbach, Christian</persName>
</correspAction>
</correspDesc>
Listing 3shows part of the header of the TEI/XML document representing the first letter Euler sent to Goldbach. With Gravsearch, information about the letter’s author, recipient and date was queried and the resulting RDF/XML was transformed into the structure required by correspSearch. Knora automatically converted the date given in the Julian calendar into the Gregorian calendar. This is possible because Knora stores dates in a calendar independent format.
3. BEOL GUI Application
3.1 BEOL GUI
The BEOL GUI is an Angular application developed to present mathematical texts on the web. It consists of a landing page which gives an overview of the available editions and templates for properly displaying different types of resources such as letters or persons. For each resource type, the appropriate template is chosen by the routing service of the application.
Figure 3: First letter from Leonhard Euler to Christian Goldbach
Figure 3 shows a graphical representation of the JSON-LD in Listing 1. Links to the author and recipient of the letter are rendered as hyperlinks and lead to a detailed view of the person when clicked. The text is returned by the Knora API as HTML and is injected into the DOM. Standoff links to endnotes, persons and bibliographical information are rendered as hyperlinks. Persons and bibliographical references appear as icons. Mathematical formulae are set in LaTeX and embedded in the HTML. They are rendered directly in the browser using MathJax. The metadata section on the left shows additional information about the letter, such as links to the English translations or the repertorium number.5 By means of a special route in the BEOL application, the repertorium number can be resolved to the IRI identifying the letter in Knora. This is useful to allow third-party repositories like Early Modern Letters Online to refer to resources on the BEOL platform without having to know the underlying IRI. In this way, the URL “https://beol.dasch.swiss/leoo/715” is resolved to the actual resource IRI of the letter by making a call to the Knora API.
In general, each Knora resource can be cited by means of an ARK identifier. The ARK identifier is resolved by a dedicated service and redirected to the Knora resource.6
3.2 Knora-ui
Knora-ui is a collection of different modules that are used in the BEOL GUI and other Angular applications. They facilitate the integration with the Knora API and offer standard ways of displaying information. The BEOL GUI uses modules from Knora-ui wherever possible. However, in project-specific cases, custom modules had to be written. Knora-ui is divided into different packages such as @knora/core, @knora/viewer, @knora/search, etc., as shown in Figure 4. These packages are available on npm. @knora/core offers methods to request a resource from the Knora API and to turn the JSON-LD document into a TypeScript structure that can be used in an Angular application. Likewise, information about project ontologies can be obtained using @knora/core. @knora/viewer deals with the rendering and displaying of the value types defined in the Knora base ontology that can be used in project specific ontologies such as the BEOL project. Figure 3 shows the rendering of the creation date of a letter in the BEOL application using @knora/viewer. @knora/viewer converts the serialised date as shown in Listing 1into a human-friendly HTML representation.
Figure 4: Knora-ui modules
@knora/search provides different elements to configure the search panel used in the application. For complex searches, @knora/search provides a graphical widget that allows for specifying an extended search that is turned into a Gravsearch query. The Angular Material Datepicker is part of that widget, so users can search for dates. In the case of BEOL, searches for Gregorian and Julian calendar dates are required. Since Angular Material did not support calendar conversions, we added this functionality in a series of pull requests. (Schweizer 2018)
4. Developing in a Generic Infrastructure
Knora and Knora-ui are part of the infrastructure of the Data and Service Center for the Humanities (DaSCH) in Switzerland. The main goal of the DaSCH is to ensure the long term availability of research data in the humanities. Due to project-based funding policies, research data is likely to end up in repositories, without a strategy for long term preservation after a project has ended. The DaSCH aims to provide both an institutional and technical basis to prevent research data and its applications from vanishing.
Unlike a conventional digital archive, data and functionality should be available continuously (keep alive archive). BEOL was begun with that goal in mind, and hence was developed as part of the infrastructure of the DaSCH. Project-specific needs were generalised and implemented in a generic way so that other projects can also benefit from the functionalities that were developed, and vice versa.
Carrying out a research project like BEOL as part of generic infrastructure has the advantage that, at the beginning of the project, there was already a software framework that could be used. Also, long term support is guaranteed through the DaSCH. Developing new functionality in a generic environment, however, is a rather slow-moving and demanding task. Both standoff and Gravsearch are developments that originated in the context of BEOL and then became part of Knora and Knora-ui. The specific, and sometimes rather limited, requirements of a BEOL were implemented in steps, so that new functionality became available at an early stage of the project while being further developed as part of the infrastructure of the DaSCH. The new developments are also used by projects other than BEOL. This broader usage lead to better stability of the software and the extension of its functionality.
This approach ensures that the contents of the BEOL platform will be available over the long term in a functional state. Also, future projects can reuse the contents and add to them, as well as develop new functionality.
5. References
Alassi, Sepideh, Tobias Schweizer, Martin Mattmüller, Lukas Rosenthaler, and Helmut Harbrecht. 2018. ‘A Digital Edition of Leonhard Euler’s Correspondence with Christian Goldbach’. In Digital Humanities 2018 Conference Abstracts, viewed 1 February 2019, <https://dh2018.adho.org/a-digital-edition-of-leonhard-eulers-correspondence-with-christian-goldbach>.
Schweizer, Tobias. 2018. ‘Datepicking Beyond the Gregorian Calendar’, viewed 1 February 2019, <https://blog.angular.io/datepicking-beyond-the-gregorian-calendar-7f3e76a1bdb8>.
Schweizer, Tobias, Sepideh Alassi, Martin Mattmüller, Lukas Rosenthaler, and Helmut Harbrecht. 2017. ‘Integrating Historical Scientific Texts into the Bernoulli-Euler Online Platform’. In Digital Humanities 2017 Conference Abstracts, 585–87, viewed 1 February 2019, <https://dh2017.adho.org/abstracts/147/147.pdf>.
- Similar to metadata, texts can contain references to other resources. Such references are represented as direct statements, so-called “standoff links”. Knora ensures that the target of a reference exists when the reference is created. As an optimisation for querying, the reference is not only expressed from the text to the person resource via “knora-base:standoffTagHasLink”, but also from the letter resource as a standoff link. Standoff markup is created from XML which is sent to the Knora API (see Knora documentation -> Knora general documentation -> Introduction -> Standoff/RDF Text Markup). From standoff markup, the originally submitted XML can be recreated when requested from Knora. The relation between XML elements and attributes and standoff entities is expressed in a custom mapping (see Knora documentation -> Knora general documentation -> Knora API v2 -> XML to Standoff Mapping in API v2). For different XML document types, specific mappings have to be created. In these mappings, standardised or project-specific standoff tags and properties can be used. Every standoff tag can have one of the types offered by the Knora base ontology such as an internal link (as described above), a date, integer or floating point number etc. Whenever such a data type is used, the data has to be submitted in a format required by Knora, in addition to its representation in the text.
- Knora documentation -> Knora general documentation -> Knora API v2 -> Introduction: Using API v2
- Knora documentation -> Knora general documentation -> Knora API v2 -> Gravsearch: Virtual Graph Search
- Knora documentation -> Knora general documentation -> Knora API v2 -> TEI/XML: Converting Standoff to TEI/XML
- The repertorium number is a unique number identifying each letter of the Euler correspondence.
- Knora documentation -> Knora general documentation -> The Knora APIs -> Knora API v2 -> Resource Permalinks