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

---

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

  
  

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

  
  

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

  
  

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

  
  

  作為工程師，我們時(shí)時(shí)刻刻把可行性放在心中。傳統(tǒng)的知識圖譜的 KR，從邏輯和推理講起，有一階邏輯(first-order logic)和描述邏輯(description logic)，后來又有邏輯程序(logic program)和生成規(guī)則（Production Rule）。但是我反對從邏輯開始理解知識圖譜。語義網(wǎng)和知識圖譜是關(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è)插件。

  
  

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

  
  

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

  
  

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

  
  

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

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

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

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

  
  

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

  
  

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

  
  

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

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

  
  

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

  
  

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

  
  

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

  
  

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

  圖表示的另一個(gè)問題是對混合表示不是很友好。因?yàn)橹R提取的成本是很高的，所以現(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)用的過程中逐步提升的。開始的時(shí)候可能文本的比例比較大。雖然 RDF 圖和屬性圖上的節(jié)點(diǎn)都可以有文本屬性，但是圖的索引還是與文本索引大不同，在實(shí)際使用中需要依賴集成 Lucene之類的全文檢索引擎。由于文本不是“一等公民”，很多建模難以實(shí)現(xiàn)，比如在 RDF 里文本不能作為三元組的主語。

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

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

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

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

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

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

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

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

  • 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，一個(gè)快速的命令上的查詢工具

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

  
  

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

  
  

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

  
  

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

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

  
  

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

  
  

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

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

  
  

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

  
  

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

  
  

  RDF 和 OWL

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  • RDF和OWL語義 http://blog.memect.cn/?p=871 我的兩個(gè)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/

  
  

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

  
  

  Python 里的 rdflib 包可以很方便處理 RDF。推薦按 rdflib 的文檔過一遍例子，加深對 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/

  
  

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

  
  

  參考手冊

  • 語義網(wǎng)速查表 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 兼容語法問題。經(jīng)典的 RDF 語法是 XML 的，不僅羅嗦和丑陋，也集成了XML“重”的一些特征，適合“企業(yè)級”（如今這個(gè)詞差不多就是恐龍、笨拙、難用的代名詞）應(yīng)用。JSON-LD 就是想提供一個(gè)和互聯(lián)網(wǎng)事實(shí)標(biāo)準(zhǔn)更兼容的、“輕”的語法。

  
  

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

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

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

  
  

  JSON 的官方文檔：

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

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

  
  

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

  
  

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

  
  

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

  
  

  知識圖譜的高級語言

  
  

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

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

  
  

  在談?wù)撜Z義網(wǎng)的時(shí)候，要和RDF路線區(qū)分開來。

  
  

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

  
  

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

  
  

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

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

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

  
  

  為什么說 RDF 是低級機(jī)器語言？

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

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

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

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

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

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

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

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

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

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

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

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

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

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

  
  

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

  
  

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

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

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

---

OpenKG.CN

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

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

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

總結(jié)

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

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