Database of Byzantine Book Epigrams - Archive

Abstract

This dataset is an extension of the publication of the Database of Byzantine Book Epigrams (2023). The 2023 publication is a copy of the data used for the live application on dbbe.ugent.be. The present dataset aims to offer a simplified structure of the DBBE data, facilitating computational research and data analysis. The dataset provides structured access to the data behind dbbe.ugent.be, enabling intuitive exploration and reuse. It is based on production PostgreSQL and Elasticsearch instances and is organized around six core concepts. The data is updated weekly to reflect the latest research and additions. Occurrences:Individual epigrams reproduced as faithfully as possible from manuscripts, preserving orthography and punctuation. Types: Normalized or critically established texts linked to one or more Occurrences, enabling comparison across similar Occurrences and providing interpretive metadata such as translations, genres, and subjects. Verses: Verses of Occurrences, grouped in Verse Groups to record textual parallels across Occurrences. Manuscripts: Metadata on the context of manuscripts, including provenance and related documentation. Persons: Information on authors, scribes, editors, and other historical or modern contributors linked to Occurrences, Types, or Manuscripts. Bibliographies: Structured references connecting literature and publications to the relevant entities in the corpus. Exploring the Dataset The dataset can be explored and analyzed in multiple ways: Web-based viewing: Tools such as SQLite Viewer allow users to simply upload the SQLite file and inspect its contents directly in the browser, requiring no technical setup. Graphical interface and export: DB Browser for SQLite offers an intuitive interface for browsing the data and exporting tables to CSV for further analysis without need for scripting based interaction. AI-assisted semantic querying: The database file can be uploaded to a large language model for natural language queries. For example, one could ask: "Give me five occurrences from the eleventh century discussing harbours." To protect sensitive data, consider using self-hosted models or paid, secure AI services rather than free online tools. Custom development: The structured SQLite format provides a robust foundation for programmatic analysis, integration with other tools like datasette, or the development of custom applications tailored to specific research questions. Database schema For a full visual of the database schema, please visit yED live. 1. Occurrences This table stores individual Occurrences (= short epigrams or poems, literally how they have been found in a manuscript, including marks for gaps and missing text.) Columns include: id, created, modified, public_comment, incipit, text_stemmer, text_original, location_in_ms*, completion_date_floor, completion_date_ceiling, palaeographical_info, contextual_info, manuscript_id, title *Note that, in the current version, the location of occurrences within the manuscript is given as plain text (ex. p. 394-395 for pages or f. 18r-18v for folia). For manuscripts that have more than 1 way of numbering pages, the alternative location is marked as f. 14r -- (alt.) p. 27. Related tables: occurrence_person_role: Links Occurrences to Persons, indicating which Role a Person plays in the given Occurrence. Example: Scribe ( = historical person), transcriber (=modern person), contributor (=modern person)... occurrence_genre: genre attributed to this Occurrence (Can be more than 1) occurrence_metre: metre attributed to this Occurrence (Can be more than 1) occurrence_management: Internal information. For example: To do's in the processing of this Occurrence occurrence_acknowledgement: Plain text acknowledgement of people who helped in the publication of this Occurrence. occurrence_text_status: An Occurrence text can have statuses like partially/completely (un)known occurrence_related_occurrence and occurrence_relation_definition: An Occurrence can be related to other Occurrence if (a) some of their verses share Verse Groups or (b) they share a Type. The relationship type is defined in occurrence_relation_definition. This works in one direction: if occurrenceA --> related to --> occurrenceB is set, then occurrenceB --> related to --> occurrenceA is not set. occurrence_keyword: Keywords telling what the Occurrence is about 2. Verses This table contains verse-level information about an Occurrence. Columns include id, occurrence_id, manuscript_id, text, order_in_occurrence, verse_group_id. Verse Groups are groupings of similar verses across occurrences. 3. Types This table contains prototypes of Occurrences. A lot of Occurrences have a high level of similarity. DBBE proposes prototypes for every group of similar Occurrences. Related tables: type_person_role: Links Types to Persons, indicating which Role a Person plays in the given Type. Example: Creator, Translitor, Editor, Contributor, ... type_genre: genre attributed to this Type. More than 1 Genre can be attributed. type_metre: metre attributed to this Type. More than 1 Metre can be attributed. type_management: Internal information. For example: To do's in the processing of this Type type_acknowledgement: Plain text acknowledgement of people who helped in the publication of this Type. type_text_status: Type text can be either completely known or partially unknown type_related_type: Groups of similar Types. The relationship is defined in type_relation_definition. This works in one direction: if typeA --> related to --> typeB is set, then typeB --> related to --> typeA is not set. type_tag: Explains the function of the Type (ex: introducing a subject, making a comment on the content,...). type_occurrence: Occurrences linked to this Type. Note that this is a many-to-many relationship: one occurrence can be linked to several types, one type can have several occurrence linked to it. type_editorial_status: editorial states for types. Currently only critical text / not a critical text. type_keyword: Keywords telling what the type is about 4. Manuscripts This table contains metadata about manuscripts. Related tables: manuscript_person_role: Any possible role a Person could play in the publication of this manuscript. Example: Patron ( = historical person), Illuminator (=historical person), contributor (=modern person)... manuscript_acknowledgement: Plain text acknowledgement of people who helped in the publication of this Manuscript. manuscript_content: Explains what the manuscript is about. Careful: content is a hierarchical table. For example, a manuscript can be about Biblica -> Novum Testamentum. In this table, the lowest leaf (Novum Testamentum) is stored. The parent_id column of the content table can be used to trace the full content. manuscript_identification: Links a manuscript to one or more IDs that were used in canonical works to refer to this manuscript (ex: Diktyon) manuscript_management: Internal information. For example: To do's in the processing of this manuscript manuscript_location: The location where the manuscript was written. Careful: location is a hierarchical table. If a manuscript was written in Brussels, it is linked to Brussels, but via the parent_id column of the location table, you could also see that Brussels is in Belgium. 5. Persons This table contains metadata about persons involved (authors, editors, patrons, etc.). Related tables: person_acknowledgement: Plain text acknowledgement of people who helped in the publication of the information on this (historical) person. person_identification: Used to link persons to canonical IDs set by different authorities. person_management: Internal information. For example: To do's in the processing of this person person_self_designation: Used for scribes: How a scribe describes himself person_office: Used for scribes: The official title of a person. 6. Bibliographies Bibliographies are modelled as concrete entity types, rather than a single table as in the original setup. article book book_chapter blog_post bib_varia: This table is usually avoided but contains entries for which no other bibliographical type exists. online_source phd Each bibliographic entity has: its own table as mentioned above a corresponding _person_role table (ex.: article_person_role: could contain authors, contributors, reviewers, ... for a given article) tables linking to the item the bibliography is about: manuscripts (ex: manuscript_article: contains articles about a given manuscript) occurrence (ex: occurrence_book: contains books about a given Occurrences) persons (ex: person_article: contains articles about - usually historical - persons) type (ex: type_article: contains articles about given Types) Additional structures: journal and journal_issue: Articles may be linked to journals and journal issues. Note that, for now, some of these bibliography tables were added for completeness sake: not every concept (Manuscript / Occurrence / Person / Type) has all types of bibliographies linked to it (online sources, PhDs, etc.). Lookup / Metadata Tables roles — defines roles for persons (ex. Author, Scribe, Contributor, ...) text_status — textual status of Occurrence or Type. (ex. Text completely known, text partially unknown,...) keywords — keywords for Occurrence and Type (ex. Holy Trinity, Seven Sages, Last Judgement, ...) tag — tag for Type: Explains the function of the Type (ex: introducing a subject, making a comment on the content,...). metre — metre classification (ex. Dodecasyllable, Elegiacs,...) genre — genre classification. (ex. Scribe-related epigram, Text-related epigram, Reader-related epigram) management — administrative metadata. (ex. Bibliography to check) acknowledgement — acknowledgement linked to occurrence, manuscripts, type, or persons. (ex. Inf