Skip to content

Owlready2 图数据库文档

介绍

OwlreadyDB 是一个基于 Owlready2 库的图数据库实现，利用 SQLite 进行数据持久化。它继承自 LocalGraphDB 和 BaseGraphDB 类，提供了在本地环境中基于本体的图数据库操作功能，包括数据的存储、查询和操作。该类支持自然语言处理功能，通过词性标注（POS tagging）增强查询能力。

设计概述

OwlreadyDB 的主要目标是方便地在本地环境中进行基于本体的知识管理。其设计主要关注以下几个方面：

  1. 本体加载和管理：使用 OWX 文件定义本体结构，包括类（class）、属性（property）和实体（entity）。本体加载到 Owlready2 的 World 实例中，利用 SQLite 数据库进行数据持久化。

  2. 自然语言查询支持：集成了词性标注器（默认使用 JiebaPOSTagger），对用户输入进行分词和标注，使得可以使用自然语言查询知识图谱。

  3. 动态架构修改：允许在运行时动态添加、更新和删除类（cls）、属性（property）和实体（entity），提供了灵活性以适应不同的业务需求。

  4. 缓存机制：使用 TTLCache 实现缓存系统，提高查询性能，减少对数据库的频繁访问。

  5. 数据验证：确保外部数据和动态添加的元素符合本体的架构，并满足特定的要求。

数据格式要求

外部数据

当数据来自外部已经定义好的数据格式时，必须满足以下要求：

  1. 符合本体架构：外部数据必须与本体的结构相匹配。属性（properties）应与本体中定义的属性一致，数据类型必须兼容。

  2. 必要的注释（Annotations）：参与查询的类和属性必须定义特定的注释，以确保查询功能的正常运行。

  3. name_properties：类必须定义，用于标识实体的 DataProperty 列表。其值类型必须为 IRI，不能为字符串。注意name_properties中尽量避免使用 #name 因为owlready2会默认使用 name属性 作为实体的唯一标识。一旦某个property中IRI的名称被定义为 name，会与owlready2中出现一些冲突，这些冲突不会导致报错，因为Owlready2有自己的降级与容灾设计，但这会导致查询结果不准确，或者与预期不符，所以需要尽量避免 name 这个属性名的使用。

  4. pos：类必须定义，表示词性（Part of Speech）的字符串列表，遵循 ICTCLAS（或自定义）的规范。

  5. trigger_words：属性必须定义，如果希望属性参与查询。其值类型为字符串，用于在查询中触发属性。

动态添加的元素

当在程序运行时动态添加类、属性和实体时，需要满足以下要求：

类（cls）

  • 定义必要的注释：

  • name_properties：必须定义，指向用于标识实体的 DataProperty 列表。值类型必须为 IRI。

  • pos：必须定义，表示词性标签的字符串列表。

  • 名称规范：类名应使用帕斯卡命名法（PascalCase），名称应具有描述性，反映其在本体中的作用。

属性（property）

  • 定义域和范围：

  • domain：必须定义，属性适用的类列表。

  • range：必须定义，属性值的类型列表。

  • 参与查询的属性：

  • trigger_words：必须定义，值类型为字符串列表，用于在查询中触发该属性。

  • 特性：根据需要指定属性的特性，如 is_functional、is_symmetric 等。

  • 名称规范：属性名应使用驼峰命名法（camelCase），名称应清晰反映属性的作用。

实体（entity）

  • 所属类：实体必须属于本体中已定义的某个类。

  • 属性值：应为所有必需的属性提供值，确保数据完整性。

  • 名称规范：实体名称应唯一且具有描述性，且应包含在 name_properties 中，以便在查询中正确识别。

OWX 文件的要求

根据 validate_owx_file 函数，OWX 文件必须满足以下要求：

  1. 类的要求：

  2. name_properties：类必须定义该注释，其值类型必须为 IRI，且指向 DataProperty。

  3. pos：类必须定义该注释，表示词性标签。

  4. 属性的要求：

  5. trigger_words：属性必须定义该注释，其值类型为字符串。多个触发词需要定义多个 trigger_words，不能使用空格分隔。

