主持人 > 博客 > 網絡新聞 > 語義網和關聯數據。 更正和補充

語義網和關聯數據。 更正和補充

我想向公眾展示這本最近出版的書的一個片段：

企業本體建模：方法與技術 [正文]：專著/[S. V. Gorshkov、S. S. Kralin、O. I. Mushtak 等； 執行主編 S.V.戈爾什科夫]。 - 葉卡捷琳堡：烏拉爾大學出版社，2019 年。- 234 頁：病態，表格； 20 公分 - 作者。 表示在背面的山雀上。 和。 — 參考書目在第 978 章的結尾— ISBN 5-7996-2580-1-200：XNUMX 份。

在哈布雷上發布此片段的目的有四：

  • 如果不是受人尊敬的客戶，任何人都不太可能擁有這本書。 塞爾日指數; 肯定是不賣的。
  • 對文字進行了更正（下面未突出顯示），並添加了與印刷專著的格式不太相容的內容：主題註釋（劇透下）和超連結。
  • 我想要 收集問題和意見，以便在任何其他出版物中以修訂形式包含此文本時考慮到它們。
  • 許多語義網和關聯數據的追隨者仍然認為他們的圈子如此狹窄，主要是因為公眾還沒有正確地解釋成為語義網和關聯數據的追隨者有多偉大。 該片段的作者雖然屬於這個圈子，但並不持這種觀點，但仍認為自己有義務再做一次嘗試。

因此，

語義網

互聯網的演變可以表示如下（或討論按下面所示的順序形成的各個部分）：

  1. 互聯網上的文檔。 關鍵技術—Gopher、FTP等
    互聯網是一個用於交換本地資源的全球網路。
  2. 網路檔案。 關鍵技術是 HTML 和 HTTP。
    公開資源的性質考慮了其傳輸介質的特性。
  3. 網路數據。 關鍵技術－REST和SOAP API、XHR等。
    網路應用時代，不僅人成為資源的消費者。
  4. 網路數據。 關鍵技術是關聯資料技術。
    第二個核心技術的創造者、W3C 總監伯納斯李 (Berners-Lee) 預言的第四個階段稱為語義網 (Semantic Web)； 關聯資料技術旨在使網路上的資料不僅是機器可讀的，而且是「機器可理解的」。

透過下文，讀者將了解第二階段和第四階段關鍵概念之間的對應關係：

  • URL 類似 URI，
  • HTML 的類似物是 RDF，
  • HTML 超連結類似於 RDF 文件中的 URI 出現。

語意網更多的是對網路未來的系統願景，而不是特定的自發性或遊說趨勢，儘管它可以考慮後者。 例如，所謂的 Web 2.0 的一個重要特徵被認為是「使用者產生的內容」。 特別是，W3C 建議應考慮到“Web註解本體「以及這樣的事業 素色.

語意網死了嗎？

如果你拒絕 不切實際的期望語意網的情況與已開發社會主義時期的共產主義大致相同（是否遵守伊里奇的有條件遺囑，讓大家自己決定）。 搜尋引擎 相當成功 強制網站使用 RDFa 和 JSON-LD，並且網站本身使用與下述技術相關的技術（Google 知識圖譜、Bing 知識圖譜）。

總的來說，作者無法說出是什麼阻止了更大的傳播，但他可以根據個人經驗來發言。 在西南攻勢的條件下，有些問題可以「開箱即用」解決，儘管這些問題不是很普遍。 因此，面臨這些任務的人無法對能夠提供解決方案的人進行強制，而後者獨立提供解決方案又與他們的商業模式相矛盾。 所以我們繼續解析 HTML 並將各種 API 黏合在一起，一個接一個更糟。

然而，關聯數據技術已擴展到主流網路之外。 事實上，這本書就是專門討論這些應用程式的。 目前，由於 Gartner 記錄（或宣布，隨你喜歡）趨勢，關聯數據社群預計這些技術將變得更加廣泛，例如 知識圖 и 數據結構。 我願意相信，這些概念的「自行車」實現不會獲得成功，但那些與下面討論的 W3C 標準相關的實現才會成功。

