语义网和关联数据。 更正和补充

我想向公众展示这本最近出版的书的一个片段:

企业本体建模:方法与技术[正文]:专着/[S. V. Gorshkov、S. S. Kralin、O. I. Mushtak 等; 执行编辑 S. V. Gorshkov]。 - 叶卡捷琳堡:乌拉尔大学出版社,2019 年。- 234 页:插图,标签; 20 厘米 - 授权。 列在山雀的背面。 和。 ——书目学家。 在通道的末尾。 - ISBN 978-5-7996-2580-1:200 份。

将这段片段放在哈布雷身上的目的有四个:

  • 如果某人不是受人尊敬的客户,则不太可能有人能够将这本书拿在手中 哔叽指数; 绝对不是卖的。
  • 对文本进行了更正(它们未在下面突出显示)并进行了与印刷专着格式不太兼容的添加:主题注释(在剧透下)和超链接。
  • 想要 收集问题和意见当此文本以修订形式包含在任何其他版本中时,将它们考虑在内。
  • 许多语义网和关联数据的拥护者仍然觉得他们的圈子太窄了,主要是因为大众还没有被恰当地解释成为语义网和关联数据的拥护者有多么伟大。 该片段的作者虽然属于这个圈子,但并不坚持这种观点,但是,尽管如此,他认为自己有义务进行另一次尝试。

因此,

语义网

互联网的演变可以表示如下(或按以下顺序谈论其形成的部分):

  1. 互联网上的文件. 关键技术——Gopher、FTP等。
    Internet 是用于交换本地资源的全球网络。
  2. 互联网文件. 关键技术是 HTML 和 HTTP。
    暴露资源的性质考虑了传输介质的特性。
  3. 互联网数据. 关键技术有REST和SOAP API、XHR等。
    互联网应用时代,不仅人成为了资源的消费者。
  4. 互联网数据. 关键技术是关联数据技术。
    这个第四阶段,由第二阶段关键技术的创造者和 W3C 的主席 Berners-Lee 预测,称为语义 Web; 关联数据技术旨在使网络上的数据不仅是机器可读的,而且是“机器可理解的”。

从下文中,读者将清楚第二阶段和第四阶段的关键概念对应:

  • URL 的类似物是 URI,
  • HTML 类似于 RDF,
  • HTML 超链接类似于 RDF 文档中的 URI 条目。

语义 Web 更像是对 Internet 未来的系统愿景,而不是特定的自发或游说趋势,尽管它也能够考虑后者。 例如,所谓的 Web 2.0 的一个重要特征被认为是“用户生成的内容”。 它被要求考虑到这一点,特别是 W3C 的建议“Web 注释本体“以及这样的承诺 固体.

语义网死了吗?

如果你拒绝 不切实际的期望,语义网的情况与发达社会主义时期的共产主义大致相同(让每个人自己决定是否遵守伊里奇的条件戒律)。 搜索引擎 相当成功 强制网站使用 RDFa 和 JSON-LD,并且他们自己使用与下述技术相关的技术(Google 知识图、Bing 知识图)。

笼统地说,作者不能说是什么阻止了更大的传播,但他可以根据个人经验来说话。 在 SW 攻势的条件下,有些任务可以“开箱即用”地解决,尽管不是很大。 结果,那些有这些任务的人没有对那些能够提供解决方案的人进行胁迫的手段,而后者自己通过后者提供解决方案是违背他们的商业模式的。 所以我们继续解析 HTML 并粘合各种 API,一个接一个。

然而,关联数据技术已经超越了大众网络。 事实上,这本书专门介绍它们的应用。 目前,关联数据社区期望这些技术随着 Gartner 修复(或宣布,无论你喜欢什么)趋势变得更加广泛,例如 知识图 и 数据结构. 我愿意相信这些概念的“自行车”实现不会成功,但与下面讨论的 W3C 标准相关的那些。

关联数据

Berners-Lee 将关联数据定义为正确运行的语义 Web:一组实现其最终目标的方法和技术。 关联数据的基本原理 Berners-Lee 挑出 下列的。

原则1. 使用 URI 来命名实体。

URI 是全局实体标识符,而不是条目的本地字符串标识符。 随后,这一原则在谷歌知识图标语“东西,不是字符串“。

原则2. 在 HTTP 方案中使用 URI,以便它们可以取消引用。