如果 OWX 文件不满足上述要求，系统将无法正常加载，并会抛出相应的错误或警告。

数据查询逻辑

参与查询的字段

  • name_properties：用于匹配用户输入中的实体名称。

  • pos：用于在词性标注后识别用户输入中的相关类。

  • trigger_words：用于在用户输入中匹配属性的触发词，从而在查询中激活相应的属性。

查询流程

  1. 分词和词性标注：使用指定的分词器对用户输入进行分词和词性标注。

  2. 实体匹配：根据标注结果，使用 pos 来识别相关的类，并通过 name_properties 来匹配实体。

  3. 属性过滤：使用 trigger_words 来识别用户输入中涉及的属性。

  4. 实体检索：根据匹配的实体和属性，按照设定的召回深度 recall_depth，检索相关的实体。

  5. 结果返回：将查询结果序列化为指定的格式（默认 turtle），返回给用户。

命名格式与规范

  • IRI（国际化资源标识符）：

  • 使用一致的基础 IRI（例如 https://turingfocus.com/onto/tfrobot）以避免冲突。

  • 确保 IRI 唯一且具有描述性。

  • 类名：

  • 使用帕斯卡命名法（PascalCase），例如 Person、Organization。

  • 名称应能反映类在本体中的角色。

  • 属性名：

  • 使用驼峰命名法（camelCase），例如 hasName、locatedIn。

  • 名称应清晰表示属性的用途。

  • 实体名：

  • 应唯一且具描述性。

  • 确保实体名称包含在 name_properties 中，以便正确识别。

其它细节

异常处理

  • 验证错误：在加载 OWX 文件或添加动态元素时，系统会验证必要的注释和属性是否正确定义。如果验证失败，将抛出 ValueError 或发出警告。

  • 查询失败：如果 Owlready2 的 SPARQL 引擎无法解析查询，将降级使用 RDFLib 并发出警告，可能会影响性能。

缓存机制

  • TTLCache：用于缓存 rdflib 图对象，提高重复查询的性能。

  • 缓存刷新：在任何修改本体或数据的操作后，缓存会自动刷新，确保查询结果的准确性。

分词器集成

  • 动态词汇更新：在添加或更新实体时，其名称会添加到分词器的词汇表中，增强查询的准确性。

  • 自定义词性标签：支持自定义词性标签，但需要确保分词器能够正确处理这些标签。

方法装饰器

  • @refresh_cache_decorator：

  • 确保在任何修改本体的方法执行后，自动刷新缓存。

  • 保证本体状态与缓存数据的一致性。

SPARQL 查询处理

  • 验证：使用 is_valid_sparql 函数确保查询语句的语法正确。

  • 降级机制：如果主 SPARQL 引擎解析失败，系统会降级使用 RDFLib，并发出警告。

保存与持久化

  • save_and_refresh_onto：保存对本体的修改，并重新加载，确保内存中的状态与持久化存储一致。

  • 文件保存：提供 save_to_file 方法，可将本体导出为文件，用于备份或迁移。

实现参考

为了更深入地理解如何实现和扩展 OwlreadyDB，开发者可以参考系统中现有的实现，例如与 GPT 或 Claude 模型的交互。

关键注意事项

  • 错误识别：在处理异常时，特别是查询过程中，需要识别特定的错误模式，以便实施适当的降级机制。

  • 自定义：虽然基础实现提供了一般功能，但如果默认行为不满足需求，开发者可以自定义方法，例如 collapse_context 或 tokenize_str。

  • 测试与验证：建议进行广泛的测试，以确保动态添加和修改本体的操作符合预期，查询结果准确无误。

通过遵循上述文档和最佳实践，开发者可以有效地使用 OwlreadyDB 来管理本体，执行高级查询，并根据需要动态修改图数据库的结构。