five

Database of Byzantine Book Epigrams - Archive

收藏
Zenodo2026-04-27 更新2026-05-26 收录
下载链接:
https://zenodo.org/doi/10.5281/zenodo.19810955
下载链接
链接失效反馈
官方服务:
资源简介:
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. Information on the manuscript courtesy of \<person x>) editorial_status — editorial states for type. Currently only (not) a critical text. self_designation — how a scribe describes himself office — the official title of a person. location - location that could be linked to manuscripts, library, persons,... . library — library name and location. Note that a manuscript name is always City - library - collection - shelf collection — collection metadata. Note that a manuscript name is always City - library - collection - shelf content - Used for storing manuscript content. Careful: location 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. identification - canonical ways to refer to persons or manuscripts (ex. Diktyon identifiers) For questions or feedback regarding this dataset, please contact the technical curator at: paulien.lemay@ugent.be

本数据集是《拜占庭书铭数据库》(Database of Byzantine Book Epigrams)2023年版出版物的扩展集。 该2023年发布成果是dbbe.ugent.be线上应用所使用数据的副本。 本数据集旨在为《拜占庭书铭数据库》(DBBE)的数据提供简化结构,以助力计算研究与数据分析工作。 本数据集为dbbe.ugent.be背后的数据源提供结构化访问路径,支持直观的探索与复用。其基于生产级PostgreSQL与Elasticsearch实例构建,围绕六大核心概念进行组织,且每周更新以反映最新的研究成果与新增数据。 实例(Occurrences):尽可能忠实地复刻手稿中的单条书铭,保留正字法与标点符号。 文本类型(Types):与一个或多个实例相关联的标准化或经批判性审定的文本,支持对相似实例进行比对,并提供翻译、体裁、主题等解释性元数据。 诗节(Verses):实例对应的诗节,按诗节组(Verse Groups)进行分组,以记录不同实例间的文本平行关系。 手稿(Manuscripts):手稿相关背景的元数据,包括来源与相关文献。 人物(Persons):与实例、文本类型或手稿相关联的作者、抄写员、编辑及其他历史或现代贡献者的相关信息。 参考文献(Bibliographies):将文献与出版物与语料库中的相关实体进行关联的结构化参考文献。 数据集探索方式 本数据集可通过多种方式进行探索与分析: 基于网页的查看方式:可使用SQLite查看器(SQLite Viewer)等工具,用户仅需上传SQLite文件即可直接在浏览器中查看数据内容,无需进行任何技术配置。 图形界面与导出功能:SQLite数据库浏览器(DB Browser for SQLite)提供直观的界面用于浏览数据,并可将数据表导出为CSV格式以开展进一步分析,无需基于脚本的交互操作。 AI辅助语义查询:可将数据库文件上传至大语言模型(Large Language Model)以发起自然语言查询。例如,用户可提出:"为我提供5条11世纪讨论港口的书铭实例。"为保护敏感数据,建议使用自托管模型或付费安全AI服务,而非免费在线工具。 自定义开发:结构化的SQLite格式为程序化分析、与datasette等其他工具集成,或针对特定研究问题开发自定义应用程序提供了坚实基础。 数据库架构 如需查看完整的数据库架构可视化图,请访问yED live。 1. 实例表 该表存储单个实例(即短书铭或诗歌,忠实呈现手稿中的原始样貌,包括缺漏文本与空白的标记)。 其字段包括:id、创建时间、修改时间、公开评论、开篇词、词干提取文本、原始文本、手稿内位置*、完成日期下限、完成日期上限、古文字学信息、背景信息、手稿id、标题。 *注:在当前版本中,手稿内实例的位置以纯文本形式呈现(例如页码范围p. 394-395或对开页范围f. 18r-18v)。对于存在多种页码编号方式的手稿,其替代位置将标记为f. 14r -- (alt.) p. 27。 相关关联表: occurrence_person_role:将实例与人物相关联,用于指明人物在对应实例中所承担的角色。示例:抄写员(历史人物)、转录员(现代人员)、贡献者(现代人员)等…… occurrence_genre:分配给该实例的体裁(可分配多个) occurrence_metre:分配给该实例的格律(可分配多个) occurrence_management:内部管理信息。例如:该实例处理过程中的待办事项 occurrence_acknowledgement:用于致谢协助发布该实例的人员的纯文本内容 occurrence_text_status:实例文本的状态,例如部分/完全(未)可知 occurrence_related_occurrence与occurrence_relation_definition:当两个实例满足以下任一条件时可建立关联:(a) 它们的部分诗节属于同一诗节组;(b) 它们共享同一文本类型。关联类型由occurrence_relation_definition定义。该关联为单向关联:若已设置实例A → 关联至实例B,则不会反向设置实例B → 关联至实例A。 occurrence_keyword:用于描述该实例主题的关键词 2. 诗节表 该表存储实例对应的诗节级信息。其字段包括:id、实例id、手稿id、文本、实例内顺序、诗节组id。 诗节组用于对不同实例中的相似诗节进行分组。 3. 文本类型表 该表存储实例的原型文本。大量实例存在较高的相似性,DBBE为每一组相似实例提供了原型文本。 相关关联表: type_person_role:将文本类型与人物相关联,用于指明人物在对应文本类型中所承担的角色。示例:创作者、翻译者、编辑、贡献者等…… type_genre:分配给该文本类型的体裁(可分配多个) type_metre:分配给该文本类型的格律(可分配多个) type_management:内部管理信息。例如:该文本类型处理过程中的待办事项 type_acknowledgement:用于致谢协助发布该文本类型的人员的纯文本内容 type_text_status:文本类型的状态,可为完全已知或部分未知 type_related_type:相似文本类型的分组。关联类型由type_relation_definition定义。该关联为单向关联:若已设置类型A → 关联至类型B,则不会反向设置类型B → 关联至类型A。 type_tag:用于说明文本类型的功能(例如:引入主题、对内容进行评论等)。 type_occurrence:与该文本类型相关联的实例。请注意这是多对多关系:一个实例可关联至多个文本类型,一个文本类型也可关联至多个实例。 type_editorial_status:文本类型的编辑状态,目前仅包含"批判性文本/非批判性文本"两种选项。 type_keyword:用于描述该文本类型主题的关键词 4. 手稿表 该表存储手稿的相关元数据。 相关关联表: manuscript_person_role:人物在手稿发布过程中可承担的任意角色。示例:资助者(历史人物)、插图师(历史人物)、贡献者(现代人员)等…… manuscript_acknowledgement:用于致谢协助发布该手稿的人员的纯文本内容 manuscript_content:用于说明手稿的主题。请注意:内容表为层级结构。例如,某手稿的主题可分为《圣经》→《新约》,该表中仅存储最低层级的节点(即《新约》),可通过内容表的parent_id字段追溯完整的主题层级。 manuscript_identification:将手稿与权威著作中使用的一个或多个标识id相关联(例如:Diktyon标识) manuscript_management:内部管理信息。例如:该手稿处理过程中的待办事项 manuscript_location:手稿的书写地点。请注意:地点表为层级结构。若某手稿写于布鲁塞尔,则其关联至布鲁塞尔,同时可通过地点表的parent_id字段追溯布鲁塞尔隶属于比利时的完整层级关系。 5. 人物表 该表存储相关人物(包括作者、编辑、资助者等)的元数据。 相关关联表: person_acknowledgement:用于致谢协助发布该(历史)人物信息的人员的纯文本内容 person_identification:用于将人物与不同权威机构制定的标准id相关联 person_management:内部管理信息。例如:该人物信息处理过程中的待办事项 person_self_designation:用于抄写员的字段:抄写员对自身的描述 person_office:用于抄写员的字段:人物的官方头衔 6. 参考文献表 参考文献并非采用原架构中的单一表结构,而是建模为具体的实体类型,包括: article(文章)、book(图书)、book_chapter(图书章节)、blog_post(博客文章)、bib_varia(其他文献:该表通常不常用,用于存储无法归类至其他文献类型的条目)、online_source(在线资源)、phd(博士学位论文)。 每一类文献实体均拥有: 1. 如上文所述的专属数据表 2. 对应的_person_role关联表(例如:article_person_role可存储某篇文章的作者、贡献者、审稿人等信息) 3. 用于关联至其描述对象的关联表: manuscripts(手稿关联表:例如manuscript_article表存储与某一手稿相关的文章) occurrence(实例关联表:例如occurrence_book表存储与某一实例相关的图书) persons(人物关联表:例如person_article表存储与某一(通常为历史)人物相关的文章) type(文本类型关联表:例如type_article表存储与某一文本类型相关的文章) 额外结构:期刊(journal)与期刊期号(journal_issue):文章可关联至期刊与期刊期号。 请注意,目前部分参考文献表仅为完整性而添加:并非每一类概念(手稿、实例、人物、文本类型)均已关联至所有类型的参考文献(例如在线资源、博士学位论文等)。 查找/元数据表 roles:定义人物的角色(例如:作者、抄写员、贡献者等) text_status:实例或文本的文本状态(例如:文本完全已知、文本部分未知等) keywords:用于实例与文本类型的关键词(例如:圣三一、七贤、末日审判等) tag:文本类型的标签:用于说明文本类型的功能(例如:引入主题、对内容进行评论等)。 metre:格律分类(例如:十二音节诗、挽歌体等) genre:体裁分类(例如:与抄写员相关的书铭、与文本相关的书铭、与读者相关的书铭) management:管理元数据(例如:待核查的参考文献) acknowledgement:与实例、手稿、文本类型或人物相关的致谢内容(例如:手稿信息由X先生提供) editorial_status:文本类型的编辑状态,目前仅包含"(非)批判性文本"两种选项。 self_designation:抄写员对自身的描述 office:人物的官方头衔 location:可关联至手稿、图书馆、人物等的地点信息 library:图书馆名称与地点。请注意:手稿名称的格式固定为「城市 - 图书馆 - 馆藏 - 架号」 collection:馆藏元数据。请注意:手稿名称的格式固定为「城市 - 图书馆 - 馆藏 - 架号」 content:用于存储手稿的主题内容。请注意:该表为层级结构。例如,某手稿的主题可分为《圣经》→《新约》,该表中仅存储最低层级的节点(即《新约》),可通过该表的parent_id字段追溯完整的主题层级。 identification:人物或手稿的标准标识方式(例如:Diktyon标识) 如有关于本数据集的疑问或反馈,请联系技术负责人:paulien.lemay@ugent.be
提供机构:
Zenodo
创建时间:
2026-04-27
二维码
社区交流群
二维码
科研交流群
商业服务