知识图谱改变银行业务模式？基于GraphDB探索FIBO

雷锋网  •  扫码分享
我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。  

译者：AI研习社（ 季一帆 ）

双语原文链接： Exploring FIBO Using the Inference and Property Path Features of GraphDB

知识图谱改变银行业务模式？基于GraphDB探索FIBO

简介

本体 或 知识图谱 可不是随拿随用的，使用者需要做出相应的努力才能发挥其作用，使其成为有效可用的工具。我们知道，领域知识的用处极大，然而这些知识却总是不完备的，将领域知识表示为图中的数据可不容易。在这个过程中，关键在于将你掌握的领域知识完美匹配到图中的知识表示。在本文中，我们将就GraphDB特性进行一系列讨论，其中就包括上述的知识匹配/对齐。

FIBO概况

金融业业务本体（FIBO）是由企业数据管理委员会（ EDMC ）开发的金融行业概念模型，至今仍由EDMC支持着FIBO的 维护和开发 。FIBO的目标是在金融业务数据构件的描述中，提供独立于数据构件的精确含义。具体而言，FIBO包含构建、扩展及集成金融业务应用所需的实体和关联信息。由于FIBO基于RDF（S）和OWL，因此可以使用SPARQL和OWL推理进行分析。本文应用的版本（2020第2季度）包含以下内容：

  • 122个命名空间，表示模块结构；

  • 1542类别

  • 1328概念

  • 535断言

自2017年首次发布FIBO以来，受益于金融业的广泛参与，该标准已取得广大发展，并符合许多现有标准。从一个称为“语义知识库”的Excel工作簿开始，FIBO已经发展成为基于RDF和OWL的复杂本体。在这个过程中，还发展了其他一些意外成果，包括本体工程的实践指南，例如使用传统基于文本的版本控制系统的RDF文本稳定性，通过与对象管理组（OMG）的密切关系实现严格的元数据标准，以及对OWL推理能力的使用。更多细节可见 此处 。

FIBO的内容多种多样，其中，RDF和OWL本体是包含业务知识的核心实体。这些业务知识可表示为RDF-XML、Turtle、JSON-LD和N-Quads/N-Triples等形式。此外：

  • FIBO词汇表基于SKOS分类法，用于RDF-XML、Turtle和JSON-LD序列化的分类管理。

  • FIBO数据字典有.csv和.xlsx格式，包含FIBO中的操作类及其附带属性。

  • FIBO-DM是一种企业数据模型，可用作SAP PowerDesigner概念和逻辑数据模型。

在本文中，我们重点关注FIBO本体和词汇表。由于它们都使用RDF编码，因此可使用SPARQL和OWL推理进行分析。

两不同层次结构

FIBO词汇表中的所有概念都是由FIBO本体中的实体定义的。因此，这些概念包含有丰富的上下文信息，在应用中使用该词汇表会同时为用户提供这些信息。如， fibo-v-be:DomesticUltimateParent  由实体 fibo-be-oac-cctl:DomesticUltimateParent 所定义。

知识图谱改变银行业务模式？基于GraphDB探索FIBO

FIBO词汇表中的概念由  skos:broader   和 skos:narrower 两种不同层次的谓词进行定义。在上图中，Total Controlling Interest Party 是比 Domestic Ultimate Parent 更为宽泛的概念。在已公布的词汇表中，仅使用了  skos:broader 。如 SKOS 规范所述，“ skos:broader 和 skos:narrower  彼此相反。当概念X比概念Y表示更广泛时，意味着Y相对是X是更小、更准确的概念“ 。因此，从 fibo-v-be:TotalControllingInterestParty  到 fibo-v-be:DomesticUltimateParent   存在  skos:narrower  的关系。 

如果给定词汇表的层次结构和本体的层次结构，那么层次结构之间的关系是什么呢？ fibo-be-oac-cctl:DomesticUltimateParent  的每一个父类在词汇中都有对应概念吗？这些概念是否表达了 skos:broaderTransitive / skos:narrowerTransitive  与 fibo-v-be:DomesticUltimateParent 的层次结构？在本文的其余部分，我们将借助GraphDB解答这些问题。

