很早我就聽說過語義網（Semantic Web；簡稱SW）這個概念，知道KDE（4）的Nepomuk引擎是基於SW技術構建的，再後來的Gnome Tracker也是。但直到讀博之後纔開始更經常接觸相關知識，意識到它（的技術）現在更常出現的名稱是關聯數據（Linked Data；簡稱LD）或知識圖譜（Knowledge Graph）；而網絡上其實也有很多SW知識庫實例，如DBpedia和Wikidata這兩個基於維基百科數據的相似但不同的項目。但由於相關知識很多，錯綜複雜，且我又不是專門做這個領域的，所以始終處於半懂不懂的狀態。

不過好在我確是喜歡它的理念，於是在不斷接觸之下，尤其是加入了Tim Berners-Lee所在的EWADA項目之後，我現在終於建立起了一個相對明確的認識。雖然肯定還不完善，但也足以整理下來，幫助後來者（比如讀了我之前寫的《Solid——簡介與體驗》或《論Web3.0和Web3》後進入Solid世界，或只是想瞭解語義網絡的人）快速建立認識。

本文不會涉及特別具體的定義等，比如具體的語法。如果想要深入，請點擊鏈接或善用搜索引擎去瞭解學習。

由於本文的性質，其內容不可避免會受我目前認識的侷限；而我也會儘量隨着我的認識的深入而不斷更新。行文也比較散，想到什麼寫什麼，沒有按常規的結構進行，還請擔待。

語義網、關聯數據以及知識圖譜——一點背景和歷史

語義網（絡）最初是爲了提高Web的機器可讀性以帶來（機器/程序/Agent的）操作性而提出的對Web（萬維網）的改進。雖然似乎並非是Tim最早提出，但Tim的確是支持者之一，而且也有很多相關貢獻。

在此之上，語義網相關研究使用以及提出了大量的技術和方案，最典型的例如：

• 描述手段RDF (Resource Description Framework)

  • 一種（或者說一類）很易理解和使用的結構化描述數據的方式

  • 本質上將數據組織成「圖」結構

• 本體（ontology）定義OWL (Web Ontology Language)

  • 定義類、屬性、類的信息等，以供RDF文檔使用

  • 某種意義上也算是描述了RDF文檔節點的「形狀」，但不是用來檢驗RDF文檔的

• 形狀描述SHACL和ShEx

  • 更具體的描述形狀的方案，且專門設計用來檢驗RDF文檔是否合規

• 推理規則SWRL（Semantic Web Rule Language）、OWL的DL（Description Logic）

  • 描述如何從RDF文檔中已有的信息自動推理出更多信息

  • 以邏輯爲基礎，具有多種理論保證和特點

• 查詢語言SPARQL

  • 類似SQL的易用的查詢RDF文檔（或者叫知識庫）的語言

• 給HTML增添語義的RDFa

  • 使得網頁可以直接內嵌語義，方便Agent使用

• 知識庫或SPARQL節點，如Apache Jena

這一切研究本質上都是爲了兩個目的服務：1. 如何更好的組織和驗證知識庫；2.如何更好地使用知識庫中的數據。研究者一般都不會忘掉語義網的大目標。不過出於種種原因，語義網的推廣並不理想。於是後來，語義網這個詞逐漸讓位給了更直接的概念，即關聯數據（Linked Data）。

這個「種種原因」的確很多，有技術上的，有實踐上的，也有商業上的。我個人覺得商業上的因素最重，畢竟如果我們回頭看看2004年以後的網絡發展，整個互聯網都是在逐步越來越封閉：先是還在基於萬維網的Web 2.0平臺化；然後是隨着iPhone而氾濫的「App」這一理念，逐步刪除任何互操作性的封閉平臺。整個發展狀況都和語義網所追求的互操作性互聯性背道而馳，但偏偏這樣又帶來大量利潤。