通过引用 URI,应该可以得到该指示符后面的指示符(类比运算符的名称“*» 在 C 中); 更准确地说,根据 HTTP 标头的值获得此符号的某种表示形式 Accept:. 也许随着 AR/VR 时代的到来,将有可能获取资源本身,但就目前而言,最有可能的是 RDF 文档,它是 SPARQL 查询的结果 DESCRIBE.

原则3. 使用 W3C 标准——主要是 RDF(S) 和 SPARQL——尤其是在取消引用 URI 时。

关联数据技术堆栈的这些单独“层”,也称为 语义网层蛋糕,下面会介绍。

原则4. 在描述实体时使用对其他 URI 的引用。

RDF 允许您将自己限制在用自然语言对资源进行口头描述,第四条原则要求不要这样做。 在普遍遵守第一原则的情况下,在描述资源时可以引用其他资源,包括“外来”资源,这就是数据被称为链接的原因。 事实上,使用 RDFS 字典中命名的 URI 几乎是不可避免的。

RDF

RDF (资源描述框架)- 一种描述相互关联的实体的形式。

关于实体及其关系,形成了“主语-谓语-宾语”形式的陈述,称为三元组。 在最简单的情况下,主语、谓语和宾语都是 URI。 同一个 URI 可以在不同位置的不同三元组中:是主语、谓语和宾语; 因此,三元组形成一种称为 RDF 图的图。

主题和客体不仅可以是 URI,还可以是所谓的 空节点, 对象也可以是 文字. 文字是原始类型的实例,由字符串表示和类型规范组成。

写文字的例子(在 Turtle 语法中,更多内容见下文): "5.0"^^xsd:float и "five"^^xsd:string. 带类型的文字 rdf:langString 也可以提供语言标签,在Turtle中是这样写的: "five"@en и "пять"@ru.

空节点是没有全局标识符的“匿名”资源,但是可以声明全局标识符; 某种存在变量。

所以(这实际上是 RDF 的全部本质):

  • 主题是一个 URI 或一个空节点,
  • 谓词是一个 URI,
  • object 是 URI、空节点或文字。

为什么谓词不能是空节点?

可能的原因是希望非正式地理解三元组并将其翻译成一阶谓词逻辑的语言。 s p o 像这样的东西 语义网和关联数据。 更正和补充哪里 语义网和关联数据。 更正和补充 - 谓词, 语义网和关联数据。 更正和补充 и 语义网和关联数据。 更正和补充 - 常量。 文件中有这种理解的痕迹“LBase:语义网语言的语义学”,具有 W3C 工作组注释的地位。 有了这样的理解,三胞胎 s p []哪里 [] - 一个空节点,将被翻译为 语义网和关联数据。 更正和补充哪里 语义网和关联数据。 更正和补充 - 变量,但如何翻译 s [] o? W3C 推荐文档》RDF 1.1 语义” 提出了另一种翻译方式,但仍未考虑谓词为空节点的可能性。

然而,马努·斯波尼 允许.

RDF 是一个抽象模型。 RDF 可以用各种语法编写(序列化): RDF / XML, (大多数人可读) JSON-LD, 热电偶 (二进制)。

相同的 RDF 可以以不同的方式序列化为 RDF/XML,因此,例如,使用 XSD 验证生成的 XML 或尝试使用 XPath 提取数据是没有意义的。 类似地,JSON-LD 不太可能满足普通 Javascript 开发人员使用 Javascript 点和方括号表示法处理 RDF 的愿望(尽管 JSON-LD 正朝着这个方向发展,提供一种机制 构图).

大多数语法都提供了缩短长 URI 的方法。 例如,广告 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 然后在 Turtle 中将允许您改为编写 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 只是 rdf:type.

分布式文件系统

分布式文件系统 (RDF Schema) - 基本建模词汇,介绍属性和类的概念,以及属性如 rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range. 例如,使用 RDFS 字典,可以编写以下有效表达式:

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS 是描述和建模词汇表,但不是约束语言(尽管官方规范和 树叶 这种使用的可能性)。 “Schema”一词不应理解为与“XML Schema”表达相同的含义。 例如, :author rdfs:range foaf:Person 意思是 rdf:type 所有属性值 :author - foaf:Person,但不代表这个要提前说。

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language)是一种针对RDF数据的查询语言。 在一个简单的例子中,SPARQL 查询是一组样本,查询图的三元组与之匹配。 变量可以放在模式中主语、谓语和宾语的位置。