FIBO导入GraphDB

GraphDB是Ontotext开发的一个可扩展、高性能的三元组数据库，其前身是OWLIM。当前的9.4.1版本支持RDF1.1、SPARQL 1.1和OWL2推理，此外还支持其他许多用于索引、可视化、分析和联合工具。同时，还提供有web访问的API（包括用于终端的SPARQL协议），因此可以结合任何编程语言使用。在下一节会展示该数据库对SPARQL1.1，OWL2推理及其规范属性路径的支持。

首先通过GraphDB创建一个存储库，通过导航窗口Setup -> Repositories > Create Repository 等步骤实现。其中，表单关键字包括：

  • Repository ID，本例中是 FIBO 。

  • Ruleset，本例中选择下拉菜单中的 OWL 2-RL (Optimized) 。

  • 选中“Use context index”，因为FIBO本体包含反映本体模块结构的命名图。

其余字段使用默认值即可，以下为屏幕截图：

知识图谱改变银行业务模式？基于GraphDB探索FIBO

接下来导入RDF图，有以下要求：

  1. 从 EDMC FIBO 本体站点下载 FIBO Production zipped N-Quads 发行版。本文使用为2020年第2季度版。

  2. 从 EDMC FIBO 词汇站点下载 FIBO Production zipped N-Quads 发行版。本文使用为2020年第2季度版。

  3. 从W3C获取所需的SKOS简单知识管理系统 http://www.w3.org/2004/02/skos/core# 。因为W3C具有 HTTP303重定向 功能，在web中浏览该URI会自动生成HTML，并在导入GraphDB时生成RDF。

为了提高效率，最好将FIBO下载到本地磁盘，存储到GraphDB的import目录，而SKOS直接通过internet下载。

从磁盘导入词汇表需要1秒，导入本体需要1分10秒，通过互联网导入sko需要2秒。之所以速度相差之大，是因为在导入过程中要执行推断操作。词汇表基于开放SKOS，借助生成新三元组的结构元素，词汇表和SKOS的导入训练。而由于在本体构建过程中OWL的复杂性，消耗了较长时间。最终，导入图谱的106187条显式语句生成405493条推断语句，总计511680条语句。需要注意的是，所有推断语句存在于默认图，同时该图还包含命名图中的所有语句。

使用GraphDB Workbench的Explore菜单中的类层次结构图能够获得本体概述，该图将子类表示为嵌套在父类中的圆：

知识图谱改变银行业务模式？基于GraphDB探索FIBO

GraphDB中的推理

OWL 2支持许多不同的推理机制，GraphDB为其中的一些程序 语言配置文件 提供支持。在GraphDB中，存储相关的语言配置文件由规则集合确定。无论是通过SPARQL插入数据还是直接导入图谱，只要将三元组添加到知识库中，就会调用专门的规则引擎——reasoner。除非不进行推理操作，否则任何规则集都通过额外的隐式三元组实现并存储，而不是显式插入的三元组。GraphDB的特殊指出在于，提交SPARQL DELETE操作后，将回收无效的推断语句。此外，存储内容和选定规则集决定了新建三元组的属性。例如，如果两个谓词的定义表明它们是相反的，那么当其中一个谓词出现在一个三元组时，将创建一个相应逆属性的三元组。

在本文的FIBO应用中，我们选择了OWL2RL语言配置文件，该配置适用于对可扩展推理有一定要求，同时保留一定表达能力的应用。我们还用RDF Schema（RDFS）规则集加载FIBO，该规则集非常简单，只包含rdfs:subPropertyOf, rdfs:subClassOf, rdfs:domain和rdfs:range。正如预期的那样，使用RDFS加载FIBO本体的NQ文件只需不到一秒钟，而使用OWL2RL则需要一分钟以上。但是，RDFS只推断出170804个隐式语句，比OWL2RL少2倍多，一些重要的推论被忽略。例如，执行以下查询将会提取出OWL2RL知识库存在但RDFS缺失的子类关系：

