Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 60 Abstract: This contribution tracks and analyzes the life cycle of the Book of the Dead as a digital project and a rather complex research resource. It gives an account of how the digital archive “Das altägyptische Totenbuch – Ein digitales Textzeugenarchiv” was constructed in the context of the digitization efforts of the Academy for Science of North Rhine-Westphalia. From the beginning, the design of the archive has factored in a life of the digital archive beyond its funding period and has sighted to create a sustainable information resource. The main issues to be discussed here are what experiences have been made with sustainability, use and reuse of the Book of the Dead archive since the official end of the project in December 2012, with a focus on conceptual, technical and organizational aspects. The lessons learned can be of interest for future undertakings in the creation of XML and web-based digital platforms in Digital Classics and beyond. In a nutshell, they are: (a) the importance of wary technological choices in an initial phase cannot be underestimated, (b) the application and presentation layers of a digital resource, if present, are an essential part of it, (c) a certain degree of commitment from the research community and funding bodies alike is indispensable for maintaining a web-based complex Digital Humanities resource. 1. The Project The Old Egyptian Book of the Dead (BoD) is a collection of c. 200 magic spells which can be found in varying selections and combinations on different objects such as papyrus rolls, linen bandages used in mummification, palls, coffins, temple or tomb walls and other grave goods. The spells were intended as to assist the journey of a deceased person through the underworld, at the judgement of the dead and in the transition to the afterlife. In the paradigmatic case, the small texts form a book on papyrus, with the single spells written in hieroglyphs or hieratic script and/or illustrated by so called vignettes. Such a book was composed for and dedicated to a particular person and showed a more or less canonical structure and order of texts through the long period from the New Kingdom to the Roman times (c. 1550 BC to c. 300 AD). As one of the central sources for the study of Egyptian religion and funerary culture, the BoD has long been an important topic in Egyptology. In the early 1990s, a team led by Ursula Rößler-Köhler at the University of Bonn, Germany, started a research project (BDP) to collect and document all known witnesses.1 Initially funded by the German Research Council, it became a long-term project of the Nordrhein-Westfälische Akademie der Wissenschaften / North Rhine-Westphalian Academy of Sciences (AWK) lasting until 2012. Some years before the foreseeable end of funding, it became clear that the only reasonable way to publish the 1 The results of the project were principally published in the two series HAT and SAT, for editions of the BoD manuscripts and for research studies on the subject, respectively Rößler-Köhler (1995) and Rößler-Köhler (1998). The original project website is available at https://www.totenbuch-projekt.uni-bonn.de/. The life cycle of the Book of the Dead as a Digital Humanities resource Ulrike Henny, Jonathan Blumtritt, Marcel Schaeben & Patrick Sahle https://www.totenbuch-projekt.uni-bonn.de/ Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 61 collected knowledge and the outcomes of research would be an online database. Printing such an extensive metadata and image archive in its entirety would simply have been impossible. For this reason, the Academy granted additional funds for two years in order to combine the ongoing research in the subject with a Digital Humanities (DH) track.2 The primary goal of this collaboration was to secure the results of the research conducted over a period of nearly 20 years by the Egyptologists involved in the project and to make them publicly available in a topical and highly useful manner. But, as it is often the case, such practical goals have had more far-reaching effects, and it remains to be determined whether they lead to a more fundamental change in the setup and methodology of research. But at the outset, the assignment was clear: to transform a given archive of knowledge on the BoD into a sustainable digital resource that is comprehensive, rich in information, easy to use and stable far beyond the lifespan of the funded research project. The original archive contained a bibliographic database intended to be comprehensive as well as descriptions of and documentation for c. 3000 objects, comprising in many cases photographic or microfilm images of these objects. 2. (Re)Birth: the Book of the Dead as a digital resource 2.1 Data model, formats and conversion Data about the BoD had already been gathered in digital form within the long-term research project at the University of Bonn. General descriptive information had been stored in a FileMaker database and bibliographic data in a Citavi instance. However with respect to the characteristics of the objects to be described, the choices of data model and software had been made rather arbitrarily, without being rooted in a formal education in database modeling. The resulting structure and usage of the databases did not follow the underlying relational model in a strict way, but gradually accrued from the daily needs of the project. The first step towards the creation of a digital resource in a narrower sense was therefore to remodel the data. The goal was to preserve as much as possible of the existing data structure. At the same time, it was decided to use XML as the underlying data model of the Book of the Dead digital archive (BDA), and this entailed a significant change from a relational to an hierarchical data structure using markup. Most notably, the objects carrying the BoD spells were reorganised from flat, single database entries – where each part of an object was described separately – into historical full objects (Gesamtobjekte) which could consist of several actual partial objects (Teilobjekte). In this way, redundancy of information common to fragments of the same original object such as dating or place of origin could be avoided. Moreover, the original full object became the basic concept of the new data model, independent of its material fate and the question whether it is now preserved as a complete, fragmented or incomplete carrier of textual and visual material. In the process of reorganisation, the BoD object records were aligned with data sets of the Trismegistos database.3 In some cases, this resulted in joining objects previously considered as separate entities. 2 At that time, the Bonn Egyptologist team comprising Rita Lucarelli, Florence Albert, Annik Wüthrich, and Felicitas Weber was led by Marcus Müller while the DH team at the Cologne Center for eHumanities (CCeH), University of Cologne, con- sisted of Patrick Sahle, Ulrike Henny, Jonathan Blumtritt and Franz Fischer. Recently, Marcel Schaeben has worked on an update of the database underlying the digital archive which is hosted at http://www.totenbuch.awk.nrw.de/. The BoD as a DH project has previously been presented on the following occasions: Sahle/Henny (2012a), Sahle/Henny (2012b), Sahle/ Henny (2013a), Sahle/Henny (2013b), Henny (2013), and Legowski (2015). 3 Cf. Depauw/Geldorf (2014) on Trismegistos in general. Trismegistos provides unique and stable identifiers for texts from the ancient world. http://www.totenbuch.awk.nrw.de/ Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 62 In addition to the remodeling of the basic entities, fields describing properties of the objects were developed and further differentiated. Where possible, narrative descriptions that did not provide any additional value were resolved into a more explicit structure of XML elements with attributes and simple text values as content. Where appropriate, controlled lists of values were created to avoid inconsistencies as, for example, variation in spelling. The controlled lists were added to a separate XML file which functioned as a central knowledge base. The follo- wing figure gives a basic, non-comprehensive overview of the data model for a BoD object: Refining the data model proved to be especially fruitful for the description of the object’s con- tents. In the original practice, the sequence of spells found on an object was written down as a single string, e.g. “1: rto: Tb 15 – 22 – 25 – 26 – 1, vso: ? 2: rto + vso: Tb 1 4: Tb 102 8: rto: Tb 26 – 27; vso: Tb 2 – 3 – 5 – 6.”4 In the new model, the string was resolved to a sequence of spell and lacuna elements, each spell element containing just one spell or vignette name and the lacuna elements left empty. Because of the complexity of the original spell sequence string, it has been kept alongside the dissolved content description to make the remodeling transparent at this critical point. Making the structure of the books explicit, i.e., to mark up the components of the sequence of spells and vignettes, was the precondition for a computational and analytic approach to the material. Similarly, in case of the spells a canonical list was added to the central knowledge base and mapped to the instances of spells witnessed on the objects. Likewise, other levels of description such as places of origin, current locations and institutions, epochs and periods for the dating of objects, etc. were controlled. Besides the control and regulation of values, the knowledge base had the function of being the anchor to which external information (encyclopedic knowledge) could be attached (e.g. geographical coordinates to place names or date specifications to names of historical epochs). Notably, translations of the spells stemming from the academy project 4 Cf. Müller et al. (2012b). Figure 1: Basic structure of the data model for a BoD object. Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 63 Altägyptisches Wörterbuch and available via the platform Thesaurus Linguae Aegyptiae5 have been added to the knowledge base. In this way, the knowledge base can thus be exploited for networking (interconnection of data in the project itself, linking of project data to external data, integration of external information into the project, support of external tools and services) and as a basis for layers of presentation and analysis. The third main component of the BDA data model, besides the objects and the knowledge base, is the images of the text bearing objects. Egyptologists in the project had acquired existing images both from museums, and in part, the images were obtained by photographing and scanning reproductions found in secondary literature. In total images were obtained from 2,245 of the 2,992 objects. It was a goal to keep the administration of images simple, so the image metadata was attached directly to the object descriptions as can be seen in Figure 1. Each image was assigned to one of the user groups “guest”, “community”, “project” or “admin”, in order to allow for a detailed access control, as some parts of the graphical material are accessible only for registered users who have accepted the terms and conditions. Of the 21,684 images, 94 are open to the public, 20,701 are only accessible to registered users and 889 only to project members. It was decided to use a custom, local XML schema6 but to offer the data in two standardised ex- port formats: OAI Dublin Core7 and EpiDoc8. The local XML dialect permitted the expression of characteristics and relations specific to the objects of study without the need to compromise and possibly lose information coming from the original databases. It also meant that the poten- tial of the new data model to capture information internal and external to the project as desired was not limited, especially with respect to spell sequences and object-part relations.9 The process of converting the data so as to conform to the new model was automated as much as possible. XML exports of the FileMaker and Citavi databases were generated and processed further with XSLT. The images were batch-processed with IrfanView to produce derivative formats suitable for a web presentation. Much of the refinement of descriptive categories and values was done in a semi-automated, iterative process, where data reports stating which part of the data could not be converted automatically were created by the DH team and dealt with by the Egyptologists.10 5 Cf. BBAW (2014), http://aaew.bbaw.de/tla/index.html. Also inside the project itself, the knowledge base has been used to add information which goes beyond the single object descriptions, for example an additional index of motifs which clas- sifies, lists and depicts types of motifs that occur on vignettes, as well as links to the objects that witness them. Cf. Müller et al. (2012c). 6 Cf. Müller et al. (2012d). 7 A metadata format suggested to be used when implementing the Open Archives Initiative Protocol, cf. Lagoze et al. (2005). 8 A subset of the Text Encoding Initiative’s standard TEI, used for the encoding of ancient documents, cf. Elliott et al. (2011–2014). 9 The direct use of EpiDoc was considered but not pursued because the archive consists of complex object descriptions and not of texts and editions thereof. On the one hand, EpiDoc would not have been used to full capacity regarding the possi- bilities for encoding texts; on the other hand, it would have been necessary to extend the TEI header to suit the extensive metadata. 10 A special task consisted in the conversion of characters. In the original project, a traditional non-Unicode font had been used for transliterations, which in the object descriptions appeared for example in names of the book’s owners and relati- ves. In the course of data conversion, the transliterated characters were converted to Unicode characters. http://aaew.bbaw.de/tla/index.html Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 64 2.2 Technical framework Ultimately, the basic choices made for the technical framework of the digital archive where a consequence of the decision to use XML as a data model. Because the goal was to build a rich and interactive digital platform for the web, with HTML as the markup language, it was advisable to use technologies which would facilitate as much as possible the interplay between the underlying data and the presentational format. The X-technologies were an obvious choice because the path from XML to XHTML is straightforward with the help of standards like XPath, XSLT and XQuery11 which have been devised precisely for the retrieval and transformation of XML data without the need to convert the data back and forth between different kinds of formats. In addition, these standards are easy, text-based, human- as well as machine-readable and, as such, offer a promising solution to the problem of long-term accessibility and usability of the data. As they are, the basic XML standards can be used directly to construct web pages. They might not suffice, however, for the building of an application that is dynamic inasmuch as the content is not simply delivered “as is” but as a response to how users engage with the platform. Second, it was a goal to create a system that could be updated by members of the community even after the end of the project, because it was clear that the launch of the digital archive, planned for February 2012, would predate the overall end of the long-term research project by only nine months. In other words, the system had to support changes and updates of the data which could be made not only by non-technicians but also by non-project members. It became necessary to turn to a database management system with support for user administration, simultaneous access by multiple users, updates and versioning of the data. With their ability to ensure and facilitate the model-related and technical integrity of the platform, native XML databases were considered an intelligent option. At the time of decision, two of the Open Source candidates were BaseX and eXistdb.12 It was decided to use the latter because there were no striking arguments in favor of one or the other and because colleagues from other academies and the University of Cologne (particularly the Monasterium project13) had some experience with it. According to Siegel and Retter, eXist is, amongst other things, a “NoSQL document database for XML and binary (including text)”, a “web server for consuming and serving documents”, a “web application platform”, and a “document creation and capture platform (XForms)”.14 It is thus possible to store XML files as well as other types of data in the database: eXist is not just a database but includes its own web server and various programming interfaces.15 XQuery scripts residing in the database can be executed directly via requests from the browser. This means that it is possible to construct one package including the data and the application that can be stored in the database, run with the eXist server and can (at least in theory) be exported and migrated as a whole if necessary. Figure 2 provides an outline of how eXist was used in the technical framework of the BDA: 11 XPath, XSLT and XQuery stand for “XML Path Language”, “Extensible Stylesheet Language Transformation” and “XML Query Language”. See W3C (2007), https://www.w3.org/standards/xml/ for further information. 12 See Siegel/Retter (2014) for a comprehensive introduction and account of eXist and Grün (2011) on baseX. 13 Monasterium.net is a collaborative and virtual archive which, at least to date, is built on eXist, see ICARUS (2017), http:// monasterium.net/mom. Krah (2009) and Heinz (2010) introduce the archive, but do not broach the issue of technological choices. 14 Siegel/Retter (2014), p. 3. 15 E.g. HTTP REST and WebDAV. https://www.w3.org/standards/xml/ http://monasterium.net/mom http://monasterium.net/mom Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 65 Figure 2: Outline of the technical framework behind the BDA. As can be seen in the figure, the digital environment of the BDA resides completely in the X-world: underlying XML data, an eXist database as the backbone and XQuery, XSLT and XForms as processing methods for creating the user interface. An ingoing request is handled by the eXist controller that rewrites URLs and passes queries on to the central HTML template managing the website layout. From there, calls go to XQuery and XForms modules and func- tions to lookup data and produce results that are passed on to the client in response. The XML data is organised into different collections that are interrelated: objects, knowledge, bibliogra- phy and project information. Information that is more static and rarely updated is organised in pre-generated static pages. JavaScripts and CSS stylesheets used for design and functionalities of the web application are included via the template and through the eXist-internal XForms implementation BetterFORM. All in all, the only kind of data in the BDA that does not reside inside eXist are the image files; these are organised in a separate file system and linked to the object descriptions. Beyond the usage of web application building blocks which are directly included in eXist, the Google Chart API16 and the Pelagios API17 were used to support visua- lisations, linkage to project-external data and the use of third-party widgets in the web pre- sentation. The W3C standard SVG18 was used to produce visualisations that went beyond the capabilities of the Google Chart API. In the BDA, forms play a special role in supporting user activities. The platform was designed to include a search form called browsing that is always visible on every page and looks up object descriptions immediately, whenever the user changes the search criteria. In addition, a special search form is provided for owners of the books and their relatives. Moreover, forms are needed to support both the addition of new data to the archive, and changes to existing data, in particular object descriptions, bibliography entries, user registration and administration data. All of the forms are complex. In case of the search forms, they are complex because they allow 16 Cf. Google (2017), https://developers.google.com/chart/. 17 See Pelagios (2017a), https://github.com/pelagios/peripleo. “Peripleo” is a new name for the former Pelagios API. 18 Scalable Vector Graphics, an XML vocabulary for vector graphics. https://developers.google.com/chart/ https://github.com/pelagios/peripleo Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 66 for the combination of several kinds of search criteria, e.g., a specific place of origin with certain spells and a free search term. The search criteria might be hierarchically organised and in some cases (spells and vignettes, for example) the number of search fields is not predetermined. Regarding the object description editing forms, the complexity of nearly the entire underlying data model had to be taken into account. Where values were controlled in the knowledge base – such as the canonical names of spells – mappings were necessary to connect the clean list shown to the user with the untidy object description entries. Finally, the interrelations between the different types of data (object descriptions, knowledge, bibliography, user data, images) had to be taken into account in the forms. eXist comes with two XForms implementations: XSLTForms and betterFORM.19 For the BDA, betterFORM was chosen to be used for the development of the aforementioned search and input forms because, at the time, its implementation of the XForms standard seemed more complete than that of XSLTForms and it was more widely used. The choice of betterFORM had some consequences: internally, betterFORM uses the JavaScript library Dojo Toolkit.20 At the time of development, it was not foreseeable that the dependencies between specific versions of eXist, betterFORM and Dojo could be an issue in the future.21 Second, the BDA data model pushed the capabilities of betterFORM (and XForms) to its limits with, for example, the high number of nested form controls and the necessary handling of special Unicode signs in the inputs. For these reasons, at certain points it became necessary to extend betterFORM via JavaScript.22 Scripting was also used to extend a standard image viewer provided by Dojo (dojox.image.Lightbox23) according to the needs of the BDA. 2.3 Features and usability While planning the structure, functionalities and design of the BDA web presentation, the primary challenge was to supply experts in the field with quick and straightforward access to the information that he or she assumed to be part of the archive. At the same time, it was challenging to open up the complex and multifaceted material to interested lay users. As a first step in responding to these requirements, we had to clarify which structures, items and contents actually had to constitute and represent the resource on the surface level. In other words, we needed to answer the question (yet again!): what is the resource? First and foremost, the archive was deemed to be about text witnesses that needed to be made accessible through their properties and content. In the BDA, the text witnesses are manifest in the form of object 19 XForms is a W3C standard for web forms which are embedded into other markup languages. An important feature of XForms is that it distinguishes between a data model, instances of data, form controls and “bindings” between the dif- ferent components, and thus follows a model-view-controller design, cf. W3C (2009), https://www.w3.org/TR/xforms/ and Dubinko (2003). Regarding eXist’s XForms implementations, XSLTForms is a client-side XForms processor while betterFORM is a server-side implementation which processes the XForms on the server and sends the resulting HTML and JavaScript of the forms to the browser. User interactions with the forms are then managed with the help of Ajax calls to the server. Cf. Siegel/Retter (2014), 256–271. 20 Cf. Dojo (2017a), https://dojotoolkit.org/. 21 The first version of the BDA ran on eXist 1.4.1, with the betterFORM limeGreen PreRelease and Dojo 1.6.1. 22 This was even prepared and supported by betterFORM: “Isn’t it one of the most mentioned arguments that XForm [sic] makes writing JavaScript superfluous? The authors of the XForms spec. Have been more cautious by stating ‘(...) reduces the need for scripting’. This clearly says that scripting might and most likely will be needed to build full applications. XForms is not the answer to all application needs.” Turner (2010). 23 Cf. Dojo (2017b), https://dojotoolkit.org/reference-guide/1. https://www.w3.org/TR/xforms/ https://dojotoolkit.org/ https://dojotoolkit.org/reference-guide/1 Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 67 descriptions holding manifold information, in corresponding images, in extracted information such as indexes, visualisations and motifs and in the form of contexts, e.g., bibliographies. The text witnesses are the anchor to which all access points in the presentation are bound. A faceted browsing allows users to find objects on the basis of multiple search criteria that can be employed individually or in conjunction with one another (see Figure 3 for example). Experts who want to examine certain spells and know the spells’ names or identification numbers can directly search for the texts and vignettes. In the example, the search is conducted for objects which bear the spell no. 5 and 11/49 in text or vignette form, combined with the criterion “date of origin” set to the epoch “New Kingdom”: this yields just a single hit. Thus, experts can filter the objects according to very specific criteria while the lay user can search for objects on the basis of more general properties, e.g., type of object or place of origin. Figure 3: Faceted browsing (example). In addition to the faceted browsing, other kinds of entry points to the archive have been cre- ated. An overview of the 238 different spells registered in the corpus is given in the website menu and conveys an impression of how the corpus is actually composed. Several indexes allow for direct retrieval of specific information: a bibliography, an alphabetical as well as semantically grouped index of motifs, an index of owners (the deceased persons for whom the Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 68 books were created) and their relatives with its own elaborate search filter,24 an index of insti- tutions by country and name, and, finally, an index of all the objects that are contained in the archive by name. Figure 4 gives an abridged example of an object description as it is presented in the digital archive:25 Another feature of the archive’s web presentation are the so-called overviews, which are simple visualisations and statistics of the data, including maps. On the one hand, they provide orientation for those consulting the material; on the other hand, they represent yet another access point for the object descriptions. Overviews have been created for the objects and their tradition, the images, locations and places of origin, dating, types of objects and material, owners and relatives, scripts, vignette styles, spells and groups of spells. Moreover, they initiate analytical approaches to the data, especially when the sequences of spells and vignettes found on the books are analyzed and when the visualisations go beyond the possibilities that standardised types of charts offer. Figure 5 depicts an analytical visualisation of the neighbourship of spells in the books compared to the canonical order of spells established by the field.26 24 Cf. Müller, inter alia (2012e). The following information is given for owners and relatives: name, short name, title, status as owner or relative, degree of kinship for relatives, a bibliographic reference to rank, gender, objects that witness the name, epoch and type of object. 25 See Müller, inter alia (2012b). 26 See Müller, inter alia (2012f) for details. Figure 4: Description of object TM 135212, wooden board, Abusir (detail). Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 69 As the active phase of the project’s Digital Humanities track was relatively short27 and the end of the overall long-term project drew near, it was clear that the question of sustainability of the resource and especially the features of the web application could not be postponed. Two central components of the digital archive in this regard are persistent URLs and APIs28. An example of such a stable URI for a BoD object description is http://totenbuch.awk.nrw.de/ objekt/tm135212. Even though the application runs on a server of the University of Cologne at the moment, it was decided to use the academy’s basic address awk.nrw.de to ensure long- term accessibility. The usage of Trismegistos numbers in the URL assures that the possible variability of object names does not put at risk that the addresses remain stable and citable. The URL as a whole is mapped onto the technical system behind it but is not directly entangled with it. Several kinds of APIs have been implemented for the digital archive: OAI-PMH,29 REST,30 Pelagios (place name) annotations in RDF and an unAPI for the retrieval of bibliographic references in various formats.31 3. Afterlife of a project: continuous curation of a resource 3.1 Launch, usage, and community The digital resource was introduced to the public at the closing convention of the BDP in Feb- ruary 2012. It has acquired a stable user base: as of May 2016, over 600 users have registered. The statistics consistently show over 30 unique daily visitors with occasional peaks around meetings and conferences. While these appear to be very modest numbers compared with what we are accustomed to in times of mass social media, it is in fact a very respectable achievement in the context of humanities projects dedicated to a highly specialised topic and geared towards the very specific usage patterns exhibited by its users.32 27 The digital reworking of the resource started in January 2011 and ended in December 2012. 28 API stands for Application Programming Interface. Here it means functionalities of software that are opened up to exter- nal programs through a documented interface with callable functions that deliver results in standard formats. 29 The OAI interface of the BDA builds on work from the Monasterium project, namely André Streicher, and has been ad- apted to the needs of the BDA by Ulrike Henny. 30 REST stands for Representational State Transfer and is a programming paradigm for distributed systems, especially Web services and APIs. 31 See Müller, inter alia (2012g) for a detailed documentation of the available APIs. 32 The analysis relies on the open source software Piwik for user statistics. Piwik analytics for the BDA has been in place since February 2013. All statements on long-term developments and trends refer to the timeframe from February 2013 to the present day. All information that can be exploited to identify a user, namely the IP-address, is processed and stored solely in an anonymised form. Cf. Piwik (2017), https://piwik.org/. Figure 5: Visualisation of the neighbourship of spells on the books (preview). http://totenbuch.awk.nrw.de/objekt/tm135212 http://totenbuch.awk.nrw.de/objekt/tm135212 https://piwik.org/ Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 70 The most visited pages are, of course, the core contents of the application, i.e., the object descriptions followed by the overview pages for single spells. In absolute numbers “Papyrus Turin 1791”33 and “Papyrus BM EA 10477”34 attracted the most public attention over the entire timeframe. This is not surprising since they are without any doubt among the most prominent manifestations of the BoD. Of the numerous registers and other aids on the website the bibliography and the motif registers seem to be of particular interest. While users from German-speaking countries constitute the largest single user group, requests from outside surpass these, despite the fact that the website is available only in German. Apparently, the language barrier is no serious obstacle for a trained Egyptologist, as the information is presented in a simple and structured way and crucial technical terms are either familiar to the international community even in their German form, or they translate well to English. Language does present a challenge when it comes to certain features implemented in the search function, user registration or in other places where instructions or documentation is needed. Of course, we would have liked to have an English version of the website, but resource restrictions led us to concentrate on content and features rather than on the translation of the user interface and introductory or help texts. Users who stay for at least ten minutes spend an average of 37 minutes on the BDA. Those who fall into that category typically focus on a selected number of specific object descriptions for a prolonged time and examine the attached pictures. These power users make up roughly a quarter of the website’s users. The BDA’s impact can also be traced through citations across both born-digital and traditional print publications. Object descriptions are cited in various essays and monographs around the world.35 The digital archive supports citation and referencing through clear, persistent, and human readable web addresses not only for object descriptions (as described above) but also for other parts of the application. Beyond monitoring statistics and impact there is real interaction with users through an e-mail address published on the website. Recipients of that address include technical staff as well as subject researchers, i.e., members of the former research project, who were primarily responsible for the edition of the scholarly content. This arrangement allows for flexible reaction to inquiries with both typical support questions as well as questions regarding the content. Traditional user support mainly concerns issues that arise during registration. We receive community feedback on the contents of the BDA from people representing diffe- rent disciplines including Egyptology, Archaeology, theology, Restoration Sciences, LAM (li- brary, archive, museum), along with hobby researchers and spiritually inclined lay users. This diversity most likely reflects the composition of the power user group. Input from the commu- nity can range from pointing out minor technical bugs or content related errors, to on-going debates in the identification of spells on objects, additions to the bibliography, and updates or corrections submitted by the archive hosting a particular object. From a methodological point of view, it is clear that these kinds of changes and additions are almost exclusively editorial and should be authorised by the scholarly editors of the BoD. Although the editors are in principle available through the support mailing list and remain res- ponsive to inquiries, the project shares the same fate as many before it: research groups dissolve after the end of the funding period and their members are gradually absorbed by their new line of work in academia or elsewhere, which leaves them less and less time for content curation. 33 Cf. Müller, inter alia (2012h). 34 Cf. Müller, inter alia (2012i). 35 The correct measurement of citation impact itself can be subject to scientific research. We let ourselves content with a general positive impression. See, for example, Google Scholar to find references to the BDA web application: https:// scholar.google.de/scholar?q=totenbuch.awk.nrw.de, accessed on June 28, 2016. https://scholar.google.de/scholar?q=totenbuch.awk.nrw.de https://scholar.google.de/scholar?q=totenbuch.awk.nrw.de Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 71 3.2 Maintenance, update and relaunch In the case presented here, the funding body, the AWK, took on responsibility for keeping the results of the research project available to the public through its digital presentation. While the academy owns the data and the editorial responsibility remains with the scholarly editors, maintenance and technical support was delegated to the CCeH at the University of Cologne, which was also responsible for the programming of the application during the project phase. Financially and on an institutional level, this arrangement was backed by a cooperation agree- ment between the academy and the University of Cologne. In this instance, continual maintenance challenges can be divided into at least four fields of activity. First of all, there are indispensable tasks on the level of technical support. Neglecting them would compromise the functionality and ultimately render the application unavailable.36 The second area is comprised of the fixing of minor bugs and the addition of new features. Although the absence of these features and persistence of bugs may be an annoyance, strictly speaking they do not break the application. We distinguish a third category of code curation that has an eye on prospective developments. This may include updates and subsequent restructuring of code. We prefer to think of such development as an investment. Again, while omitting such development may not necessarily break the application, it may generate even higher and unpredictable expenses in the future, increase risk for hacking, which may, in turn, lead to the abandonment of the BDA. Finally, as a fourth area, there are, of course, the tasks generated by the editors and their requests for content updates or questions and additional information supplied by the users. With respect to the continuous service of the website, since the launch in February 2012, beyond the basic maintenance tasks, we have encountered a number of incidents that threatened the functionality of the resource. In January 2014, an unannounced update of the Java version on the servers prevented the database instance from starting up. In August 2014, a widget developed by an external partner37 partly stopped working because it was relying on an API that was discontinued. Hacking attempts exploiting common vulnerabilities to spam or disable sites happen every day. On two occasions, these attempts were partly successful so that the application had to be restored and additional measures had to be taken to strengthen it against particular attacks. These kinds of incidents cannot be anticipated and the extent of the work required to fix them is hard to calculate, but they require a prompt intervention. Altogether, these efforts did not take up more than two person-days per year. This may sound like a relatively insignificant amount of time, but it should be remembered that responding to these incidents requires in-depth knowledge of the software; the need to keep this expert knowledge alive and available – even when needed for an isolated incident – is one of the major challenges confronting digital humanities centers. In the second field of activity, bug-fixing, most of the work was done in the first year. Thereafter the amount of time spent on bug-fixing was reduced to a very low level. Fixing of errors is now being fitted into the normal schedule according to its priority. The team keeps a wish list of features posted by the users. Implementation of these features, though, has a relatively low priority while there is no dedicated funding. 36 On the first level the basic infrastructure consisting of networking, DNS, server virtualisation, storage management etc. has to be in place. These services can be provided by external hosting agencies or academic computing centers. They are a prerequisite and of course generate overhead, but they are well-established services and can be priced in reliably and thus are not tackled here. 37 The Pelagios Place Widget, developed by the Pelagios community, cf. Pelagios (2017b), https://github.com/pelagios/ pelagios-widgets. At the time of writing, the latest commit was registered on August 14, 2014. https://github.com/pelagios/pelagios-widgets https://github.com/pelagios/pelagios-widgets Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 72 Regarding the third category, investments that deal with sustainable and long-term perspective of the project, plans for adjusting the code to recent developments were made as early as spring 2013. The team at the CCeH discussed an update to eXist 1.4.3 to solve security issues38 and to improve the performance of the application. After consulting with Wolfgang Meier, the chief developer of eXist, this initiative was suspended because it was clear that technical intricacies would require a considerable amount of work and it seemed advisable to put that effort into the next major version. An anew hack in 2016 revived the plan to update the database and relaunch the application. In principle, it is possible to export an entire application from one eXist version and transfer it to another eXist instance.39 In case of the BDA, the devil was in the details. After transferring the core of the application40 to the new eXist version, dependencies between project code and eXist-internal third-party components (mainly BetterFORM and Dojo) became apparent and had to be fixed. At the time of initial development, BetterFORM was a solid choice as a user interface frame- work that tightly integrates with XML technologies and eXist in particular. A version of the BetterFORM XForms processor is bundled with the eXist database, so initially it was an ad- vantage not to have to include additional external dependencies such as an HTML/Javascript framework. The main difficulty with the migration of the forms was that the newer version of BetterFORM in eXist 2.2 came with a newer version of Dojo. Unfortunately, there had been fundamental changes in the Dojo API as well as minor but decisive and undocumented changes in the XForms syntax expected by BetterFORM and in the eXist specific XQuery implemen- tation. All in all, the update of some parts of the XQuery code, the adaptation of CSS styles and the rewriting of most of the Dojo based JavaScript code were necessary. It became obvious that the scripting that had be done to extend BetterFORM where it did not suffice for handling the complex structure of the object descriptions was problematic in the moment of the migration. The same can be said for the extension of the Dojo-based image viewer and the general usage of the Dojo API to extend the features and usability of the presentation. In the light of the problems faced, it should not be forgotten that much of the migration was completely unproblematic. The bundle of XML data, XQuery and XSLT scripts, static HTML pages and SVG graphics and additional binary resources could be transferred directly to the new database. It was not necessary to alter the data, their structure and interrelations. The migration of the user management system was straightforward, as well. Following the classification laid out above, the personnel resources needed to keep the BDA alive thus amount to the following: 1. Continuous server and system maintenance: ca. 16h per year41 2. Minor bug-fixing and additional features: 60h in the last four years 3. Update and relaunch four years after the initial launch (including planning): c. 100h once 4. Communication with users (login problems etc.) and curation of the data (corrections, additions): c. 10h per year 38 The website had been hacked in November 2013 and an outdated version of the database represented a weak point in this regard. 39 From eXist-db 2.0 onwards, this is supported by a dedicated package repository (cf. eXistdb 2017, http://exist-db.org/ exist/apps/doc/repo.xml), but export and import routines existed even before. 40 Cf. section 2.2 and especially Figure 2 for an account of the technical framework. 41 Not including the hosting infrastructure which is managed externally. http://exist-db.org/exist/apps/doc/repo.xml http://exist-db.org/exist/apps/doc/repo.xml Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 73 4. Conclusion and outlook In conclusion, the BDA shows that it is possible to transform a traditional long-term research project into a digital project of a high quality level in a relatively short amount of time and with limited financial resources – if the interdisciplinary cooperation between researchers and digital humanists works well. In this case, two years of 100% FTE of a graduate were sufficient for the initial development of the digital archive. Regarding the stability and sustainability of the data model, technical framework and user interface, the X-technologies and eXist as a database management system have proven to be good choices until now. However, there is also a rising curve of complexity from data through application42 to user interface when it comes to maintenance, update and relaunch. In the case of the BDA, the local XML model was and is reasonable because it made the modeling easy and the use of a local dialect can be justified when exports of the data are offered in standard formats. As regards the application and user interface, a digital resource for the BoD, and probably for other humanities research subjects as well, can hardly be created with standard software because of the particularity and complexity of the material. For the BDA, this became especially visible when the detailed and hierarchically organised object descriptions had to be mapped to and represented through user interface functionalities such as faceted browsing as well as search and input forms. A modular and flexible system that can be adapted to the requirements of the project is needed, which, at the same time, does not trouble future develop- ments. In principle, eXist is such a flexible system but seems to be more future-proof in its core functionalities (the handling of XML data, XQueries and basic apps) than in specialised features that are in part integrated into the database as third-party libraries and interdependent with the core database in their versions. As regards the user interface, its structure, browse and search features and its design have all stood the test of time. Most users seem to get by with it and find what they are looking for. One of the greatest rewards has been to witness continual and consistent usage and community feedback. Power users do not solely consume but also contribute to the information in the database. Although modest in numbers these usage patterns are of great quality as they reflect a qualified scientific use and reveal that the BDA is, as intended, an established research tool for a specialised community, supporting the production of theses, essays and other scholarly publications. In the light of the interest that the international Egyptologist community shows, it is thus reasonable and important not just to archive the underlying data but to keep the database, presentation and user interface alive and running. The web-based platform ensures that the digital resource is used because it furthers the visibility of the contents and keeps the threshold low to engage with them. A technically advanced Egyptologist might well make use of the APIs and work directly with the XML data to carry out specific formal analyses. Most users, however, will be happy to have a user interface that is as comfortable to use as possible. The key to ensuring long-term availability of digital resources is to take on responsibility and to organise continuous maintenance and curation. There is a risk inherent to this type of commitment inasmuch as there is no safe way to calculate the required workload and expenses in advance.43 Researchers and funders alike push towards complex digital representations of research data and call for sustainability at the same time, while there are no well-practiced and institutionalised solutions in place that would guarantee long-term availability of digital systems. Fortunately, this topic has come into focus recently and is vigorously debated 42 Understood as the middleware of code and function modules providing the basic functionality of the digital archive. 43 There are few published experience reports and even fewer numbers to build on. Future developments of technology and prices are hard to predict, especially in the long term. Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 74 especially in the context of humanities.44 Our experience is that the maintenance of a digital resource such as the one presented here is reasonably manageable. It must be said, however, that the BDA is backed by a Digital Humanities center with a lifespan longer than a single project and the corresponding personnel, and that the curation of the contents relies on the voluntary commitment of the subject researchers. The continuous use and development of the platform and ongoing interest in the subject may as well lead to new initiatives and follow- up projects which take the digital resource into a new phase and present the data in a new context. As the current user interface would be replaced by another one, maintenance could be reduced to archiving the underlying research data. At present, however, such initiatives are not in the offing. Likewise, should it become clear that the costs for maintaining the current web application surpass the benefit, the web application would be abandoned. As long as this is not the case, keeping the online BDA alive as long as possible is worthwhile. 44 In 2016, the second edition of the conference “Forschungsdaten in den Geisteswissenschaften” (Research Data in the Humanities) in Hamburg was announced, dedicated solely to the question of sustainability of digital research applications (cf. Universität Hamburg 2016, https://www.gwiss.uni-hamburg.de/gwin/ueber-uns/forge2016.html). Also, the 2017 edi- tion of the Digital Humanities Conference in German-speaking countries will address digital sustainability and stresses the unresolved issue of long-term availability of digital platforms, editions and databases (cf. DHd 2017, http://www. dhd2017.ch/calls). https://www.gwiss.uni-hamburg.de/gwin/ueber-uns/forge2016.html http://www.dhd2017.ch/calls http://www.dhd2017.ch/calls Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 75 5. List of Abbreviations API Application Programming Interface AWK Nordrhein-Westfälische Akademie der Wissenschaften BDA Book of the Dead digital archive BDP Book of the Dead Research Project BoD Old Egyptian Book of the Dead CCeH Cologne Center for eHumanities CSS Cascading Style Sheets DH Digital Humanities DNS Domain Name System FTE Full-time equivalent HAT Handschriften des Altägyptischen Totenbuchs HTML Hypertext Markup Language HTTP Hyper Text Transfer Protocol LAM Library, Archive, Museum OAI Open Archives Initiative OAI-PMH Open Archives Initiative Protocol for Metadata Harvesting RDF Resource Description Framework REST Representational State Transfer SAT Studien zum Altägyptischen Totenbuch SVG Scalable Vector Graphics TEI Text Encoding Initiative URI Uniform Resource Identifier URL Uniform Resource Locator WebDAV Web Distributed Authoring and Versioning XHTML Extensible Hypertext Markup Language XML Extensible Markup Language XPath XML Path Language XQuery XML Query Language XSLT Extensible Stylesheet Language Transformation 6. Bibliography BBAW (2014): Berlin-Brandenburgische Akademie der Wissenschaften, Altägyptisches Wör- terbuch, “Thesaurus Linguae Aegyptiae (TLA)”, http://aaew.bbaw.de/tla/. Depauw/Geldorf (2014): Depauw and Gheldof, “Trismegistos. An Interdisciplinary Platform for Ancient World Texts and Related Information”, in: Bolikowski, Casarosa, Goodale, Hous- sos, Manghi, and Schirrwagen (edd.), Theory and Practice of Digital Libraries – TPDL 2013 Selected Workshops, 416: 40–52. Communications in Computer and Information Science, Cham. DHd (2016): Digital Humanities im deutschsprachigen Raum (DHd), “Call for Papers”, (DHd 2017). Digitale Nachhaltigkeit, http://www.dhd2017.ch/calls. http://aaew.bbaw.de/tla/index.html http://www.dhd2017.ch/calls Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 76 Dojo (2017a): The Dojo Foundation, “Dojo Toolkit 1.11”, https://dojotoolkit.org/ (March 2nd, 2017). Dojo (2017b): The Dojo Foundation, “dojox.image.Lightbox”, https://dojotoolkit.org/referen- ce-guide/1.10/dojox/image/Lightbox.html (March 2nd, 2017). Dubinko (2003): Dubinko, “XForms Essentials”, Sebastopol, http://xformsinstitute.com/es- sentials/browse/. Elliott et al. (2011–2014): Elliott, Bodard, Mylonas, Stoyanova, Tupman, and Vanderbilt, “Epi- Doc Guidelines: Ancient Documents in TEI XML (Version 8)” The Stoa Consortium, http:// www.stoa.org/epidoc/gl/latest/. eXistdb (2017): eXist-db Project, “Package Repository”, http://exist-db.org/exist/apps/doc/ repo.xml (March 2nd, 2017). Google (2017): Google Developers, “Google Charts. Interactive Charts for Browsers and Mo- bile Devices”, https://developers.google.com/chart/. Grün (2011): Grün, “Storing and Querying Large XML Instances”, Konstanz, http://files.ba- sex.org/publications/Gruen [2010], Storing and Querying Large XML Instances.pdf. Heinz (2010): Heinz, “Monasterium.net – Auf dem Weg zu einem europäischen Urkunden- portal”, in: Regionale Urkundenbücher. Die Vorträge der 12. Tagung der Commission Interna- tionale de Diplomatique, 14:139–45 (NÖLA. Mitteilungen Aus Dem Niederösterreichischen Landesarchiv), St. Pölten. Henny (2013): Henny, “Aufbau eines Digitalen Textzeugenarchivs zum Altägyptischen Toten- buch” (Best Practice: Digitale Korpora. Workshop der Berlin-Brandenburgischen Akademie der Wissenschaften und der Union der deutschen Akademien der Wissenschaften, Berlin, August 10, 2013), https://prezi.com/pthztgusy4g8/aufbau-eines-digitalen-textzeugenarchivs-zum-al- tagyptischen-totenbuch/. ICARUS (2017): ICARUS – International Centre for Archival Research, “Monasterium.net”, http://monasterium.net/mom/home (March 2nd, 2017). Krah (2009): Krah, “Monasterium.net - Das Virtuelle Urkundenarchiv Europas. Möglichkeiten der Bereitstellung und Erschließung von Urkundenbeständen”, in: Generaldirektion der Staat- lichen Archive Bayerns (ed.), Archivalische Zeitschrift 91, no. Sonderdruck, 221–46. Lagoze et al (2005): Lagoze, Van de Sompel, Nelson, and Warner, “Implementation Guidelines for the Open Archives Initiative Protocol for Metadata Harvesting. Guidelines for Repository Implementers” Open Archives Initiative, http://www.openarchives.org/OAI/2.0/guidelines-re- pository.htm. Legowski (2015): Legowski, “The Project Is Completed! What Now? The Ancient Egyptian Book of the Dead – A Digital Textzeugenarchiv” (Altertumswissenschaften in a Digital Age: Egyptology, Papyrology and Beyond, Leipzig, May 11, 2015), https://prezi.com/z2hcb_m_ y815/the-project-is-completed-what-now/. https://dojotoolkit.org/ https://dojotoolkit.org/reference-guide/1.10/dojox/image/Lightbox.html https://dojotoolkit.org/reference-guide/1.10/dojox/image/Lightbox.html http://xformsinstitute.com/essentials/browse/ http://xformsinstitute.com/essentials/browse/ http://www.stoa.org/epidoc/gl/latest/ http://www.stoa.org/epidoc/gl/latest/ http://exist-db.org/exist/apps/doc/repo.xml http://exist-db.org/exist/apps/doc/repo.xml https://developers.google.com/chart/ http://files.basex.org/publications/Gruen [2010], Storing and Querying Large XML Instances.pdf http://files.basex.org/publications/Gruen [2010], Storing and Querying Large XML Instances.pdf https://prezi.com/pthztgusy4g8/aufbau-eines-digitalen-textzeugenarchivs-zum-altagyptischen-totenbuch https://prezi.com/pthztgusy4g8/aufbau-eines-digitalen-textzeugenarchivs-zum-altagyptischen-totenbuch http://monasterium.net/mom/home http://www.openarchives.org/OAI/2.0/guidelines-repository.html http://www.openarchives.org/OAI/2.0/guidelines-repository.html https://prezi.com/z2hcb_m_y815/the-project-is-completed-what-now/ https://prezi.com/z2hcb_m_y815/the-project-is-completed-what-now/ Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 77 Müller et al. (2012a): Müller et al., “Das Altägyptische Totenbuch. Ein Digitales Textzeugen- archiv”, http://www.totenbuch.awk.nrw.de/. Müller et al. (2012b): Müller et al., “Totenbuchprojekt Bonn, TM 135212”, in: Das Al- tägyptische Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/objekt/ tm135212. Müller et al. (2012c): Müller et al., “Register Motive (Nach Gruppen)”, in: Das Altägypti- sche Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/register/moti- ve-gruppen. Müller et al. (2012d): Müller et al., “Totenbuch-Schema.”, in: Das Altägyptische Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/schema/totenbuch.xsd. Müller et al. (2012e): Müller et al., “Register der Besitzer”, in: Das Altägyptische Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/register/besitzer. Müller et al. (2012f): Müller et al., “Sprüche. Benachbarte Sprüche”, in: Das Altägyptische Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/uebersicht/sprue- che#Nachbarschaft. Müller et al. (2012g): Müller et al., “Dokumentation. Die Außenwelt, Schnittstellen und Meta- daten”, in: Das Altägyptische Totenbuch. Ein Digitales Textzeugenarchiv, 2012ff, http://toten- buch.awk.nrw.de/projekt/dokumentation#SchnittstellenMetadaten. Müller et al. (2012h): Müller et al., “Totenbuchprojekt Bonn, TM 57201”, in: Das Altägypti- sche Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/objekt/tm57201. Müller et al. (2012i): Müller et al., “Totenbuchprojekt Bonn, TM 134299”, in: Das Altägyptische Totenbuch. Ein Digitales Textzeugenarchiv, http://totenbuch.awk.nrw.de/objekt/tm134299. Pelagios (2017a): PELAGIOS Project, “Peripleo. A Search Engine for the Pelagios Universe, with a Comprehensive JSON API”, https://github.com/pelagios/peripleo (March 2nd, 2017). Pelagios (2017b): PELAGIOS Project, “Pelagios-Widgets. Embeddable JavaScript Widgets to Access Pelagios Data”, https://github.com/pelagios/pelagios-widgets (March 2nd, 2017). Piwik (2017): Piwik.org, “PIWIK. Open Analytics Platform.” https://piwik.org/ (March 2nd, 2017). Rößler-Köhler (1995): Rößler-Köhler (ed.), Handschriften des Altägyptischen Totenbuchs (HAT), Wiesbaden. Rößler-Köhler (1998): Rößler-Köhler (ed.), Studien zum Altägyptischen Totenbuch (SAT), Wiesbaden. Sahle/Henny (2012a): Sahle and Henny, “The New Book of the Dead Database” (Third Inter- national Colloquium for Book of the Dead Studies, Bonn, February 28, 2012), http://web.ar- chive.org/web/20130422052335/https://www.totenbuch-projekt.uni-bonn.de/kolloquium-tb. http://www.totenbuch.awk.nrw.de/ http://totenbuch.awk.nrw.de/objekt/tm135212 http://totenbuch.awk.nrw.de/objekt/tm135212 http://totenbuch.awk.nrw.de/register/motive-gruppen http://totenbuch.awk.nrw.de/register/motive-gruppen http://totenbuch.awk.nrw.de/schema/totenbuch.xsd http://totenbuch.awk.nrw.de/register/besitzer http://totenbuch.awk.nrw.de/uebersicht/sprueche#Nachbarschaft http://totenbuch.awk.nrw.de/uebersicht/sprueche#Nachbarschaft http://totenbuch.awk.nrw.de/projekt/dokumentation#SchnittstellenMetadaten http://totenbuch.awk.nrw.de/projekt/dokumentation#SchnittstellenMetadaten http://totenbuch.awk.nrw.de/objekt/tm57201 http://totenbuch.awk.nrw.de/objekt/tm134299 https://github.com/pelagios/peripleo https://github.com/pelagios/pelagios-widgets https://piwik.org/ http://web.archive.org/web/20130422052335/https://www.totenbuch-projekt.uni-bonn.de/kolloquium-tb http://web.archive.org/web/20130422052335/https://www.totenbuch-projekt.uni-bonn.de/kolloquium-tb Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 78 Sahle/Henny (2012b): Sahle and Henny, “Visualising the Book of the Dead” (unConference DHD, Hamburg, July 17, 2012), https://prezi.com/s_3muupnarfs/visualising-the-book-of-the- dead/. Sahle/Henny (2013a): Sahle and Henny, “Aspekte Digitaler Forschung Am Beispiel Des To- tenbuch-Projekts”, (“Nicht für das Leben lernen wir, sondern für den Tod”. Abschlussveran- staltung des Akademienprojektes “Edition des altägyptischen Totenbuches vom Neuen Reich bis zur Römerzeit,” Düsseldorf, February 19, 2013), http://www.awk.nrw.de/veranstaltungen/ veranstaltungsrueckblick/2013/totenbuch-projekt-abschlussveranstaltung.html. Sahle/Henny (2013b): Sahle and Henny, “Egyptology Meets Digital Humanities: The Book of the Dead” (Digital Classicist Berlin Seminars, Berlin, August 1, 2013), http://de.digitalclassi- cist.org/berlin/2013/01/07/Sahle-Henny. Siegel/Retter (2014): Siegel and Retter, “eXist. A NoSQL Document Database and Application Platform”, Sebastopol. Turner (2010): Turner, “JavaScript in betterFORM.” betterFORM, https://betterform.word- press.com/2010/06/16/javascript-in-betterform/ (June 16, 2010). Universität Hamburg (2016): Universität Hamburg, Fakultät für Geisteswissenschaften, “For- schungsdaten in den Geisteswissenschaften (FORGE 2016) — Jenseits der Daten”, https:// www.gwiss.uni-hamburg.de/gwin/ueber-uns/forge2016.html (March 2nd, 2017). W3C (2009): World Wide Web Consortium (W3C), “XForms 1.1. W3C Recommendation 20 October 2009”, https://www.w3.org/TR/xforms/ (March 2nd, 2017). W3C (2017): World Wide Web Consortium (W3C), “XML Technology”, https://www.w3.org/ standards/xml/ (March 2nd, 2017). 7. List of Images Figure 1: Basic structure of the data model for a BoD object; by Ulrike Henny. Figure 2: Outline of the technical framework behind the BDA; by Ulrike Henny. Figure 3: Faceted browsing (example); screenshot from website (2017). Figure 4: Description of object TM 135212, wooden board, Abusir (detail); screenshot from website (2017, http://totenbuch.awk.nrw.de/objekt/tm135212). Figure 5: Visualisation of spell neighbourship on the books (preview); screenshot from websi- te (2017, http://totenbuch.awk.nrw.de/static/overviews/benachbarte-sprueche-absolut-gerade. svg). https://prezi.com/s_3muupnarfs/visualising-the-book-of-the-dead/ https://prezi.com/s_3muupnarfs/visualising-the-book-of-the-dead/ http://www.awk.nrw.de/veranstaltungen/veranstaltungsrueckblick/2013/totenbuch-projekt-abschlussveran http://www.awk.nrw.de/veranstaltungen/veranstaltungsrueckblick/2013/totenbuch-projekt-abschlussveran http://de.digitalclassicist.org/berlin/2013/01/07/Sahle-Henny http://de.digitalclassicist.org/berlin/2013/01/07/Sahle-Henny https://betterform.wordpress.com/2010/06/16/javascript-in-betterform/ https://betterform.wordpress.com/2010/06/16/javascript-in-betterform/ https://www.gwiss.uni-hamburg.de/gwin/ueber-uns/forge2016.html https://www.gwiss.uni-hamburg.de/gwin/ueber-uns/forge2016.html https://www.w3.org/TR/xforms/ https://www.w3.org/standards/xml/ https://www.w3.org/standards/xml/ http://totenbuch.awk.nrw.de/objekt/tm135212 http://totenbuch.awk.nrw.de/static/overviews/benachbarte-sprueche-absolut-gerade.svg http://totenbuch.awk.nrw.de/static/overviews/benachbarte-sprueche-absolut-gerade.svg Digital Classics Online Henny, Blumtritt, Schaeben, Sahle: The life cycle of the Book of the Dead DCO 3,2 (2017) 79 Authors45 Ulrike Henny Universität Würzburg Institut für Deutsche Philologie/ Lehrstuhl für Computerphilologie Am Hubland 97074 Würzburg Email: ulrike.henny@uni-wuerzburg.de Jonathan Blumtritt Universität Köln Data Center for the Humanities (DCH) Albertus-Magnus-Platz 50923 Köln Email: jonathan.blumtritt@uni-koeln.de Marcel Schaeben Universität Köln Cologne Center for eHumanities (CCeH) Albertus-Magnus-Platz 50923 Köln Email: m.schaeben@uni-koeln.de Prof. Dr. Patrick Sahle Universität Köln Cologne Center for eHumanities (CCeH) Albertus-Magnus-Platz 50923 Köln Email: sahle@uni-koeln.de 45 The rights pertaining to content, text, graphics, and images, unless otherwise noted, are reserved by the author. This contribution is licensed under CC-BY 4.0 International.