語義網和關聯數據就像外太空:那裡沒有生命。 去那里或多或少長期……我不知道他們小時候對你說什麼來回應“我想成為一名宇航員”。 但是你可以在地球上看到正在發生的事情; 成為業餘天文學家甚至專業人士要容易得多。
本文將關注 RDF 存儲領域最新的、不超過幾個月的趨勢。 第一段中的比喻靈感來自剪裁下的史詩宣傳圖片。
一、RDF 訪問的 GraphQL
開箱即用,這個機會由:
如果存儲庫不提供這樣的機會,則通過編寫適當的“解析器”(resolver)來獨立實現。 例如,這是在法國項目中完成的
從語義 Web 和關聯數據的正統擁護者的角度來看,所有這一切當然是令人難過的,因為它似乎旨在用於圍繞下一個數據孤島構建的集成,而不是合適的平台(當然,RDF 存儲) .
比較 GraphQL 和 SPARQL 的印像是雙重的。
- 一方面,GraphQL 看起來像是 SPARQL 的遠親:它解決了 REST 典型的重选和多重查詢問題——如果沒有這些,可能就無法考慮 查詢語言,至少對於網絡而言;
- 另一方面,GraphQL 的剛性方案令人不安。 因此,與 RDF 的完全反身性相比,它的“內省性”似乎非常有限。 並且沒有屬性路徑的模擬,所以它甚至不是很清楚為什麼它是“Graph-”。
二。 MongoDB 適配器
與前一個趨勢互補的趨勢。
- 現在在星狗
也許 - 特別是,所有都在同一個 GraphQL 上 - 將 MongoDB 數據的顯示配置為虛擬 RDF 圖; - Ontotext GraphDB 最近
它允許 插入到 MongoDB 查詢的 SPARQL 片段中。
更廣泛地說,關於 JSON 源的適配器允許或多或少地“即時”將存儲在這些源中的 JSON 表示為 RDF,那麼我們也可以在相當長的一段時間內回憶起現有的適配器
總結前兩個趨勢,我們可以說 RDF 存儲庫展示了在“多存儲”(多語言持久性)條件下集成和運行的充分準備。 然而,眾所周知,後者早已過時,取而代之的是
總之,沒辦法。 我想單獨寫一篇文章來討論多模型 DBMS,但是現在你可以看到,現在還沒有“基於”圖模型(RDF 可以被認為是它的變體)的多模型 DBMS。 一些小型多模型——由替代 LPG 圖模型的 RDF 存儲支持——將在中討論
三、 OLTP 對比聯機處理程序
然而,同一個 Gartner
但是在 OLTP-OLAP 範圍內,RDF 存儲庫在哪裡? 我會這樣回答:不在那裡也不在這裡。 為了表明它們的用途,需要一些第三種縮寫。 作為一種選擇,我建議 聯機處理 — 在線智能處理。
然而,仍然:
現在讓我向市場介紹一位新玩家。 來自 IBM Netezza 和 Amazon Redshift 的創建者 -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
四、 岩石數據庫
以上已經
首先,通過判斷
其次,相應主題的項目(即非產品)是在RocksDB上做的。
例如,eBay 在中使用 RocksDB
另一個例子——出現在幾個月前
五、液化石油氣支持
讓我提醒您 LPG 圖和 RDF 圖之間的主要區別。
在 LPG 中,標量屬性可以附加到邊緣實例,而在 RDF 中它們只能附加到邊緣“類型”(但不僅是標量屬性,還有普通鏈接)。 與液化石油氣相比,RDF 的這種局限性
顯然,“支持液化石油氣”的任務分為兩部分:
- 對 RDF 模型進行更改,使其可以在其中模擬 LPG 構造;
- 對 RDF 查詢語言進行更改,使訪問此修改後的模型中的數據成為可能,或者實現以流行的 LPG 查詢語言查詢此模型的能力。
五.1. 數據模型
這裡有幾種可能的方法。
五.1.1。 單例屬性
協調 RDF 和 LPG 的最直接的方法可能是
- 而不是,例如,謂詞
:isMarriedTo
使用謂詞:isMarriedTo1
,:isMarriedTo2
等等 - 這些謂詞然後成為新三元組的主題:
:isMarriedTo1 :since "2013-09-13"^^xsd:date
等等 - 這些謂詞實例與一個共同謂詞的聯繫是由以下形式的三元組建立的
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo
. - 顯然那
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type
,但考慮一下為什麼你不應該只寫:isMarriedTo1 rdf:type :isMarriedTo
.
“LPG 支持”的任務在這裡在 RDFS 級別解決。 這樣的決定需要包含在相關的
五.1.2。 正確完成具體化
不那麼幼稚的方法源於對屬性實例由三元組完美實例化的認識。 通過能夠討論三元組,我們也可以討論屬性實例。
這些方法中最可靠的是
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .
五.1.3。 其他方法
您可以不用理會形式語義,只需考慮三元組有一些標識符,當然是 URI,並用這些 URI 組成新的三元組。 剩下的就是在 SPARQL 中授予對這些 URI 的訪問權限。 所以
在快板中
:bob :marriedTo :alice {"since" : "2013-09-13"}
五.2. 查詢語言
在模型級別以一種或另一種方式支持 LPG 後,您需要能夠在此類模型中查詢數據。
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- Anzograph 還支持
SPARQL* 並將支持暗號 , Neo4j 中的查詢語言。 - Stardog 維護自己的
延期 SPARQL 和再次 格林姆林。 您可以使用如下方式在 SPARQL 中獲取三元組的 URI 和“元信息”:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}
- Allegrograph也支持自己的
延期 SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
順便說一下,GraphDB 曾一度支持 Tinkerpop/Gremlin,但不支持 LPG,但在 8.0 或 8.1 版本中停止了。
六。 收緊許可證
最近沒有添加到“triplestore of choice”和“open source triplestore”集的交集。 新的開源 RDF 存儲遠不是日常使用的好選擇,我想使用的新三元組存儲的源代碼(例如 AnzoGraph)已關閉。 相反,我們可以談論減少......
當然,以前的開源也不是封閉的,只是一些開源的倉庫逐漸不被認為是值得選擇的了。 在我看來,擁有開源版本的 Virtuoso 充滿了錯誤。 Blazegraph 被 AWS 收購併構成了 Amazon Neptune 的基礎; 現在尚不清楚是否至少會再發布一次。 只剩下珍娜了……
如果開源不是很重要,只是想嘗試一下,那麼一切也沒有以前那麼美好了。 例如:
總的來說,對於一個普通的 IT 外行來說,空間變得越來越難以接近,它的發展正在成為企業的很多。
來源: www.habr.com