查询将返回这样的变量值,当代入样本时,可以导致查询 RDF 图的子图(其三元组的子集)。 三元组的不同样本中的同名变量必须具有相同的值。

例如,对于上面的七个 RDFS 公理集,以下查询将返回 rdfs:domain и rdfs:range 作为价值观 ?s и ?p 分别:

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

值得注意的是,SPARQL 是声明式的,不是图形遍历语言(但是,一些 RDF 存储库提供了调整查询执行计划的方法)。 因此,一些标准的图问题,例如寻找最短路径,无法在 SPARQL 中解决,包括使用该机制 属性路径 (但是,同样,各个 RDF 存储库为这些任务提供了特殊的扩展)。

SPARQL 不认同世界开放性的假设,遵循“否定即失败”的方法,其中 有可能 结构如 FILTER NOT EXISTS {…}. 使用该机制考虑数据分布 联合查询.

SPARQL 访问点是一个能够处理 SPARQL 查询的 RDF 存储,没有第二阶段的直接类似物(请参阅本段开头)。 它可以比作一个数据库,基于生成 HTML 页面的内容,但外部可以访问。 SPARQL 访问点更像是第三阶段的 API 访问点,但有两个主要区别。 首先,可以将多个“原子”查询合并为一个(这被认为是 GraphQL 的一个关键特性),其次,这样的 API 是完全自文档化的(HATEOAS 试图实现这一点)。

论战言论

RDF 是一种在 Web 上发布数据的方式,因此 RDF 存储库应被视为文档 DBMS。 的确,由于 RDF 是图而不是树,所以它们同时也是图。 令人惊讶的是,它完全奏效了。 谁能想到会有聪明人实现空白节点。 这里是科德 没有解决.

还有一些不太全功能的方法来组织对 RDF 数据的访问,例如, 关联数据片段 (LDF) 和 关联数据平台 (自民党)。

猫头鹰

猫头鹰 (Web Ontology Language) - 知识表示的形式主义,描述逻辑的句法版本 语义网和关联数据。 更正和补充 (下面的所有地方都更正确地说 OWL 2,OWL 的第一个版本是基于 语义网和关联数据。 更正和补充).

OWL中描述逻辑的概念对应于类,角色对应于属性,个体保留原名。 公理也称为公理。

例如,在所谓的 曼彻斯特语法 对于 OWL 符号,我们已经知道的公理 语义网和关联数据。 更正和补充 会这样写:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

写 OWL 还有其他的语法,比如 功能语法,在官方规范中使用,并且 猫头鹰/XML. 此外,OWL 可以序列化 抽象的 RDF 句法 并且在未来 - 在任何特定的语法中。

OWL 相对于 RDF 是双重的。 一方面,它可以看作是一种扩展 RDFS 的字典。 另一方面,它是一种更强大的形式主义,RDF 只是一种序列化格式。 并非所有基本的 OWL 构造都可以用单个 RDF 三元组来编写。

根据允许使用 OWL 结构的哪个子集,人们谈到所谓的 猫头鹰简介. 标准化和最著名的是 OWL EL、OWL RL 和 OWL QL。 配置文件的选择会影响典型问题的计算复杂性。 一套完整的 OWL 设计相匹配 语义网和关联数据。 更正和补充,称为 OWL DL。 有时人们也谈到 OWL Full,其中 OWL 结构被允许以 RDF 固有的完全自由使用,没有语义和计算限制。 语义网和关联数据。 更正和补充. 例如,某物既可以是类又可以是属性。 OWL Full 无法解析。

OWL 中附加后果的关键原则是接受开放世界假设(open world assumption, OWA) 和拒绝唯一名称假设, ). 下面我们将看到这些原则可以导致什么,并介绍 OWL 的一些结构。

让本体包含以下片段(曼彻斯特语法):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

是否可以从上面所说的约翰有很多孩子得出结论呢? 拒绝 UNA 会迫使推理机以否定的方式回答这个问题,因为 Alice 和 Bob 很可能是同一个人。 为了使下面的事情发生,我们需要添加以下公理:

DifferentIndividuals: Alice, Bob, Carol, John

现在让本体片段具有以下形式(约翰被宣布有很多孩子,但他只有两个孩子):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