關聯數據

伯納斯-李將關聯資料定義為「正確完成」的語意網路：一組使其能夠實現最終目標的方法和技術。 關聯資料的基本原則 Berners-Lee 突出顯示 下列。

原則1。 使用 URI 來命名實體。

URI 是全域實體標識符，而不是條目的本機字串標識符。 隨後，這項原則在Google知識圖譜口號中得到了最好的表達“事物，而不是字串“。

原則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 的全部要點）：

  • subject 是一個 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是一種描述和建模詞彙，但不是一種約束語言（儘管官方規範和 葉子 此類使用的可能性）。 「模式」一詞不應被理解為與「XML 模式」這一表達方式相同的含義。 例如， :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是一種在網路上發布資料的方式，因此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，其中允許以 RDF 固有的完全自由的方式使用 OWL 結構，而沒有語義和計算限制 語義網和關聯數據。 更正和補充。 例如，某物可以既是類別又是屬性。 OWL Full 是不可判定的。

在 OWL 中附加後果的關鍵原則是採用開放世界假設。 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 的孩子。

為了排除這種可能性，讓我們加入一個關於約翰的新事實：

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

為了排除其他孩子的出現，假設屬性「有孩子」的所有值都是人，其中我們只有四個：

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

現在本體將變得矛盾，推理機不會不報告這一點。 從某種意義上說，透過最後一條公理，我們「封閉」了世界，並注意約翰是他自己的孩子的可能性是如何被排除的。

連結企業數據

關聯資料方法和技術集最初旨在用於在 Web 上發布資料。 它們在企業內部環境中的使用面臨許多困難。

例如，在封閉的企業環境中，基於Web的開放性和分散性質而做出的採用OWA和拒絕UNA的決策的OWL的演繹能力太弱。 這裡可以採用以下解決方案。

  • 賦予OWL語意，意味著放棄OWA而採用UNA，對應輸出引擎的實作。 - 沿著這條路 來了 Stardog RDF 儲存。
  • 放棄 OWL 的演繹能力，轉而使用規則引擎。 — 星狗 支持 SWRL; Jena 和 GraphDB 提供 自己 語言 規則
  • 拒絕OWL的演繹能力，使用接近RDFS的一個或另一個子集進行建模。 - 請參閱下面有關此內容的更多資訊。

另一個問題是企業界可能更加關注資料品質問題以及關聯資料堆疊中缺乏資料驗證工具。 這裡的輸出如下。

  • 同樣，如果有適當的推理引擎可用，則可用於驗證具有封閉世界語義和唯一名稱的 OWL 構造。
  • 使用 SHACL，在修復語義Web層蛋糕層清單後進行標準化（但是，它也可以用作規則引擎），或者 上海證券交易所.
  • 了解一切最終都是透過 SPARQL 查詢完成的，並使用它們創建您自己的簡單資料驗證機制。

然而，即使完全拒絕演繹功能和驗證工具，連結資料堆疊也會在與開放和分散式網路類似的資料整合任務中失去競爭。

常規的企業資訊系統怎麼樣？

這是可能的，但是您當然應該清楚相應的技術必須解決哪些問題。 我將在這裡描述開發參與者的典型反應，以展示從傳統 IT 的角度來看該技術堆疊是什麼樣子。 讓我想起了大象的寓言：

  • 業務分析師：RDF 類似於直接儲存的邏輯模型。
  • 系統分析：RDF就像 伊夫，只需要一堆索引和方便的查詢語言。
  • 開發人員：嗯，這都是本著豐富模型和低程式碼概念的精神， 正在閱讀 最近關於這件事。
  • 專案經理: 是的，是一樣的 折疊堆疊!