SELECT * WHERE {
 { SERVICE <repository:FIBO-RL> {
     ?sub_class rdfs:subClassOf ?super_class
     FILTER(?sub_class != ?super_class)
     FILTER(?super_class != owl:Thing)
     FILTER(contains(str(?sub_class),'fibo')
         && contains(str(?super_class),'fibo'))
 }  }
 FILTER NOT EXISTS {
         ?sub_class rdfs:subClassOf ?super_class
 }
}

GraphDB内部联合能够实现跨知识库的相同实例数据高效查询。以下是RDFS推理库缺失的子类关系：

知识图谱改变银行业务模式？基于GraphDB探索FIBO

究其原因，是因为RDFS推理器无法处理概念的定义。例如，Rate和Ratio类被定义为与以下语句等价：

fibo-fnd-qt-qtu:Rate owl:equivalentClass fibo-fnd-utl-alx:Ratio

在OWL2的所有语言配置文件中，这表示它们是彼此的子类，但RDFS语义却不是如此。

基于属性路径的增强推理

属性路径 是SPARQL的特殊属性，通过属性路径，能够在RDF图中跨不同三元组的节点。三元组是SPARQL中最简单的属性路径。

在FIBO本体中，类层次结构由及物谓词表示，即 rdfs:subClassOf 。FIBO词汇概念的层次结构由 不及物谓词 表示，如 skos:broader 。这意味着，本体的类层次结构与常用编程语言的层次结构的概念类似，如java、python和 C++ ，以及UML等规范语言。类层次结构被映射到谓词，然而由于无法精准表示预期，映射是有损的，谓词概念一般无法完整表达原有语义。

至于词汇表的使用，则是为了给领域特定词汇提供更广泛的上下文。因此，使用者必须区分他们的词汇结构和FIBO的词汇结构。因为层次结构隐式地反映了本体的及物类结构，所以任何情况下进行集成都要求外部词汇表与隐式FIBO层次结构相关联。

由于FIBO本体层次结构实际上是要映射到 skos:broaderTransitive 和 skos:narrower_transitive 谓词，因此通过推理可以缓解映射问题。将GraphDB知识库与OWL2RL (Optimized) 规则集配合使用，能够创建所有必需三元组。SKOS语义属性的顶层结构是 skos:semanticRelation ，该谓词提供了可视化表示和词汇表导航所必需的结构。 s kos:broader   和  skos:narrower 三元组可用于降低对FIBO的本体需求。

s kos:broader  和  skos:narrower 可用于FIBO的高层本体，至于选择何种方式，由使用者自行决定，可以单独应用，也可以按一定策略结合SPARQL使用。

对两种层次结构的lint check验证了属性路径和推断的实用性。每个词汇概念都由本体中的实体定义，那么哪些实体由于词汇表没有相应词汇而进行了类层次结构的映射呢？

结构完整性约束

知识图谱改变银行业务模式？基于GraphDB探索FIBO

使用SPARQL分析图谱

利用SPAERL查询语句，查找与类层次结构的概念槽子类相关联、但与FIBO词汇表的概念层次结构缺乏关联的类别。

Lint查询

SELECT DISTINCT ?parentEntity  where {
   ?concept a skos:Concept ;
            rdfs:isDefinedBy ?entity .
   # Every concept is defined by an entity
   ?entity rdfs:subClassOf ?parentEntity .
   # Exclude restrictions
   FILTER(ISIRI(?parentEntity))
   # Only consider resources in the FIBO namespaces
   FILTER(CONTAINS(str(?parentEntity),'fibo'))
   FILTER NOT EXISTS {
       # Find where there is no semantic relation
       # between concept and related concept
       ?relatedConcept rdfs:isDefinedBy ?parentEntity .
       # Consider the entire set of
       # related concepts in the hierarchy
       ?concept (skos:semanticRelation)+ ?relatedConcept
   }
}

至于词汇表和本体之间的属性路径，一部分依赖于 skos:semanticRelation ，另一部分依赖于 rdfs:subClassOf 。