这个本体会不会不一致(可以解释为无效数据的证据)? 接受 OWA 将导致推理机做出否定响应:“其他地方”(在不同的本体中)很可能会说 Carol 也是 John 的孩子。

为了消除这种可能性,让我们添加一个关于 John 的新事实:

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

为了排除其他孩子的出现,假设“有孩子”属性的所有值都是人,其中我们只有四个:

ObjectProperty: hasChild
   Domain: Human
   Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

现在本体将变得不一致,推理机将不会报告失败。 使用最后一个公理,我们有点“封闭”了世界,并注意到约翰是他自己孩子的可能性是如何被排除的。

链接企业数据

一组方法和技术关联数据最初旨在用于在网络上发布数据。 在企业内部环境中使用它们面临着许多困难。

例如,在封闭的企业环境中,OWL 基于采用 OWA 和拒绝 UNA 的演绎能力,由 Web 的开放和分布式特性驱动的解决方案太弱了。 并且这里可能有以下输出。

  • 赋予OWL语义,意味着拒绝OWA而采用UNA,实现相应的推理引擎。 - 沿着这条路 Stardog RDF 存储库。
  • 放弃 OWL 的演绎能力,转而使用规则引擎。 - 星狗支持 SWRL; Jena 和 GraphDB 提供 自己 语言 规则。
  • 拒绝OWL的演绎能力,使用接近RDFS的一个或另一个子集进行建模。 - 在下面查看更多相关信息。

另一个问题是企业界更加关注数据质量问题以及关联数据堆栈中数据验证工具的缺乏。 输出如下。

  • 同样,使用具有封闭世界语义和名称唯一性的 OWL 构造来验证是否存在合适的推理引擎。
  • 使用 SHACL,在 Semantic Web Layer Cake 层列表固定后标准化(但是,它也可以用作规则引擎),或者 上海证券交易所.
  • 意识到一切最终都是由 SPARQL 查询完成的,使用它们创建您自己的简单数据验证机制。

然而,即使完全拒绝演绎功能和验证工具,关联数据堆栈也会在类似于开放和分布式网络的任务中竞争——在数据集成任务中。

常规的企业信息系统怎么样?

这是可能的,但人们当然应该清楚适当的技术必须解决哪些问题。 我将在这里描述开发参与者的典型反应,以展示从传统 IT 的角度来看这个技术堆栈的样子。 让我想起了大象的寓言:

  • 业务分析师: RDF 有点像直接存储的逻辑模型。
  • 系统分析:RDF就像 EAV,只有一堆索引和方便的查询语言。
  • 开发人员: 嗯,这都是本着丰富模型和低代码概念的精神, 我读 最近关于它。
  • 项目经理: 是的 折叠堆栈!

实践表明,堆栈最常用于与数据的分布和异构性相关的任务,例如,在构建 MDM(主数据管理)或 DWH(数据仓库)类的系统时。 任何行业都存在这样的问题。

至于特定行业的应用,关联数据技术目前在以下行业中最为流行。

  • 生物医学技术(它们的受欢迎程度似乎与主题领域的复杂性有关);

局部的

前几天在“沸点”,由“国家医学知识库”协会组织的会议召开了“本体的统一。 从理论到实际应用“。

  • 复杂产品的制造和运营(大型工程、石油和天然气生产;通常它是一个标准 ISO 15926 );

局部的

这也是因为学科领域的复杂性,例如在上游阶段,如果我们谈论石油和天然气行业,一个简单的会计需要有一些 CAD 功能。

2008 年,雪佛龙举办了一次具有代表性的安装 会议.

ISO 15926 最终对石油和天然气行业来说似乎有点沉重(并且在机械工程中的使用几乎更多)。 在整个挪威,只有挪威国家石油公司 (Equinor) 彻底迷上了他 生态系统. 其他人正在尝试做他们自己的事情。 例如,据传,国内能源部打算创建一个“燃料和能源综合体的概念本体模型”,显然类似于 为电力行业而生.

  • 金融机构(甚至 XBRL 也可以看作是 SDMX 和 RDF 数据立方体本体的混合体);

局部的

今年年初,LinkedIn 积极向作者发送垃圾邮件,向作者发送几乎所有金融业巨头的职位空缺,他从电视剧《金装律师》中认识这些公司:Goldman Sachs、JPMorgan Chase 和/或 Morgan Stanley、Wells Fargo、SWIFT/Visa/万事达卡、美国银行、花旗集团、美联储、德意志银行……每个人可能都在找人寄给 知识图谱大会. 不少人发现:金融机构霸占一切 第一天早上.