實踐表明，堆疊最常用於與資料分佈和異質性相關的任務，例如建構MDM（主資料管理）或DWH（資料倉儲）類系統時。 任何行業都存在這樣的問題。

從產業應用來看，關聯數據技術目前在以下產業最受歡迎。

  • 生物醫學技術（其受歡迎程度似乎與領域的複雜性有關）；

目前的

《沸點》近日主辦了“全國醫學知識庫”協會主辦的會議“結合本體。 從理論到實際應用“。

  • 複雜產品的生產和營運（大型機械工程、石油和天然氣生產；我們最常談論的是標準 品質政策 ISO 15926);

目前的

這裡的原因也在於主題領域的複雜性，例如，在上游階段，如果我們談論石油和天然氣行業，簡單的會計需要一些 CAD 功能。

2008年，舉辦了由雪佛龍組織的代表性安裝活動 會議.

最終，ISO 15926 對於石油和天然氣行業來說似乎有點沉重（並且在機械工程中可能有更多的應用）。 只有挪威國家石油公司 (Equinor) 徹底迷上了它；在挪威，整個 生態系統。 其他人都在努力做自己的事情。 例如，據傳聞，國內能源部打算創建一個“燃料和能源綜合體的概念本體模型”，顯然類似於 專為電力產業打造.

  • 金融組織（甚至 XBRL 也可以被視為 SDMX 和 RDF 資料立方體本體的混合體）；

目前的

今年年初，LinkedIn 積極向作者發送了來自幾乎所有金融業巨頭的職缺職位，這些巨頭都是他在電視劇《不可抗力》中認識的：高盛、摩根大通和/或摩根士丹利、富國銀行、 SWIFT /Visa/Mastercard、美國銀行、花旗集團、聯準會、德意志銀行...可能每個人都在尋找可以發送給的人 知識圖譜大會。 不少人發現：金融機構拿走了一切 第一天早上.

在 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 另一個上升趨勢出現了──知識圖譜。 某種輪迴發生了：圖DBMS，使用者的注意力和開發者的努力發生了切換，在前者的需求和後者的習慣的影響下，開始有了輪廓和定位。他們的前任競爭對手。

現在幾乎每個圖 DBMS 都宣稱自己是建立企業「知識圖」的合適平台（「連結資料」有時會被「連結資料」取代），但這種說法的合理性如何？

圖資料庫仍然是語義化的；圖 DBMS 中的資料仍然是相同的資料豎井。 字串識別碼而不是 URI 使得整合兩個圖 DBMS 的任務仍然是一個整合任務，而整合兩個 RDF 儲存通常歸結為簡單地合併兩個 RDF 圖。 非語意性的另一個面向是 LPG 圖模型的非自反性，這使得使用相同平台來管理元資料變得困難。

最後，圖 DBMS 沒有推理引擎或規則引擎。 此類引擎的結果可以透過複雜的查詢來重現，但這甚至在 SQL 中也是可能的。

然而，領先的 RDF 儲存系統在支援 LPG 模型方面沒有任何困難。 最可靠的方法被認為是 Blazegraph 中一度提出的方法：RDF* 模型，結合了 RDF 和 LPG。

更

您可以在上一篇關於 Habré 的文章中閱讀有關 LPG 模型的 RDF 儲存支援的更多資訊： “RDF 存儲現在發生了什麼”。 我希望有一天能寫一篇關於知識圖和資料結構的單獨文章。 最後一節很容易理解，寫得很匆忙，然而，即使六個月後，這些概念並沒有變得更清晰。

文學

  1. Halpin, H.、Monnin, A.（編）（2014 年）。 哲學工程：邁向網路哲學
  2. Allemang, D., Hendler, J. (2011) 工作本體論者的語意網（第二版）
  3. Staab, S., Studer, R.（編）（2009）本體論手冊（第二版）
  4. 伍德，D.（編輯）。 (2011)連結企業數據
  5. Keet, M. (2018) 本體工程簡介

來源： www.habr.com

添加評論