之所以關聯數據（LD）可以作爲語義網（SW）的替代用詞，本質上其實是因爲LD本身就是對SW最核心技術和標準的重新打包，但淡化了「努力全盤加裝在現有Web上」這個目標。RDF本質上就是一個圖，每個數據都是圖上的一個節點，那麼各個數據（節點）之間本身就是相互關聯/鏈接的。LD就是強調要重視數據之間的這種關聯性，使用RDF等一系列技術，而不是使用無關聯性的純文本，或是自行重新發明輪子造的弱化仿製版RDF。而且由於RDF中節點的ID本身是一個URI或URN，所以LD和Web的關係也沒有斬斷，而是可以靜待等待時機成熟捲土重來。Tim的SoLiD（Social Linked Data）其實就是有感於平臺壟斷化的氾濫，而嘗試使用LD來重建Web這個目標去的項目（參見《論Web3.0和Web3》）。

與此同時或稍晚一點，Google開始使用知識圖譜（Knowledge Graph）這一名稱來稱呼其所搭建的（基於RDF的）知識庫，以用來支持其搜索或AI/ML（尤其是NLP）技術。而隨着AI/ML技術討論的流行，知識圖譜逐漸成爲了絕大多數人首先乃至唯一聽說過的SW和LD技術實例和用法。

「知識圖譜」這個翻譯在NLP或感知類AI的語境下沒什麼問題，但在理解概念時會讓人的注意力有所偏差，尤其是其中的「譜」字比較誤導人。其技術（及英文原文）的核心在於這裏的「知識」是以「圖」的形式存儲/描述的，以區別於（例如）表格狀的關係型數據庫。其實在這個詞廣爲使用前，從傳統AI/邏輯而來的「知識庫」應當是更常用的一個詞。

雖說知識圖譜並不算是和語義網的目的相悖，但似乎它用到的主要是RDF的圖結構以及SPARQL等的查詢功能，或許再加上個OWL或推理，至於其他內容則不太在乎——畢竟和他們的ML研究關係不大。不過如果你接觸過知識圖譜，那麼其實你已經算是稍微接觸了SW了。

但同時經過上面的梳理可以看到，語義網的目標和研究以及技術應用遠遠大於它。不要把一種實例當成唯一作用。

RDF和其他技術的關係

RDF可以說是SW最核心的技術。當然這句話不是說RDF必須是核心或者RDF就是完美的方案，而是對現狀的一個總結。雖然人們討論過RDF的種種問題，但整體而言它是相當優秀的方案，足以支撐其上的一系列研究。

RDF的要點就是使用subject predicate object（主語 謂語 賓語）這樣的三元組來描述事物，並集合大量的三元組來形成數據/知識庫/知識圖譜。在此之外，RDF還引入前綴（prefix）的概念，一是簡化書寫，二是和OWL相連接：一般而言我們預期前綴就是一個ontology。

這個「前綴」和「命名空間」（namespace）的概念很像。但在RDF標準中，前綴並不要求一定是個有效定義（比如一個OWL文檔），而可以是任意東西；而命名空間一般都是一個有效的定義（域）。

當然在此之外，還有一些變體，用來解決特定的需求。比如在s p o的三元組上增加圖（graph）形成四元組，用來進一步框定三元組的來源，以表達語義或優化推理。

RDF是一個理論框架，但實際使用則需要有實際的序列化表示。這裏的選項有很多，而且一般都互相等價（除了那些支持額外特性的，這裏不討論），比較典型的例如：

• RDF/XML語法：核心標準，理論上所有框架都支持，但不夠適合人讀寫（XML寫起來太費事）；

• Turtle語法：簡練，適合人讀寫；

• JSON-LD語法：特化的JSON，也許更適合網絡使用。

SW和LD的許多相關技術都是基於RDF構建的，比如前面提到的那些：

• OWL的作用是輔助描述RDF資源，而且同時OWL也序列化成RDF文檔（某種很奇妙的互指涉/間接遞歸關係）；