在 HeadHunter 上,只有 Sberbank 发现了一些有趣的东西,它是关于“具有类似 RDF 的数据模型的 EAV 存储”。

或许,中西方金融机构对相应技术的喜爱程度的差异是由于后者活动的跨国性。 显然,跨国界的整合需要在组织和技术上有质的不同的解决方案。

  • 具有商业应用的问答系统(IBM Watson、Apple Siri、Google Knowledge Graph);

局部的

顺便说一下,Siri 的创建者 Thomas Gruber 是将本体论(在 IT 意义上)定义为“概念化规范”的作者。 在我看来,这个定义中的单词重新排列并没有改变它的意思,这也许表明它不存在。

  • 结构化数据的发布(有充分的理由这已经可以归因于链接开放数据)。

局部的

关联数据的忠实拥护者是所谓的 GLAM:画廊、图书馆、档案馆和博物馆。 在这里我只想说,为了取代 MARC21,美国国会图书馆正在推动 书目框架为书目着录的未来奠定基础 当然还有基于 RDF 的。

维基数据经常被引用为链接开放数据领域成功项目的例子——一种机器可读版本的维基百科,其内容与 DBPedia 不同,不是通过从信息框导入文章生成的,而是或多或少是手动创建的(随后成为相同信息框的信息源)。

也推荐复习 Stardog 网站“客户”部分中 Stardog RDF 存储库的用户。

尽管如此,在 Gartner 2016 年“新兴技术的成熟度曲线” “企业分类学和本体论管理”正处于失望谷的中间地带,有望在 10 年内达到“生产力高原”。

连接企业数据

预测、预测、预测……

出于对历史的兴趣,我在下表中总结了 Gartner 多年来对我们感兴趣的技术的预测。

技术 报告 位置 几年到高原
2001 语义网 新兴技术 创新触发 5-10
2006 企业语义网 新兴技术 膨胀期望的高峰期 5-10
2012 语义网 大数据运用 膨胀期望的高峰期 > 10
2015 关联数据 高级分析和数据科学 幻灭的低谷 5-10
2016 企业本体管理 新兴技术 幻灭的低谷 > 10
2018 知识图 新兴技术 创新触发 5-10

然而,已经在 “炒作周期……”2018 另一个上升趋势出现了——知识图谱。 某种轮回发生了:Graph DBMS,用户的注意力和开发者的力量竟然互换了,在前者的需求和后者的习惯的影响下,开始获取轮廓和定位他们的竞争对手前辈。

现在几乎每个图形 DBMS 都声称是构建企业“知识图谱”(“关联数据”有时被“关联数据”取代)的合适平台,但这种说法的合理性如何?

图数据库仍然是语义的,图 DBMS 中的数据仍然是相同的数据孤岛。 字符串标识符而不是 URI 使得集成两个图形 DBMS 的任务仍然是相同的集成任务,而集成两个 RDF 存储库通常只是合并两个 RDF 图的问题。 语义的另一个方面是 LPG 图模型的非自反性,这使得使用同一平台管理元数据变得困难。

最后,图形 DBMS 没有推理引擎或规则引擎。 此类引擎的结果可以通过复杂的查询来重现,但这甚至在 SQL 中也是可能的。

然而,领先的 RDF 存储库在支持 LPG 模型方面没有问题。 最可靠的是 Blazegraph 中一次提出的方法:RDF* 模型,它结合了 RDF 和 LPG。

详情

您可以在之前关于 Habré 的文章中阅读更多关于 RDF 存储对 LPG 模型的支持: “现在 RDF 存储库发生了什么”. 关于Knowledge Graphs和Data Fabric,希望有一天能单独写一篇文章。 最后一节,很容易理解,写的很匆忙,然而,即使过了六个月,这些概念也没有清楚多少。

文学

  1. Halpin, H., Monnin, A.(编)(2014 年)。 哲学工程:走向网络哲学
  2. Allemang, D., Hendler, J. (2011) 工作本体论语义网(第 2 版)
  3. Staab, S., Studer, R.(编辑)(2009 年)本体论手册(第 2 版)
  4. Wood, D.(编辑)。 (2011) 链接企业数据
  5. Keet, M. (2018) 本体工程简介

来源: habr.com

添加评论