知識圖譜改變銀行業務模式?基於GraphDB探索FIBO

譯者：AI研習社（季一帆）

雙語原文連結：Exploring FIBO Using the Inference and Property Path Features of GraphDB

---

簡介

本體或知識圖譜可不是隨拿隨用的，使用者需要做出相應的努力才能發揮其作用，使其成為有效可用的工具。我們知道，領域知識的用處極大，然而這些知識卻總是不完備的，將領域知識表示為圖中的數據可不容易。在這個過程中，關鍵在於將你掌握的領域知識完美匹配到圖中的知識表示。在本文中，我們將就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 所定義。

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 等步驟實現。其中，表單關鍵字包括：

其餘欄位使用默認值即可，以下為屏幕截圖：

接下來導入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中的推理

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推理庫缺失的子類關係：

究其原因，是因為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，該謂詞提供了可視化表示和詞彙表導航所必需的結構。skos:broader  和 skos:narrower三元組可用於降低對FIBO的本體需求。

skos:broader 和 skos:narrower可用於FIBO的高層本體，至於選擇何種方式，由使用者自行決定，可以單獨應用，也可以按一定策略結合SPARQL使用。

對兩種層次結構的lint check驗證了屬性路徑和推斷的實用性。每個詞彙概念都由本體中的實體定義，那麼哪些實體由於詞彙表沒有相應詞彙而進行了類層次結構的映射呢？

結構完整性約束

使用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愛好者。歡迎與譯站一起，學習新知，分享成長。

雷鋒網版權文章，未經授權禁止轉載。詳情見轉載須知。