• SHACL和ShEx都是用來描述RDF圖的形狀的；

• SPARQL是用來查詢RDF的知識庫的；

• SWRL或OWL DL描述如何從已有RDF中生成/演繹新的知識/信息。

這裏的「基於」同時代表兩方面的含義：1. 圍繞、擴展及使用RDF的功能；2. 其本身表示成RDF。並不是每一項技術都同時去做這兩面，但的確有不少這樣的例子（如OWL、SHACL等；參考後文）。

Turtle、N3和OWL

如前面所說，Turtle是一種RDF的序列化形式，或者也可以稱爲一種語言。它的核心特點就是簡潔，對人類友好。

N3也是一種語言，粗看之下和Turtle差不多。但N3和Turtle有很大不同，最主要的在於N3不只是序列化RDF，而還包含了其他內容，尤其是關於推理和查詢的支持——你可以直接在N3中描寫推理推則或者書寫查詢，且N3有對應的推理器；而RDF只是數據，沒有別的。

我並不完全確定Turtle和N3誰先被提出，但Turtle的確可以被看作是N3的RDF描述部分的子集，或者說N3是對Turtle的擴展。

N3的另一特點是它支持標準/核心RDF之外的一些內容，比如對圖的標註（類似RDF* (RDF Star)，但語法不同），比如它特定的built-in的特定語法及語義（如log:collectAllIn臨時的封閉世界假設查詢，或是提供linear logic推理）。

需要注意的是，N3的推理規則需要全部在N3中寫出，不會「繼承」其他來源的推理規則。例如由於OWL是有效的RDF文檔，N3中也可以引用OWL的概念，但並不自動具有OWL的推理定義，需要自行書寫（或導入/粘貼）。

OWL、SHACL以及數據檢查

OWL允許描述「類」和「屬性」的信息，比如某個類是另一個類的子類，某個類擁有幾個什麼屬性，以及它們的對象類型是什麼，某個屬性可以用在什麼類上，等等。不同的研究者也開發了不同的OWL推理器，比如HermiT，可以用來推斷類或個體（individual）的等價性，個體的類歸屬等。這樣，OWL可以用來刻劃多個不同定義之間的「同義」性，通過推理器提供互操作性（interoperability）。但是，一個很常見的誤解（我就有過）是以爲OWL可以檢查某個知識庫是否「有效」，即是否符合「類的定義」。

實際上，OWL基本上不能用來做這些檢查。主要原因是OWL所基於的「開放世界假設」。

「開放世界假設」認爲「當前知識庫中的數據未必是完整的」。換句話說，如果當前知識庫中類A的實例a只擁有一個pb屬性，但A的定義中有兩個pb屬性，那麼OWL會認爲這是合法的數據，因爲「少的那個pb屬性可能是存在的，只不過不在當前知識庫中」。

如果想進行這種檢查，則需要使用SHACL。SHACL基於的是「封閉世界假設」，就是設計來檢查數據的。另外還有個ShEx，也是用來描述形狀的，也可以用來檢查。我暫時沒有詳細瞭解過，不知道它和SHACL的關係是什麼。

我還接觸並使用過一個有意思的Python庫，叫Owlready。它的主要功能是讓Python的類和實例與OWL的類和個體之間相互鏈接，用法之一是從OWL的類定義生成（導入成）Python的類，很有意思。原則上說，OWL的功能比典型的OOP的類與實例的概念強大，所以裏邊必然有一些有意思的事情（包含但不限於推理）。整體而言，我很喜歡它的理念，而且希望有人可以開發「編譯器」，來將OWL的類定義轉成其他（尤其是編譯型）語言的類定義，這樣跨語言的時候就方便很多。

推理規則描述語言

在SW的世界中有許多的推理規則的描述語言，各不相同，這讓我一度十分迷惑。雖然現在也沒有完全弄懂，但至少有了一些認識。

