本文轉載自文因互聯 2016 年 6 月份組織的第一期北京知識圖譜學習小組 Wiki。

---

• 知識表示（Knowledge Representation，KR，也譯為知識表現）是如何將結構化數據組織，以便于機器處理和人的理解的方法。從結構推導出新的結構，這就是推理。傳統上KR屬于邏輯的分支，但在實踐中我們會用很簡單、可讀、可維護的數據結構。

  
  

  經典的教科書中的 KR，主要關注的是如何方便機器處理。但是在現實的工程中，如何方便人的理解也是極為關鍵的。在工程實踐中，人才是知識不能被處理好、不能快速交換、不能規?；暮诵?。

  
  

  知識表現的瓶頸不在于機器處理能力的不足，而在于人的認知能力的不足。因此，我們在學習知識表現方法的時候，要始終牢記知識的可讀性、可維護性要遠遠比它的表達力、計算速度重要。知識是為人閱讀而設計的，只是偶爾被機器執行。

  
  

  數據優先，邏輯靠邊

  
  

  作為工程師，我們時時刻刻把可行性放在心中。傳統的知識圖譜的 KR，從邏輯和推理講起，有一階邏輯(first-order logic)和描述邏輯(description logic)，后來又有邏輯程序(logic program)和生成規則（Production Rule）。但是我反對從邏輯開始理解知識圖譜。語義網和知識圖譜是關于數據的，關于結構促進數據的流動，用結構化數據增進其他系統的自動化能力的。邏輯只是很小的一個插件。

  
  

  語義網，或者現在的知識圖譜，在應用中，核心問題不是“應該怎么樣”，而是“不得不怎么樣”。語義推理對數據質量的要求很高，在工程上成本就承受不了?，F實的應用，只能逐步提高數據的質量，從數據清洗開始就要承擔巨額的投入，然后做實體抽取，實體鏈接，對齊，消歧，關系抽取，對齊，詞庫提取，本體建模，這每一步都是海一樣的銀子砸進去。

  
  

  然后在推理中，推理規則都需要人生成。現在機器生成規則的能力很弱，幾乎不可用。僅僅是屬性和直接關系的查找可以機器做，稍微復雜的長程關系都需要人來寫。這在工程部署中有巨大的困難，因為這樣的工程師很少，寫出來的東西可維護性，性能，普適性都成問題。所以現實中的系統，很少有做推理的。即使是做推理，也很少是一階邏輯推理，一般也就是if then else，命題邏輯。很多時候還要容忍數據中的噪聲，和正則表達式等結合在一起用。所以學術派的推理機，一般都用不了。

  
  

  所以我們會了解 RDF 和 OWL，但是并不推薦使用這些 W3C 標準作為工程的選擇。我們認為 JSON 和關系數據庫是工程中成本較小的解決方案。在某些特定場合，圖的表示也是合理的。這會在之后的“知識存儲”的章節繼續討論。

  
  

  其他一些我的個人觀點

  • 我對關聯數據的看法 http://baojie.org/blog/2014/12/21/on-linked-data/

  • 語義網的工具演化 http://baojie.org/blog/2014/02/12/semantic-tool-evolution/

  • 語義網不需要描述邏輯 http://baojie.org/blog/2013/02/05/semantic-web-and-description-logic/

  
  

  知識表現的數據結構

  
  

  在知識提取之后，如何表示知識？其實知識并不神秘，只是一些數據之間的關系。在計算機中的表示，就是數據結構。傳統上，我們把那些能夠導出新的關系的關系（比如“爸爸的爸爸是爺爺”，這里面“爸爸”和“爺爺”都是關系）看成知識。但是在目前的知識圖譜實踐中，并不會有嚴格的區分，我們把各種結構都可以看成廣義的知識。

  
  

  不過不是所有的數據結構我們會用知識工程的方法來處理，比如集合、哈希表、隊列、堆棧、鏈表等等，一般丟給軟件工程去處理。另一類特殊的結構，二維表，我們丟給數據工程去解決。當然數據工程和知識工程之間沒有嚴格的界限，二維表和復雜知識結構表示之間也有交叉，暫留后述。

  知識表現的數據結構，一般來說是那些“復雜”的結構，最常見的就是圖（graph）和樹（tree）。

  
  

  知識表現的圖，是“有類型的邊”（typed edge），分析方法和一般的圖論和社交關系圖譜中分析的無類型的邊很不相同。傳統的Web結構只有“鏈接”這一種關系。在2000年代中，語義網試圖給鏈接加上類型說明，如某人主頁聲明工作于某公司，這就有“工作”關系。這里，類型就是邊的“元數據”（metadata）。后來，發現在應用中還需要給邊，當然還有節點，添加更多的元數據，這就形成了有類型的邊構成的圖譜結構，上面每個邊和每個節點都擁有元數據。

  
  

  圖的知識表現，演化出兩個流派。一個是 RDF 圖，一個是屬性圖（Property Graph）。RDF 圖是 W3C 的官方標準，得到了政府資金和一些大公司的大力支持，但是最終市場表現平平。屬性圖是草根自發的，最終得到了市場的認可，現在主要是中小企業、創業公司在用。RDF 圖是科學頂層設計出來的，屬性圖是工程實戰中總結出來的。它們發展軌跡的不同也再次證明，好的架構一般是總結出來的，不是憑空設計出來的。

  
  

  RDF 圖的基礎是三元組，用 URI 命名節點和連接節點，有嚴格的語義，約束比較多。屬性圖沒有嚴格的語義，可以比較自由地聲明節點和邊的屬性。RDF 的優勢在于推理，但是三元組的組織使稍復雜的關系的表達很困難，具體后述。屬性圖不定義推理，但是可以通過查詢語言（如Gremlin）來做模式（pattern）的查找和圖上的遍歷（traverse），可以實現特設的(ad-hoc)的推理。也待到圖數據庫部分細說。

  
  

  用圖表示知識，豐富的知識結構主要表現為圖上的邊，各種推理算法就是在圖上推導出邊的算法。在傳統圖論里，有可達性（reachability）推理，有大量的優化研究。一些基本的傳遞性的推理，如分類樹（taxonomy），是可以轉化為圖可達性推理的。但是大量的其他類型的推理，沒有成熟的工程系統和算法可用?，F有的圖數據庫，都局限很大，工程上成本很高。

  圖表示的另一個問題是對混合表示不是很友好。因為知識提取的成本是很高的，所以現實的工程中我們很難一步到位生成純結構化的數據表示，我們的數據往往是結構化和非結構化（主要是文本）混合的。其中結構化的比例，結構化的質量，可能是在應用的過程中逐步提升的。開始的時候可能文本的比例比較大。雖然 RDF 圖和屬性圖上的節點都可以有文本屬性，但是圖的索引還是與文本索引大不同，在實際使用中需要依賴集成 Lucene之類的全文檢索引擎。由于文本不是“一等公民”，很多建模難以實現，比如在 RDF 里文本不能作為三元組的主語。

  
  

  由于圖表示很復雜，最廣為接受的知識組織其實是樹（taxonomy，hierarchy）。這是人的認知決定的。計算機發展這么多年，界面元素的組織，被廣為接受的也只有樹、列表、表格。那些看起來很復雜的知識庫，其基礎也都是樹。

  
  

  所以樹形的 JSON 最終脫穎而出，不是偶然的。它符合人的認知，滿足了結構化和非結構化混合表示的需要，兼容現有的工程實現。JSON 表示被稱為“文檔”（document），2009 年以來興起了很多文檔數據庫（document database）。最近又有了 PostgeSQL 和 OrientDB 這樣混合關系與文檔的數據庫，可以實現可讀性好、工程兼容性好、表達力也還夠用的知識表示。

  
  

  JSON和YAML，易讀知識的藝術

  
  

  JSON 是很簡單的數據格式。JSON 成為 Web API 的事實標準，部分實現了當初語義網的一些目標。但是幾年前，我和一位語義網領域的知名教授聊到語義數據的表示問題，我提到了 JSON，他表示沒聽說過。這讓我很震驚，學術界何以對工業界數據表示的事實標準如此不關心呢？

  
  

  我們做研究，一定要從實踐中來，到實踐中去。實際的數據是什么樣，用什么樣的成本能獲得這些數據，這都不是隨便能假設的。JSON 在和 XML 的競爭中勝利，基于 JSON 的 REST 服務框架在和基于 XML 的 SOAP 的競爭中勝利，不是偶然的。因為 JSON 和 REST 更符合人的認知的需要，生成他們的成本低，理解他們的成本低，工程師容易理解，最終就用起來了。所以現在 XML 和 SOAP 雖然是“國際標準”，但在 Web 上用的人很少，JSON 和 REST 這些“野路子”一統天下。這和屬性圖數據庫超越 RDF 數據庫是一個道理。

  
  

  在 Python 中使用 JSON 超級簡單，JSON 和 Python 的字典很像，可以轉換?？垂俜轿臋n即可

  • json庫 https://docs.python.org/2/library/json.html

  掌握下面這些庫會讓你處理json和字典的時候更開心

  • attrdict https://github.com/bcj/AttrDict a['foo']['bar']可以寫做a.foo.bar 或a['foo'].bar。可讀/寫屬性，可遞歸訪問屬性，繼承dict的各種方法

  • marisa-trie https://github.com/kmike/marisa-trie 超級節約內存的字典

  • DAWG http://dawg.readthedocs.org/en/latest/ 另一個超級節約內存的字典

  • orderedmultidict https://github.com/gruns/orderedmultidict 多值有序字典

  • jsonpickle ?http://jsonpickle.github.io/ JSON持久化。支持更復雜數據的存儲

  • jq ?http://stedolan.github.io/jq/tutorial/ 命令行上的json處理和查詢

  • pjson ?https://github.com/igorgue/pjson 在命令行上彩色打印json

  • jsonlint https://github.com/zaach/jsonlint 格式化json

  • jsawk https://github.com/micha/jsawk json的awk，一個快速的命令上的查詢工具

  • json-diff https://www.npmjs.org/package/json-diff 比較兩個json

  
  

  以上都是良心推薦，經多年工程實戰考驗的趁手工具。掌握了這些即使學不好知識圖譜，也可以成為不錯的數據科學家 :D

  
  

  還有一些高級的話題，json pointer， json schema， xml2json， csv2json，暫時不提。我們只需要知道，json的工具鏈極為豐富。很多時候我們處理數據，就是卡在這些“小”工具上。你要是用了RDF，就會在無數小地方上因為缺少這些小工具而痛苦。

  
  

  最后要隆重推薦一下YAML：JSON的超集，有更簡潔的語法 http://yaml.org/

  警告 Yaml可能有嚴重的世界觀副作用，過敏者請謹慎使用。

  
  

  YAML 在我看來比 JSON 的可讀性更好，更加 Pythonic（因為其語法接近Python）。當然有人可能會不喜歡縮進，不過 Python 社區的智力一般比較高，不會有這種偏見。YAML 里可以有節點之間的鏈接，因此可以表示圖。此外yaml里可以寫!注!釋！我認為 YAML 是天然的最好的知識圖譜表示語法。

  
  

  PyYAML 是 Python 里的 Yaml 處理庫 http://pyyaml.org/wiki/PyYAML

  不過 Yaml 解析的速度比 json 慢得多，大概只有 1/10。但是我們要牢記，知識表示最重要的是對人的友好，不是對機器的友好。速度不是大的問題，大部分的知識庫都不是特別大。

  
  

  最后多說一句無關的話，很多語言都有可讀性更好的類 Python 語法。下面是我收集的一個列表

  
  

  有一本經典的編程書《The Art of Readable Code》 https://book.douban.com/subject/5442971/ 。我覺得同樣的在知識表示里，我們應該追求“易讀知識的藝術”。工程上，這是特別重要的一件事。

  
  

  RDF 和 OWL

  
  

  雖然在大部分的應用場景下我都不會推薦大家使用 RDF 和 OWL，但了解一下它們還是很有必要的，當是打免疫針。當然這兩個語言非常的復雜，官方文檔打印出來有 1000 頁厚，展開講的話一個學期也講不完。好在我們是工程師，只關心如何應用，不需要全面了解。

  
  

  但基礎的RDF是非常非常簡單的，一頁紙就能說清楚。RDF 的基本單元是三元組（triple）。每個三元組是（主語 謂語 賓語）這樣的元組 tuple。主謂賓的取值稱為“資源”（Resource，也就是 RDF 里的 R）。資源可以是一個網址（URI），一個字符串或數字（嚴格來講都是帶類型的字符串，稱為literal），或者一個“空節點”（blank node）。主謂賓有一些限制，這里不細說，看后面提到的文檔。

  
  

  有兩種特殊類型的資源。rdfs:Class 代表類。rdf:Property 代表二元關系。有一種特殊的關系叫 rdf:type ，聲明一個資源屬于某一個類。

  
  

  用RDF建模，就要把所有的數據結構分割為三元組。這對我們智人是很麻煩的事情，因為我們的認知里還會有定語、狀語、補語，所以 RDF 提供了一些很麻煩的變通方法，例如 reification?？展濣c也是一種方法。這些在實踐中都會帶來無窮無盡的煩惱。

  
  

  一個三元組就是一個關系。在 RDF 里我們可以聲明一些規則，從一些關系推導出另一些關系。這些規則我們稱為“schema”，所以有了 RDFS（RDF Schema）。這些規則用一些詞匯（可以類比編程語言里的保留字，不過RDF里任何詞匯都可以被重定義和擴展）表示，如 subClassOf subPropertyOf domain range。

  
  

  RDF 里的推理規則有十幾條，其中最常用的大概就是父類子類關系（subClassOf）。有了它就可以表示分類樹，這種最常見的知識組織。后來在一些領域大家需要其他的一些推理規則，就又添加了幾十條規則，例如要表達女兒都是女生、哥哥的哥哥還是哥哥、爸爸的爸爸是爺爺、每人只有一個親爸爸，等等。這些規則被稱為 OWL，其中 O 代表 Ontology（本體）。我們不必關心本體的哲學定義，只要知道它是一些數據和推理規則的集合就好了。

  
  

  RDF和OWL都有嚴格的語義。一種叫模型論語義，是一種非常可怕的東西！它是一個高階的語義，充斥著難懂的話，什么“映射”、“外延”、“解釋”、“蘊涵” 之類。模型論語義是這樣的使人快活，可是沒有它，別人也便這么過。因為還有基于規則的語義；這是一種不完備的語義，因為有些推理可能不能100%得到模型論要求的結果。不過對于應用，這種不完備性基本無所謂。

  • RDF和OWL語義 http://blog.memect.cn/?p=871 我的兩個ppt，講解了RDF和OWL的模型論語義

  RDF和OWL的語法和基本使用，可以看官方的文檔，還不算太難懂（英文）

  • RDF 1.1 Primer https://www.w3.org/TR/rdf11-primer/

  • OWL 2 Primer http://www.w3.org/TR/owl2-primer/

  
  

  各種語法里，優先推薦用 Turtle 語法，因為它簡潔....得不像RDF http://www.w3.org/TR/turtle/

  
  

  Python 里的 rdflib 包可以很方便處理 RDF。推薦按 rdflib 的文檔過一遍例子，加深對 RDF 的理解 http://rdflib.readthedocs.io/en/stable/

  
  

  這個 2011 年的綜述，提到了各種 RDF 相關的 Python 包：RdfLib RdfAlchemy Fuxi ORDF Django-RDF Djubby Redland SuRF PySparql Sparta Oort Virtuoso pySesame pynappl HTTP4Store py4s

  • Survey of Pythonic tools for RDF and Linked Data programming http://www.michelepasin.org/blog/2011/02/24/survey-of-pythonic-tools-for-rdf-and-linked-data-programming/

  
  

  本文沒包括的還有：rdfQuery, PySWIP, pyDatalog, PyLog, FLiP, seth, sparrow, pymantic , pyRDFa, djubby , pySPARQL。感興趣的可以查查。我個人很喜歡pyDatalog，雖然不是RDF的推理機，但大部分RDF的可以完成的建模用pyDatalog也都能做，我覺得更自然些。

  
  

  參考手冊

  • 語義網速查表 http://ebiquity.umbc.edu/resource/html/id/94/ （丁力寫的）

  • OWL語法速查表 https://www.w3.org/TR/2012/REC-owl2-quick-reference-20121211/ （我寫的）

  
  

  JSON-LD

  
  

  JSON-LD 是 RDF 的 JSON 語法，其中 LD 代表 Linked Data。它要解決的是 RDF 沒有好的 Web 兼容語法問題。經典的 RDF 語法是 XML 的，不僅羅嗦和丑陋，也集成了XML“重”的一些特征，適合“企業級”（如今這個詞差不多就是恐龍、笨拙、難用的代名詞）應用。JSON-LD 就是想提供一個和互聯網事實標準更兼容的、“輕”的語法。

  
  

  JSON-LD 基本思想是（我個人的理解）

  • 盡可能用對人友好的字符串來寫作，而不是象在傳統 RDF 里用難以理解的 URI。為了解釋字符串，就引入了@context，把字符串定義在一定的上下文下——這些上下文本身一般是 URI。這是比 XML domain更友好的設計，增強了可讀性。

  • 引入模塊化組織，加強可讀性和可維護性。傳統的 RDF 的組織粒度太低，在三元組層面。JSON-LD 把同一個主語的三元組組織在一個 { } 塊下，方便寫作和理解。塊的主語可以用 @id 屬性聲明。更高層面上它還提供了 @graph 聲明，你可以把它理解成一個子模塊，模塊里的內容可以共享一些元數據（比如上下文和注釋）。

  
  

  JSON 的官方文檔：

  • 主頁 http://json-ld.org/

  • W3C標準 https://www.w3.org/TR/2014/REC-json-ld-20140116/

  
  

  JSON-LD 本身現在還沒有普及起來。wikidata 在用，谷歌的 knowlege graph 也在用，但大多數人還不知道。我個人認為這是個好東西，雖然難以預料未來能不能火起來。

  
  

  JSON-LD 體現了兩個對人友好的特性：可讀性和模塊化。第一代的 Web 知識語言如 RDF 和 OWL，可以類比為知識的“匯編語言”，對機器很友好，對人不友好。Turtle 和 JSON-LD 這類第二代語言，開始“高級化”，注意了方便人來寫作和閱讀，注意了引入適應人的認知需要的模塊。

  
  

  模塊化機制引入 RDF，前后花了十多年的時間。我自己從 2004-2010 也參與了一些工作?？梢哉f，中間大家都犯了很多錯誤，走到今天的知識圖譜很不容易。今后大家肯定還會繼續犯錯誤。但是如果大家能多想想人的需要，而不僅是機器的需要，可能會少犯些錯誤吧。

  
  

  知識圖譜的高級語言

  
  

  最后再展開說說我對 Web 上知識表示的展望，基本基于我一篇老博文《語義網的高級語言》（2012-11-27）

  • http://baojie.org/blog/2012/11/27/advanced-language-of-semantic-web/

  
  

  在談論語義網的時候，要和RDF路線區分開來。

  
  

  和一些人談到語義網，他們說：“語義網死了”。如果從 RDF 的角度來說，是的——雖然 W3C 路線的支持者還不承認。

  
  

  但是這種觀點，就如同計算機在只有機器語言，沒有高級語言的時候就斷言：“計算機死了”。

  
  

  我大膽提出兩個假設

  • RDF 是一門低級語言，只適合機器使用——如同機器語言或者匯編語言

  • 語義網需要一門高級語言，面向工程師（人），用來做大規模知識庫的寫作、重用

  
  

  為什么說 RDF 是低級機器語言？

  • 用 URL 來尋址并不錯。但是把精確尋址的任務交給人，要求人來設計 URL，就如同在 C 編程中要求人對每個變量賦予內存地址。 RDF 是一個“平坦”(flat)的語言，缺少內部的組織單元。有很多建議，引入諸如package, named graph 這樣的組織單元，但目前還沒有達成共識或廣泛采用。

  • RDF 的語法，即使是 Turtle，也沒有可讀性，理解和重用起來非常困難。

  • RDF缺少“宏”或者構造高層次組織的能力。其實 SPARQL 彌補了一點，就是 graph pattern；一些語言如 SPIN，把 graph pattern 作為可重用的單元，甚至可以生成新的數據。如果把這個能力作為 RDF 原生的能力就好了。

  
  

  2010年RDF Working Group 開預備會議，我也與會了（ https://www.w3.org/2009/12/rdf-ws/papers/ws33 ）。現在回來看，我那時的想法是錯誤的：為 RDF 引入更精確的語義，基于上下文(context)的組織和尋址，并不合適——雖然Pat Hayes后來很喜歡這個想法并在工作組內推一個類似的想法。

  
  

  RDF 的問題不是邏輯太少了，而是邏輯太多了。

  
  

  知識工程的問題往往是太多考慮機器的需要，而不太考慮人的需要。而知識工程的瓶頸，又恰恰在人而不在機器。

  
  

  三元組的問題在于模型的進化能力有限。想為一句話再加個時間戳？想表示 Provenance？在 RDF 制定的早期，就提出了 reification 作為彌補。但是后來所有人都討厭這個丑陋的補丁。后來陸續有四元組、五元組、六元組、Context、Named Graph 等等各種其他的補丁。越搞越復雜，越來越沒人懂。所以我認為，為知識表現專門開發一門語言沒必要。特別是在 RDF 里 Literals 是二等公民（比如subject不允許是字符串！！），和它們真實的地位不相稱。直接利用現有高級語言，如Python或Javascript，某個子集就好，不需要搞三元組。

  
  

  RDF 1.1 現在的幾個努力方向：JSON 語法，Named Graph, Turtle Syntax，這些都是好的。但是還不夠。我甚至懷疑，在 RDF 框架內能不能達到易用性的目的。

  
  

  因為從一開始，RDF 就被設計成 machine understandable 語言。這本是好的，至少在 1999 年。但是一個缺少高級語言的情況，就好像編程語言的早期。結果就是知識工程的人月神話。

  
  

  現在的情況也很象Web發明的時候：在 Internet 上，TCP/IP 是面向機器的低級語言，而 HTML 和 URL 是面向人的高級語言。我覺得，現在有一個強烈的需要來設計一個 Semantic Web 的高級語言。

  
  

  這樣的高級語言要有什么特征呢？我覺得大體有這樣幾點

  • 支持多粒度的知識/數據組織和重用

  • 用字符串而不是URL來尋址。不追求addressing uniqueness, 而是probable and eventual addressing uniqueness

  • 支持知識的分布式傳輸（按一定粒度）

  • 使用目前主流程序員熟悉的語法形式。

  • 盡可能少重新發明輪子——比如rdf:plainLiteral（我是作者之一）這樣的字符串類型就沒什么必要

  • 支持結構化和非結構化數據的混合表達（RDF有Literal，不過，那個太局限了）

  • 這個語言的文檔不要提什么“語義”（有幾個程序員關心SQL的語義？）,不要規定什么schema

  • 把推理轉化為圖的操作或者編程語言內置的運算。在這之外的推理都先不考慮。

  • 從一開始就設計成在cluster上能運行的語言

  • 拜托，用程序員看的懂的語言和例子寫文檔。

  
  

  其實這樣的語言雛形的一些部分，在不同的技術平臺上都已經自發出現了。語義維基，圖數據庫，新一代檢索引擎，都包含了上述部分概念。有心人要做的，就是一個有機的組合。我想，在我寫這一段的時候，大概已經有人開始做了。

  
  

  我甚至覺得，都沒有必要引入一個新的高級語言語法，就在現有的某種貼近 RDF 的編程語言里，做少量的增加就能實現目的。最理想的就是 Python。為什么這么說？JSON 本身就是 Python 的數據結構。而幾乎所有的數據 API 都吃 JSON。Python 的類與屬性定義與關系就是 RDF 的翻版。

  其實更合適的是 Lisp。但是 Lisp 對抽象思維要求太高，社區又太小。做面向 Web 的開發，為了工程經濟性（人力上的），還是 Python 比較合適。

更多內容可以訪問鏈接? https://github.com/memect/kg-beijing/wiki

---

OpenKG.CN

中文開放知識圖譜（簡稱OpenKG.CN）旨在促進中文知識圖譜數據的開放與互聯，促進知識圖譜和語義技術的普及和廣泛應用。

轉載須知：轉載需注明來源“OpenKG.CN”、作者及原文鏈接。如需修改標題，請注明原標題。

點擊閱讀原文，進入 OpenKG 博客。

總結

以上是生活随笔為你收集整理的鲍捷 | 知识表示——面向实战的介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。