skos：semanticRelation后面的加号（+）表示此谓词可用作与主语通过rdfs:subClassOf匹配的一个或多个谓语之间的路径。此外，在属性路径中可以执行其他许多操作，本文不再讨论，有兴趣的读者请查阅 SPARQL 1.1 Query language W3C Recommendation 21 March 2013 。

至此，我们得到一个知识库，该库包含FIBO本体和FIBO词汇表的显式和隐式RDF语句。执行lint查询将会生成不满足上述完整性检查的类列表：父类应该链接到词汇表中与相应子类相关的概念。

parentEntity  
 fibo-der-drc-swp:SwapLifecycleEventIdentifier
 fibo-fbc-fct-bc:BusinessCenterCodeScheme
 fibo-fbc-fct-breg:RegistrationAuthorityCode
 fibo-fbc-fct-fse:FinancialServiceProviderIdentifierScheme
 fibo-fbc-fct-rga:RegulationIdentificationScheme
 fibo-fbc-fct-rga:RegulationIdentifier
 fibo-fbc-fct-usjrga:FederalReserveDistrictIdentifier
 fibo-fbc-fi-fi:SecuritiesTransactionIdentifier
 fibo-fnd-arr-arr:CollectionConstituent
 fibo-fnd-arr-arr:DatedCollectionConstituent
 fibo-fnd-arr-arr:DatedStructuredCollection
 fibo-fnd-arr-arr:Scheme
 fibo-fnd-arr-arr:StructuredCollection
 fibo-fnd-dt-fd:CombinedDateTime
 fibo-fnd-gao-gl:Goal
 fibo-fnd-law-lcap:LicenseIdentifier
 fibo-fnd-oac-ctl:Control
 fibo-fnd-oac-oac:OwnershipAndControl
 fibo-fnd-oac-own:Ownership
 fibo-fnd-pas-pas:ProductIdentifier
 fibo-fnd-plc-adr:RegionSpecificIdentifier
 fibo-fnd-plc-loc:County
 fibo-fnd-plc-loc:FederalCapitalArea
 fibo-fnd-plc-loc:FederalState
 fibo-fnd-plc-loc:Parcel
 fibo-fnd-plc-uspsa:DeliveryAddressCodeSet
 fibo-fnd-plc-uspsa:DeliveryPointCodeSet
 fibo-fnd-plc-uspsa:ZipCodeScheme
 fibo-fnd-plc-vrt:NotionalPlace
 fibo-fnd-pty-pty:Situation
 fibo-fnd-rel-rel:Reference
 fibo-fnd-utl-alx:StatisticalAreaIdentifier
 fibo-sec-sec-iss:SecurityOfferingDistributionType

结论

FIBO是本体工程一个非常复杂的展示，需要由具有广泛金融知识以及具有丰富的本体及其管理知识的人员执行，只靠阅读代码是不够用的。为了最好的利用FIBO，需要借助GraphDB这样强大的工具，以充分利用FIBO的丰富知识来辅助开发。本文证明，在FIBO执行推理时，OWL2RL是比RDFS更好的选择。同时，结合推理和属性路径能够检测到一些结构性问题，这些技术的研究为大型、复杂的本体和知识图谱提供质量保证。

之后，我们会陆陆续续发布一系列相关文章，对如何使用图数据库引擎和语义技术来处理金融服务部门的本体和数据进行介绍。

AI研习社是AI学术青年和AI开发者技术交流的在线社区。我们与高校、学术机构和产业界合作，通过提供学习、实战和求职服务，为AI学术青年和开发者的交流互助和职业发展打造一站式平台，致力成为中国最大的科技创新人才聚集地。

如果，你也是位热爱分享的AI爱好者。欢迎与译站一起，学习新知，分享成长。

知识图谱改变银行业务模式？基于GraphDB探索FIBO

雷锋网版权文章，未经授权禁止转载。详情见。

知识图谱改变银行业务模式？基于GraphDB探索FIBO

随意打赏

提交建议
微信扫一扫，分享给好友吧。
关闭