好多語言，爲什麼？

在討論這些語言的關係之前，首先我們要瞭解：爲什麼會有這些不同的語言？是因爲研究人員或開發人員閒得慌麼？

答案其實很簡單：因爲它們的能力各不相同，所以不得不有許多不同的語言。

下面一節會簡單討論幾個我瞭解的例子，尤其是OWL、N3和Datalog。

於是很自然的一個衍生問題是：爲什麼不創建一個涵蓋全部的語言？

答案很明確，但不一定直觀：因爲它們的一些特質互不兼容，如果全部支持，那麼推理複雜度將不可接受。

這背後的原因則根植於不同的邏輯系統、不同的任務以及不同的複雜度。它們要麼有嚴格的證明，要麼有長期無法打破的猜測，並不是靠蠻力能解決的問題。

一個基本認識：越簡單的越快，越複雜的越慢。

一些常見語言

說是「常見」語言，其實是我所知道的語言——雖然我所知道的肯定不全面，但既然我並不是資深人士，那麼我能接觸到的應當算是常見吧：

• OWL（Web Ontology Language）：以Description Logic爲基的語言，以描述性的方式書寫（/使用定義內的）規則

  • 開放世界假設

  • 有OWL (1)和OWL 2兩個版本，都有自己的不同profile，但含義不同（參考閱讀）

    • OWL 2應當比OWL (1)更好用，各個意義上

  • OWL 2的三個Profile分別基於不同的DL，支持不同的功能，爲不同的任務優化

• SWRL（Semantic Web Rule Language）：基於霍恩子句（Horn Clause）的語言，似乎比OWL (1)功能強大一點

  • 開放世界假設

  • 雖然叫「語義網絡規則語言」，但它並不是「全語義網的標準」

• N3：帶查詢的規則描述語言，大約是簡化版的謂詞邏輯/一階邏輯

  • 開放世界假設，但部分語法支持臨時的封閉世界假設

• Datalog（RDFox變體）：類似Prolog的基於霍恩子句的語言，另支持內置語法和關鍵詞

  • 封閉世界假設，使用negation-as-failure

• SPARQL：本身是查詢語言，但查詢條件中可以實質上進行一定推理

  • 大約算是封閉世界假設

我的認識中，OWL是這些不同語言中推理功能最少的，SWRL比它稍微強一點。不過我沒有完全弄明白各個Profile的實際能力區別，也沒仔細研究過SWRL，所以無法具體比較。

N3完全覆蓋了OWL和SWRL的能力，並且提供了更多的功能。

而Datalog則是另一種思路，尤其是它拋棄了開放世界假設，又基於Prolog的語法結構，所以理應有更強大的推理能力（指「可以表達的推理規則」及按這些規則推出的結論），尤其是可以表達「否」。

SPARQL不完全歸屬這個類別（見下一節），但使用它也可以從實質上進行推理，即從知識庫中得出知識庫中不存在的信息。它也支持表達「或」，以及表達「非」（似乎也是negation as failure）。其表達能力超過SWRL和OWL，也許可以和Datalog比一比。我不確定SPARQL和Datalog兩者誰更強大，但僅以描述的易讀性來看，Datalog更好讀。

查詢數據

前面主要討論的是數據本身的事情：表示是什麼，理念是什麼，結構是什麼，如何檢查等等。但我們有數據的目的是爲了使用數據，於是SW研究參考關係型數據庫的SQL開發了SPARQL來查詢RDF知識庫。

SPARQL類似SQL，通過描述性的查詢來從知識庫中提取數據。SPARQL的「描述」是基於「模式匹配（pattern matching）」的，即從知識庫中尋找和描述中相符合的三元組。

