本文轉(zhuǎn)載自文因互聯(lián) 2016 年 6 月份組織的第一期北京知識(shí)圖譜學(xué)習(xí)小組 Wiki。

---

• 知識(shí)表示（Knowledge Representation，KR，也譯為知識(shí)表現(xiàn)）是如何將結(jié)構(gòu)化數(shù)據(jù)組織，以便于機(jī)器處理和人的理解的方法。從結(jié)構(gòu)推導(dǎo)出新的結(jié)構(gòu)，這就是推理。傳統(tǒng)上KR屬于邏輯的分支，但在實(shí)踐中我們會(huì)用很簡(jiǎn)單、可讀、可維護(hù)的數(shù)據(jù)結(jié)構(gòu)。

  
  

  經(jīng)典的教科書(shū)中的 KR，主要關(guān)注的是如何方便機(jī)器處理。但是在現(xiàn)實(shí)的工程中，如何方便人的理解也是極為關(guān)鍵的。在工程實(shí)踐中，人才是知識(shí)不能被處理好、不能快速交換、不能規(guī)模化的核心。

  
  

  知識(shí)表現(xiàn)的瓶頸不在于機(jī)器處理能力的不足，而在于人的認(rèn)知能力的不足。因此，我們?cè)趯W(xué)習(xí)知識(shí)表現(xiàn)方法的時(shí)候，要始終牢記知識(shí)的可讀性、可維護(hù)性要遠(yuǎn)遠(yuǎn)比它的表達(dá)力、計(jì)算速度重要。知識(shí)是為人閱讀而設(shè)計(jì)的，只是偶爾被機(jī)器執(zhí)行。

  
  

  數(shù)據(jù)優(yōu)先，邏輯靠邊

  
  

  作為工程師，我們時(shí)時(shí)刻刻把可行性放在心中。傳統(tǒng)的知識(shí)圖譜的 KR，從邏輯和推理講起，有一階邏輯(first-order logic)和描述邏輯(description logic)，后來(lái)又有邏輯程序(logic program)和生成規(guī)則（Production Rule）。但是我反對(duì)從邏輯開(kāi)始理解知識(shí)圖譜。語(yǔ)義網(wǎng)和知識(shí)圖譜是關(guān)于數(shù)據(jù)的，關(guān)于結(jié)構(gòu)促進(jìn)數(shù)據(jù)的流動(dòng)，用結(jié)構(gòu)化數(shù)據(jù)增進(jìn)其他系統(tǒng)的自動(dòng)化能力的。邏輯只是很小的一個(gè)插件。

  
  

  語(yǔ)義網(wǎng)，或者現(xiàn)在的知識(shí)圖譜，在應(yīng)用中，核心問(wèn)題不是“應(yīng)該怎么樣”，而是“不得不怎么樣”。語(yǔ)義推理對(duì)數(shù)據(jù)質(zhì)量的要求很高，在工程上成本就承受不了。現(xiàn)實(shí)的應(yīng)用，只能逐步提高數(shù)據(jù)的質(zhì)量，從數(shù)據(jù)清洗開(kāi)始就要承擔(dān)巨額的投入，然后做實(shí)體抽取，實(shí)體鏈接，對(duì)齊，消歧，關(guān)系抽取，對(duì)齊，詞庫(kù)提取，本體建模，這每一步都是海一樣的銀子砸進(jìn)去。

  
  

  然后在推理中，推理規(guī)則都需要人生成。現(xiàn)在機(jī)器生成規(guī)則的能力很弱，幾乎不可用。僅僅是屬性和直接關(guān)系的查找可以機(jī)器做，稍微復(fù)雜的長(zhǎng)程關(guān)系都需要人來(lái)寫(xiě)。這在工程部署中有巨大的困難，因?yàn)檫@樣的工程師很少，寫(xiě)出來(lái)的東西可維護(hù)性，性能，普適性都成問(wèn)題。所以現(xiàn)實(shí)中的系統(tǒng)，很少有做推理的。即使是做推理，也很少是一階邏輯推理，一般也就是if then else，命題邏輯。很多時(shí)候還要容忍數(shù)據(jù)中的噪聲，和正則表達(dá)式等結(jié)合在一起用。所以學(xué)術(shù)派的推理機(jī)，一般都用不了。

  
  

  所以我們會(huì)了解 RDF 和 OWL，但是并不推薦使用這些 W3C 標(biāo)準(zhǔn)作為工程的選擇。我們認(rèn)為 JSON 和關(guān)系數(shù)據(jù)庫(kù)是工程中成本較小的解決方案。在某些特定場(chǎng)合，圖的表示也是合理的。這會(huì)在之后的“知識(shí)存儲(chǔ)”的章節(jié)繼續(xù)討論。

  
  

  其他一些我的個(gè)人觀點(diǎn)

  • 我對(duì)關(guān)聯(lián)數(shù)據(jù)的看法 http://baojie.org/blog/2014/12/21/on-linked-data/

  • 語(yǔ)義網(wǎng)的工具演化 http://baojie.org/blog/2014/02/12/semantic-tool-evolution/

  • 語(yǔ)義網(wǎng)不需要描述邏輯 http://baojie.org/blog/2013/02/05/semantic-web-and-description-logic/

  
  

  知識(shí)表現(xiàn)的數(shù)據(jù)結(jié)構(gòu)

  
  

  在知識(shí)提取之后，如何表示知識(shí)？其實(shí)知識(shí)并不神秘，只是一些數(shù)據(jù)之間的關(guān)系。在計(jì)算機(jī)中的表示，就是數(shù)據(jù)結(jié)構(gòu)。傳統(tǒng)上，我們把那些能夠?qū)С鲂碌年P(guān)系的關(guān)系（比如“爸爸的爸爸是爺爺”，這里面“爸爸”和“爺爺”都是關(guān)系）看成知識(shí)。但是在目前的知識(shí)圖譜實(shí)踐中，并不會(huì)有嚴(yán)格的區(qū)分，我們把各種結(jié)構(gòu)都可以看成廣義的知識(shí)。

  
  

  不過(guò)不是所有的數(shù)據(jù)結(jié)構(gòu)我們會(huì)用知識(shí)工程的方法來(lái)處理，比如集合、哈希表、隊(duì)列、堆棧、鏈表等等，一般丟給軟件工程去處理。另一類(lèi)特殊的結(jié)構(gòu)，二維表，我們丟給數(shù)據(jù)工程去解決。當(dāng)然數(shù)據(jù)工程和知識(shí)工程之間沒(méi)有嚴(yán)格的界限，二維表和復(fù)雜知識(shí)結(jié)構(gòu)表示之間也有交叉，暫留后述。

  知識(shí)表現(xiàn)的數(shù)據(jù)結(jié)構(gòu)，一般來(lái)說(shuō)是那些“復(fù)雜”的結(jié)構(gòu)，最常見(jiàn)的就是圖（graph）和樹(shù)（tree）。

  
  

  知識(shí)表現(xiàn)的圖，是“有類(lèi)型的邊”（typed edge），分析方法和一般的圖論和社交關(guān)系圖譜中分析的無(wú)類(lèi)型的邊很不相同。傳統(tǒng)的Web結(jié)構(gòu)只有“鏈接”這一種關(guān)系。在2000年代中，語(yǔ)義網(wǎng)試圖給鏈接加上類(lèi)型說(shuō)明，如某人主頁(yè)聲明工作于某公司，這就有“工作”關(guān)系。這里，類(lèi)型就是邊的“元數(shù)據(jù)”（metadata）。后來(lái)，發(fā)現(xiàn)在應(yīng)用中還需要給邊，當(dāng)然還有節(jié)點(diǎn)，添加更多的元數(shù)據(jù)，這就形成了有類(lèi)型的邊構(gòu)成的圖譜結(jié)構(gòu)，上面每個(gè)邊和每個(gè)節(jié)點(diǎn)都擁有元數(shù)據(jù)。

  
  

  圖的知識(shí)表現(xiàn)，演化出兩個(gè)流派。一個(gè)是 RDF 圖，一個(gè)是屬性圖（Property Graph）。RDF 圖是 W3C 的官方標(biāo)準(zhǔn)，得到了政府資金和一些大公司的大力支持，但是最終市場(chǎng)表現(xiàn)平平。屬性圖是草根自發(fā)的，最終得到了市場(chǎng)的認(rèn)可，現(xiàn)在主要是中小企業(yè)、創(chuàng)業(yè)公司在用。RDF 圖是科學(xué)頂層設(shè)計(jì)出來(lái)的，屬性圖是工程實(shí)戰(zhàn)中總結(jié)出來(lái)的。它們發(fā)展軌跡的不同也再次證明，好的架構(gòu)一般是總結(jié)出來(lái)的，不是憑空設(shè)計(jì)出來(lái)的。

  
  

  RDF 圖的基礎(chǔ)是三元組，用 URI 命名節(jié)點(diǎn)和連接節(jié)點(diǎn)，有嚴(yán)格的語(yǔ)義，約束比較多。屬性圖沒(méi)有嚴(yán)格的語(yǔ)義，可以比較自由地聲明節(jié)點(diǎn)和邊的屬性。RDF 的優(yōu)勢(shì)在于推理，但是三元組的組織使稍復(fù)雜的關(guān)系的表達(dá)很困難，具體后述。屬性圖不定義推理，但是可以通過(guò)查詢(xún)語(yǔ)言（如Gremlin）來(lái)做模式（pattern）的查找和圖上的遍歷（traverse），可以實(shí)現(xiàn)特設(shè)的(ad-hoc)的推理。也待到圖數(shù)據(jù)庫(kù)部分細(xì)說(shuō)。

  
  

  用圖表示知識(shí)，豐富的知識(shí)結(jié)構(gòu)主要表現(xiàn)為圖上的邊，各種推理算法就是在圖上推導(dǎo)出邊的算法。在傳統(tǒng)圖論里，有可達(dá)性（reachability）推理，有大量的優(yōu)化研究。一些基本的傳遞性的推理，如分類(lèi)樹(shù)（taxonomy），是可以轉(zhuǎn)化為圖可達(dá)性推理的。但是大量的其他類(lèi)型的推理，沒(méi)有成熟的工程系統(tǒng)和算法可用。現(xiàn)有的圖數(shù)據(jù)庫(kù)，都局限很大，工程上成本很高。

  圖表示的另一個(gè)問(wèn)題是對(duì)混合表示不是很友好。因?yàn)橹R(shí)提取的成本是很高的，所以現(xiàn)實(shí)的工程中我們很難一步到位生成純結(jié)構(gòu)化的數(shù)據(jù)表示，我們的數(shù)據(jù)往往是結(jié)構(gòu)化和非結(jié)構(gòu)化（主要是文本）混合的。其中結(jié)構(gòu)化的比例，結(jié)構(gòu)化的質(zhì)量，可能是在應(yīng)用的過(guò)程中逐步提升的。開(kāi)始的時(shí)候可能文本的比例比較大。雖然 RDF 圖和屬性圖上的節(jié)點(diǎn)都可以有文本屬性，但是圖的索引還是與文本索引大不同，在實(shí)際使用中需要依賴(lài)集成 Lucene之類(lèi)的全文檢索引擎。由于文本不是“一等公民”，很多建模難以實(shí)現(xiàn)，比如在 RDF 里文本不能作為三元組的主語(yǔ)。

  
  

  由于圖表示很復(fù)雜，最廣為接受的知識(shí)組織其實(shí)是樹(shù)（taxonomy，hierarchy）。這是人的認(rèn)知決定的。計(jì)算機(jī)發(fā)展這么多年，界面元素的組織，被廣為接受的也只有樹(shù)、列表、表格。那些看起來(lái)很復(fù)雜的知識(shí)庫(kù)，其基礎(chǔ)也都是樹(shù)。

  
  

  所以樹(shù)形的 JSON 最終脫穎而出，不是偶然的。它符合人的認(rèn)知，滿(mǎn)足了結(jié)構(gòu)化和非結(jié)構(gòu)化混合表示的需要，兼容現(xiàn)有的工程實(shí)現(xiàn)。JSON 表示被稱(chēng)為“文檔”（document），2009 年以來(lái)興起了很多文檔數(shù)據(jù)庫(kù)（document database）。最近又有了 PostgeSQL 和 OrientDB 這樣混合關(guān)系與文檔的數(shù)據(jù)庫(kù)，可以實(shí)現(xiàn)可讀性好、工程兼容性好、表達(dá)力也還夠用的知識(shí)表示。

  
  

  JSON和YAML，易讀知識(shí)的藝術(shù)

  
  

  JSON 是很簡(jiǎn)單的數(shù)據(jù)格式。JSON 成為 Web API 的事實(shí)標(biāo)準(zhǔn)，部分實(shí)現(xiàn)了當(dāng)初語(yǔ)義網(wǎng)的一些目標(biāo)。但是幾年前，我和一位語(yǔ)義網(wǎng)領(lǐng)域的知名教授聊到語(yǔ)義數(shù)據(jù)的表示問(wèn)題，我提到了 JSON，他表示沒(méi)聽(tīng)說(shuō)過(guò)。這讓我很震驚，學(xué)術(shù)界何以對(duì)工業(yè)界數(shù)據(jù)表示的事實(shí)標(biāo)準(zhǔn)如此不關(guān)心呢？

  
  

  我們做研究，一定要從實(shí)踐中來(lái)，到實(shí)踐中去。實(shí)際的數(shù)據(jù)是什么樣，用什么樣的成本能獲得這些數(shù)據(jù)，這都不是隨便能假設(shè)的。JSON 在和 XML 的競(jìng)爭(zhēng)中勝利，基于 JSON 的 REST 服務(wù)框架在和基于 XML 的 SOAP 的競(jìng)爭(zhēng)中勝利，不是偶然的。因?yàn)?JSON 和 REST 更符合人的認(rèn)知的需要，生成他們的成本低，理解他們的成本低，工程師容易理解，最終就用起來(lái)了。所以現(xiàn)在 XML 和 SOAP 雖然是“國(guó)際標(biāo)準(zhǔn)”，但在 Web 上用的人很少，JSON 和 REST 這些“野路子”一統(tǒng)天下。這和屬性圖數(shù)據(jù)庫(kù)超越 RDF 數(shù)據(jù)庫(kù)是一個(gè)道理。

  
  

  在 Python 中使用 JSON 超級(jí)簡(jiǎn)單，JSON 和 Python 的字典很像，可以轉(zhuǎn)換。看官方文檔即可

  • json庫(kù) https://docs.python.org/2/library/json.html

  掌握下面這些庫(kù)會(huì)讓你處理json和字典的時(shí)候更開(kāi)心

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

  • marisa-trie https://github.com/kmike/marisa-trie 超級(jí)節(jié)約內(nèi)存的字典

  • DAWG http://dawg.readthedocs.org/en/latest/ 另一個(gè)超級(jí)節(jié)約內(nèi)存的字典

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

  • jsonpickle ?http://jsonpickle.github.io/ JSON持久化。支持更復(fù)雜數(shù)據(jù)的存儲(chǔ)

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

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

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

  • jsawk https://github.com/micha/jsawk json的awk，一個(gè)快速的命令上的查詢(xún)工具

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

  
  

  以上都是良心推薦，經(jīng)多年工程實(shí)戰(zhàn)考驗(yàn)的趁手工具。掌握了這些即使學(xué)不好知識(shí)圖譜，也可以成為不錯(cuò)的數(shù)據(jù)科學(xué)家 :D

  
  

  還有一些高級(jí)的話(huà)題，json pointer， json schema， xml2json， csv2json，暫時(shí)不提。我們只需要知道，json的工具鏈極為豐富。很多時(shí)候我們處理數(shù)據(jù)，就是卡在這些“小”工具上。你要是用了RDF，就會(huì)在無(wú)數(shù)小地方上因?yàn)槿鄙龠@些小工具而痛苦。

  
  

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

  警告 Yaml可能有嚴(yán)重的世界觀副作用，過(guò)敏者請(qǐng)謹(jǐn)慎使用。

  
  

  YAML 在我看來(lái)比 JSON 的可讀性更好，更加 Pythonic（因?yàn)槠湔Z(yǔ)法接近Python）。當(dāng)然有人可能會(huì)不喜歡縮進(jìn)，不過(guò) Python 社區(qū)的智力一般比較高，不會(huì)有這種偏見(jiàn)。YAML 里可以有節(jié)點(diǎn)之間的鏈接，因此可以表示圖。此外yaml里可以寫(xiě)!注!釋！我認(rèn)為 YAML 是天然的最好的知識(shí)圖譜表示語(yǔ)法。

  
  

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

  不過(guò) Yaml 解析的速度比 json 慢得多，大概只有 1/10。但是我們要牢記，知識(shí)表示最重要的是對(duì)人的友好，不是對(duì)機(jī)器的友好。速度不是大的問(wèn)題，大部分的知識(shí)庫(kù)都不是特別大。

  
  

  最后多說(shuō)一句無(wú)關(guān)的話(huà)，很多語(yǔ)言都有可讀性更好的類(lèi) Python 語(yǔ)法。下面是我收集的一個(gè)列表

  
  

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

  
  

  RDF 和 OWL

  
  

  雖然在大部分的應(yīng)用場(chǎng)景下我都不會(huì)推薦大家使用 RDF 和 OWL，但了解一下它們還是很有必要的，當(dāng)是打免疫針。當(dāng)然這兩個(gè)語(yǔ)言非常的復(fù)雜，官方文檔打印出來(lái)有 1000 頁(yè)厚，展開(kāi)講的話(huà)一個(gè)學(xué)期也講不完。好在我們是工程師，只關(guān)心如何應(yīng)用，不需要全面了解。

  
  

  但基礎(chǔ)的RDF是非常非常簡(jiǎn)單的，一頁(yè)紙就能說(shuō)清楚。RDF 的基本單元是三元組（triple）。每個(gè)三元組是（主語(yǔ) 謂語(yǔ) 賓語(yǔ)）這樣的元組 tuple。主謂賓的取值稱(chēng)為“資源”（Resource，也就是 RDF 里的 R）。資源可以是一個(gè)網(wǎng)址（URI），一個(gè)字符串或數(shù)字（嚴(yán)格來(lái)講都是帶類(lèi)型的字符串，稱(chēng)為literal），或者一個(gè)“空節(jié)點(diǎn)”（blank node）。主謂賓有一些限制，這里不細(xì)說(shuō)，看后面提到的文檔。

  
  

  有兩種特殊類(lèi)型的資源。rdfs:Class 代表類(lèi)。rdf:Property 代表二元關(guān)系。有一種特殊的關(guān)系叫 rdf:type ，聲明一個(gè)資源屬于某一個(gè)類(lèi)。

  
  

  用RDF建模，就要把所有的數(shù)據(jù)結(jié)構(gòu)分割為三元組。這對(duì)我們智人是很麻煩的事情，因?yàn)槲覀兊恼J(rèn)知里還會(huì)有定語(yǔ)、狀語(yǔ)、補(bǔ)語(yǔ)，所以 RDF 提供了一些很麻煩的變通方法，例如 reification。空節(jié)點(diǎn)也是一種方法。這些在實(shí)踐中都會(huì)帶來(lái)無(wú)窮無(wú)盡的煩惱。

  
  

  一個(gè)三元組就是一個(gè)關(guān)系。在 RDF 里我們可以聲明一些規(guī)則，從一些關(guān)系推導(dǎo)出另一些關(guān)系。這些規(guī)則我們稱(chēng)為“schema”，所以有了 RDFS（RDF Schema）。這些規(guī)則用一些詞匯（可以類(lèi)比編程語(yǔ)言里的保留字，不過(guò)RDF里任何詞匯都可以被重定義和擴(kuò)展）表示，如 subClassOf subPropertyOf domain range。

  
  

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

  
  

  RDF和OWL都有嚴(yán)格的語(yǔ)義。一種叫模型論語(yǔ)義，是一種非常可怕的東西！它是一個(gè)高階的語(yǔ)義，充斥著難懂的話(huà)，什么“映射”、“外延”、“解釋”、“蘊(yùn)涵” 之類(lèi)。模型論語(yǔ)義是這樣的使人快活，可是沒(méi)有它，別人也便這么過(guò)。因?yàn)檫€有基于規(guī)則的語(yǔ)義；這是一種不完備的語(yǔ)義，因?yàn)橛行┩评砜赡懿荒?00%得到模型論要求的結(jié)果。不過(guò)對(duì)于應(yīng)用，這種不完備性基本無(wú)所謂。

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

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

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

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

  
  

  各種語(yǔ)法里，優(yōu)先推薦用 Turtle 語(yǔ)法，因?yàn)樗?jiǎn)潔....得不像RDF http://www.w3.org/TR/turtle/

  
  

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

  
  

  這個(gè) 2011 年的綜述，提到了各種 RDF 相關(guān)的 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/

  
  

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

  
  

  參考手冊(cè)

  • 語(yǔ)義網(wǎng)速查表 http://ebiquity.umbc.edu/resource/html/id/94/ （丁力寫(xiě)的）

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

  
  

  JSON-LD

  
  

  JSON-LD 是 RDF 的 JSON 語(yǔ)法，其中 LD 代表 Linked Data。它要解決的是 RDF 沒(méi)有好的 Web 兼容語(yǔ)法問(wèn)題。經(jīng)典的 RDF 語(yǔ)法是 XML 的，不僅羅嗦和丑陋，也集成了XML“重”的一些特征，適合“企業(yè)級(jí)”（如今這個(gè)詞差不多就是恐龍、笨拙、難用的代名詞）應(yīng)用。JSON-LD 就是想提供一個(gè)和互聯(lián)網(wǎng)事實(shí)標(biāo)準(zhǔn)更兼容的、“輕”的語(yǔ)法。

  
  

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

  • 盡可能用對(duì)人友好的字符串來(lái)寫(xiě)作，而不是象在傳統(tǒng) RDF 里用難以理解的 URI。為了解釋字符串，就引入了@context，把字符串定義在一定的上下文下——這些上下文本身一般是 URI。這是比 XML domain更友好的設(shè)計(jì)，增強(qiáng)了可讀性。

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

  
  

  JSON 的官方文檔：

  • 主頁(yè) http://json-ld.org/

  • W3C標(biāo)準(zhǔn) https://www.w3.org/TR/2014/REC-json-ld-20140116/

  
  

  JSON-LD 本身現(xiàn)在還沒(méi)有普及起來(lái)。wikidata 在用，谷歌的 knowlege graph 也在用，但大多數(shù)人還不知道。我個(gè)人認(rèn)為這是個(gè)好東西，雖然難以預(yù)料未來(lái)能不能火起來(lái)。

  
  

  JSON-LD 體現(xiàn)了兩個(gè)對(duì)人友好的特性：可讀性和模塊化。第一代的 Web 知識(shí)語(yǔ)言如 RDF 和 OWL，可以類(lèi)比為知識(shí)的“匯編語(yǔ)言”，對(duì)機(jī)器很友好，對(duì)人不友好。Turtle 和 JSON-LD 這類(lèi)第二代語(yǔ)言，開(kāi)始“高級(jí)化”，注意了方便人來(lái)寫(xiě)作和閱讀，注意了引入適應(yīng)人的認(rèn)知需要的模塊。

  
  

  模塊化機(jī)制引入 RDF，前后花了十多年的時(shí)間。我自己從 2004-2010 也參與了一些工作。可以說(shuō)，中間大家都犯了很多錯(cuò)誤，走到今天的知識(shí)圖譜很不容易。今后大家肯定還會(huì)繼續(xù)犯錯(cuò)誤。但是如果大家能多想想人的需要，而不僅是機(jī)器的需要，可能會(huì)少犯些錯(cuò)誤吧。

  
  

  知識(shí)圖譜的高級(jí)語(yǔ)言

  
  

  最后再展開(kāi)說(shuō)說(shuō)我對(duì) Web 上知識(shí)表示的展望，基本基于我一篇老博文《語(yǔ)義網(wǎng)的高級(jí)語(yǔ)言》（2012-11-27）

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

  
  

  在談?wù)撜Z(yǔ)義網(wǎng)的時(shí)候，要和RDF路線(xiàn)區(qū)分開(kāi)來(lái)。

  
  

  和一些人談到語(yǔ)義網(wǎng)，他們說(shuō)：“語(yǔ)義網(wǎng)死了”。如果從 RDF 的角度來(lái)說(shuō)，是的——雖然 W3C 路線(xiàn)的支持者還不承認(rèn)。

  
  

  但是這種觀點(diǎn)，就如同計(jì)算機(jī)在只有機(jī)器語(yǔ)言，沒(méi)有高級(jí)語(yǔ)言的時(shí)候就斷言：“計(jì)算機(jī)死了”。

  
  

  我大膽提出兩個(gè)假設(shè)

  • RDF 是一門(mén)低級(jí)語(yǔ)言，只適合機(jī)器使用——如同機(jī)器語(yǔ)言或者匯編語(yǔ)言

  • 語(yǔ)義網(wǎng)需要一門(mén)高級(jí)語(yǔ)言，面向工程師（人），用來(lái)做大規(guī)模知識(shí)庫(kù)的寫(xiě)作、重用

  
  

  為什么說(shuō) RDF 是低級(jí)機(jī)器語(yǔ)言？

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

  • RDF 的語(yǔ)法，即使是 Turtle，也沒(méi)有可讀性，理解和重用起來(lái)非常困難。

  • RDF缺少“宏”或者構(gòu)造高層次組織的能力。其實(shí) SPARQL 彌補(bǔ)了一點(diǎn)，就是 graph pattern；一些語(yǔ)言如 SPIN，把 graph pattern 作為可重用的單元，甚至可以生成新的數(shù)據(jù)。如果把這個(gè)能力作為 RDF 原生的能力就好了。

  
  

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

  
  

  RDF 的問(wèn)題不是邏輯太少了，而是邏輯太多了。

  
  

  知識(shí)工程的問(wèn)題往往是太多考慮機(jī)器的需要，而不太考慮人的需要。而知識(shí)工程的瓶頸，又恰恰在人而不在機(jī)器。

  
  

  三元組的問(wèn)題在于模型的進(jìn)化能力有限。想為一句話(huà)再加個(gè)時(shí)間戳？想表示 Provenance？在 RDF 制定的早期，就提出了 reification 作為彌補(bǔ)。但是后來(lái)所有人都討厭這個(gè)丑陋的補(bǔ)丁。后來(lái)陸續(xù)有四元組、五元組、六元組、Context、Named Graph 等等各種其他的補(bǔ)丁。越搞越復(fù)雜，越來(lái)越?jīng)]人懂。所以我認(rèn)為，為知識(shí)表現(xiàn)專(zhuān)門(mén)開(kāi)發(fā)一門(mén)語(yǔ)言沒(méi)必要。特別是在 RDF 里 Literals 是二等公民（比如subject不允許是字符串！！），和它們真實(shí)的地位不相稱(chēng)。直接利用現(xiàn)有高級(jí)語(yǔ)言，如Python或Javascript，某個(gè)子集就好，不需要搞三元組。

  
  

  RDF 1.1 現(xiàn)在的幾個(gè)努力方向：JSON 語(yǔ)法，Named Graph, Turtle Syntax，這些都是好的。但是還不夠。我甚至懷疑，在 RDF 框架內(nèi)能不能達(dá)到易用性的目的。

  
  

  因?yàn)閺囊婚_(kāi)始，RDF 就被設(shè)計(jì)成 machine understandable 語(yǔ)言。這本是好的，至少在 1999 年。但是一個(gè)缺少高級(jí)語(yǔ)言的情況，就好像編程語(yǔ)言的早期。結(jié)果就是知識(shí)工程的人月神話(huà)。

  
  

  現(xiàn)在的情況也很象Web發(fā)明的時(shí)候：在 Internet 上，TCP/IP 是面向機(jī)器的低級(jí)語(yǔ)言，而 HTML 和 URL 是面向人的高級(jí)語(yǔ)言。我覺(jué)得，現(xiàn)在有一個(gè)強(qiáng)烈的需要來(lái)設(shè)計(jì)一個(gè) Semantic Web 的高級(jí)語(yǔ)言。

  
  

  這樣的高級(jí)語(yǔ)言要有什么特征呢？我覺(jué)得大體有這樣幾點(diǎn)

  • 支持多粒度的知識(shí)/數(shù)據(jù)組織和重用

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

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

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

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

  • 支持結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的混合表達(dá)（RDF有Literal，不過(guò)，那個(gè)太局限了）

  • 這個(gè)語(yǔ)言的文檔不要提什么“語(yǔ)義”（有幾個(gè)程序員關(guān)心SQL的語(yǔ)義？）,不要規(guī)定什么schema

  • 把推理轉(zhuǎn)化為圖的操作或者編程語(yǔ)言?xún)?nèi)置的運(yùn)算。在這之外的推理都先不考慮。

  • 從一開(kāi)始就設(shè)計(jì)成在cluster上能運(yùn)行的語(yǔ)言

  • 拜托，用程序員看的懂的語(yǔ)言和例子寫(xiě)文檔。

  
  

  其實(shí)這樣的語(yǔ)言雛形的一些部分，在不同的技術(shù)平臺(tái)上都已經(jīng)自發(fā)出現(xiàn)了。語(yǔ)義維基，圖數(shù)據(jù)庫(kù)，新一代檢索引擎，都包含了上述部分概念。有心人要做的，就是一個(gè)有機(jī)的組合。我想，在我寫(xiě)這一段的時(shí)候，大概已經(jīng)有人開(kāi)始做了。

  
  

  我甚至覺(jué)得，都沒(méi)有必要引入一個(gè)新的高級(jí)語(yǔ)言語(yǔ)法，就在現(xiàn)有的某種貼近 RDF 的編程語(yǔ)言里，做少量的增加就能實(shí)現(xiàn)目的。最理想的就是 Python。為什么這么說(shuō)？JSON 本身就是 Python 的數(shù)據(jù)結(jié)構(gòu)。而幾乎所有的數(shù)據(jù) API 都吃 JSON。Python 的類(lèi)與屬性定義與關(guān)系就是 RDF 的翻版。

  其實(shí)更合適的是 Lisp。但是 Lisp 對(duì)抽象思維要求太高，社區(qū)又太小。做面向 Web 的開(kāi)發(fā)，為了工程經(jīng)濟(jì)性（人力上的），還是 Python 比較合適。

更多內(nèi)容可以訪問(wèn)鏈接? https://github.com/memect/kg-beijing/wiki

---

OpenKG.CN

中文開(kāi)放知識(shí)圖譜（簡(jiǎn)稱(chēng)OpenKG.CN）旨在促進(jìn)中文知識(shí)圖譜數(shù)據(jù)的開(kāi)放與互聯(lián)，促進(jìn)知識(shí)圖譜和語(yǔ)義技術(shù)的普及和廣泛應(yīng)用。

轉(zhuǎn)載須知：轉(zhuǎn)載需注明來(lái)源“OpenKG.CN”、作者及原文鏈接。如需修改標(biāo)題，請(qǐng)注明原標(biāo)題。

點(diǎn)擊閱讀原文，進(jìn)入 OpenKG 博客。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。