除了查詢以外，類似SQL支持增刪改查，SPARQL當然也支持修改知識庫，且（由於圖和RDF的特性）選項更豐富。在此之外，SPARQL還支持CONSTRUCT，用來直接從查詢結果構建一個新的圖（並返回，而非插入到知識庫中）。另外，還記得我們前面提到的「開放世界假設」麼？SPARQL也支持同時從多個地方查詢，甚至是各執行一部分查詢（即Federated Query，互聯查詢）。

SPARQL的功能由簡單到複雜涵蓋很多，我也不確定什麼教程最合適，畢竟我並沒有完全跟着教程學。我當時學習是找了個基礎教程（現在不記得是誰了），然後就不斷的搜相關功能如何實現，以及參考官方文檔。所以其實迄今爲止我也不算完全掌握了它，而只是會用以及熟悉它。

速度，還有我是否需要擔心速度？

本節涉及我不夠瞭解純熟的理念，請謹慎閱讀。

我印象中看到過Nepomuk被拋棄的一部分原因是項目經費不再撥款了，另一部分原因則是它的速度實在是有問題。

而且這也符合一般的感覺，那就是SW的工具都存在速度問題。雖然裏面有業界使用人數少所以優化有限的因素，但始終有一個問題縈繞在心頭，那就是：是不是SW有理論限制，速度無法上去？

答案其實是否定的。現在有許多人在改進其速度，尤其以RDFox爲代表的知識庫+推理引擎的速度更是數量級地優於Jena。

當然，這並不是說理論複雜度上限就不存在了。其實仔細想想，這個擔心本身很有意思。SW的世界（比如OWL的DL）經常強調邏輯系統的選擇及帶來的速度，所以看SW的人也會擔心這個問題。但事實上，這可以說是某種倖存者偏差（？應該有個更好的詞？但我想不起來）：如果你用同樣的思維去考慮其他系統（比如編程語言），那麼你更應該擔心它們的複雜度是否爆錶。

最經典的就是程序中的「停機問題」：給定一段程序，（在不執行的情況下通過分析代碼）判定它何時會結束。我們已經知道，所有的圖靈機（也就意味着所有的編程語言）都無法解決停機問題。換句話說，如果從理論上思考，在解決某一個推理問題（如「停機問題」所代表的「何時程序會結束」）時，它們的複雜度是無窮大。

這個複雜度和DL們經常在乎的複雜度根本就不可比，但似乎鮮有人因爲在乎它而覺得所有程序都存在速度極差的問題。同理，也不應該因爲SW相關研究因爲明確說了一些推理工具的理論複雜度上限很高，而認爲它就比不說明複雜度的東西更慢。

啓航

本文從不同角度梳理了一些語義網和關聯數據的相關知識，希望對新來者有所幫助。

當然如果你對SW和LD感興趣，那麼一個很自然的問題是：我該從哪裏開始？

最簡單的回答是：你需要用什麼，就從哪開始。

而如果你暫時沒有使用需求，而主要是對技術感興趣，你可以去試試Wikidata的SPARQL接口，例如參考Wikibooks上的SPARQL一篇。這樣你可以學習SPARQL，可以直接使用一個編輯器和端點，可以有實際的數據集。你大概也會對RDF可視化（即其圖結構的可視化）感興趣，例如試試這個工具。而RDF本身，不妨試試RDF各種表示的轉換工具，比如:isSemantic的RDF轉換器，或如果你更傾向於JSON也可以試試JSON-LD轉換器。或者如果你暫時沒特別確定的需求，那麼也可以先用着Solid（比如參考《Solid——簡介與體驗》），在使用中很容易就接觸到相關東西，逐漸學習。

但說實話，你應該已經看出來了，這個問題其實也不好回答。這是因爲SW和LD相關技術比較散，多是研究性而非商業性的，所以「推廣」方面存在一些門檻/障礙。這的確是個問題，希望未來有所改進。出於相似的原因，Tim爲Solid成立了Inrupt，希望可以讓推廣更容易一些——的確有用，但並沒有如魔法般的效果，一些事情還是需要水磨工夫。