鲍捷 | 知识表示——面向实战的介绍
本文轉(zhuǎn)載自文因互聯(lián) 2016 年 6 月份組織的第一期北京知識圖譜學(xué)習(xí)小組 Wiki。
知識表示（Knowledge Representation，KR，也譯為知識表現(xiàn)）是如何將結(jié)構(gòu)化數(shù)據(jù)組織，以便于機器處理和人的理解的方法。從結(jié)構(gòu)推導(dǎo)出新的結(jié)構(gòu)，這就是推理。傳統(tǒng)上KR屬于邏輯的分支，但在實踐中我們會用很簡單、可讀、可維護(hù)的數(shù)據(jù)結(jié)構(gòu)。
經(jīng)典的教科書中的 KR，主要關(guān)注的是如何方便機器處理。但是在現(xiàn)實的工程中，如何方便人的理解也是極為關(guān)鍵的。在工程實踐中，人才是知識不能被處理好、不能快速交換、不能規(guī)?；暮诵?。
知識表現(xiàn)的瓶頸不在于機器處理能力的不足，而在于人的認(rèn)知能力的不足。因此，我們在學(xué)習(xí)知識表現(xiàn)方法的時候，要始終牢記知識的可讀性、可維護(hù)性要遠(yuǎn)遠(yuǎn)比它的表達(dá)力、計算速度重要。知識是為人閱讀而設(shè)計的，只是偶爾被機器執(zhí)行。
數(shù)據(jù)優(yōu)先，邏輯靠邊
作為工程師，我們時時刻刻把可行性放在心中。傳統(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ù)的流動，用結(jié)構(gòu)化數(shù)據(jù)增進(jìn)其他系統(tǒng)的自動化能力的。邏輯只是很小的一個插件。
語義網(wǎng)，或者現(xiàn)在的知識圖譜，在應(yīng)用中，核心問題不是“應(yīng)該怎么樣”，而是“不得不怎么樣”。語義推理對數(shù)據(jù)質(zhì)量的要求很高，在工程上成本就承受不了?，F(xiàn)實的應(yīng)用，只能逐步提高數(shù)據(jù)的質(zhì)量，從數(shù)據(jù)清洗開始就要承擔(dān)巨額的投入，然后做實體抽取，實體鏈接，對齊，消歧，關(guān)系抽取，對齊，詞庫提取，本體建模，這每一步都是海一樣的銀子砸進(jìn)去。
然后在推理中，推理規(guī)則都需要人生成?，F(xiàn)在機器生成規(guī)則的能力很弱，幾乎不可用。僅僅是屬性和直接關(guān)系的查找可以機器做，稍微復(fù)雜的長程關(guān)系都需要人來寫。這在工程部署中有巨大的困難，因為這樣的工程師很少，寫出來的東西可維護(hù)性，性能，普適性都成問題。所以現(xiàn)實中的系統(tǒng)，很少有做推理的。即使是做推理，也很少是一階邏輯推理，一般也就是if then else，命題邏輯。很多時候還要容忍數(shù)據(jù)中的噪聲，和正則表達(dá)式等結(jié)合在一起用。所以學(xué)術(shù)派的推理機，一般都用不了。
所以我們會了解 RDF 和 OWL，但是并不推薦使用這些 W3C 標(biāo)準(zhǔn)作為工程的選擇。我們認(rèn)為 JSON 和關(guān)系數(shù)據(jù)庫是工程中成本較小的解決方案。在某些特定場合，圖的表示也是合理的。這會在之后的“知識存儲”的章節(jié)繼續(xù)討論。
其他一些我的個人觀點
-
我對關(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ù)據(jù)之間的關(guān)系。在計算機中的表示，就是數(shù)據(jù)結(jié)構(gòu)。傳統(tǒng)上，我們把那些能夠?qū)С鲂碌年P(guān)系的關(guān)系（比如“爸爸的爸爸是爺爺”，這里面“爸爸”和“爺爺”都是關(guān)系）看成知識。但是在目前的知識圖譜實踐中，并不會有嚴(yán)格的區(qū)分，我們把各種結(jié)構(gòu)都可以看成廣義的知識。
不過不是所有的數(shù)據(jù)結(jié)構(gòu)我們會用知識工程的方法來處理，比如集合、哈希表、隊列、堆棧、鏈表等等，一般丟給軟件工程去處理。另一類特殊的結(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é)點，添加更多的元數(shù)據(jù)，這就形成了有類型的邊構(gòu)成的圖譜結(jié)構(gòu)，上面每個邊和每個節(jié)點都擁有元數(shù)據(jù)。
圖的知識表現(xiàn)，演化出兩個流派。一個是 RDF 圖，一個是屬性圖（Property Graph）。RDF 圖是 W3C 的官方標(biāo)準(zhǔn)，得到了政府資金和一些大公司的大力支持，但是最終市場表現(xiàn)平平。屬性圖是草根自發(fā)的，最終得到了市場的認(rèn)可，現(xiàn)在主要是中小企業(yè)、創(chuàng)業(yè)公司在用。RDF 圖是科學(xué)頂層設(shè)計出來的，屬性圖是工程實戰(zhàn)中總結(jié)出來的。它們發(fā)展軌跡的不同也再次證明，好的架構(gòu)一般是總結(jié)出來的，不是憑空設(shè)計出來的。
RDF 圖的基礎(chǔ)是三元組，用 URI 命名節(jié)點和連接節(jié)點，有嚴(yán)格的語義，約束比較多。屬性圖沒有嚴(yán)格的語義，可以比較自由地聲明節(jié)點和邊的屬性。RDF 的優(yōu)勢在于推理，但是三元組的組織使稍復(fù)雜的關(guān)系的表達(dá)很困難，具體后述。屬性圖不定義推理，但是可以通過查詢語言（如Gremlin）來做模式（pattern）的查找和圖上的遍歷（traverse），可以實現(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)和算法可用?，F(xiàn)有的圖數(shù)據(jù)庫，都局限很大，工程上成本很高。
圖表示的另一個問題是對混合表示不是很友好。因為知識提取的成本是很高的，所以現(xiàn)實的工程中我們很難一步到位生成純結(jié)構(gòu)化的數(shù)據(jù)表示，我們的數(shù)據(jù)往往是結(jié)構(gòu)化和非結(jié)構(gòu)化（主要是文本）混合的。其中結(jié)構(gòu)化的比例，結(jié)構(gòu)化的質(zhì)量，可能是在應(yīng)用的過程中逐步提升的。開始的時候可能文本的比例比較大。雖然 RDF 圖和屬性圖上的節(jié)點都可以有文本屬性，但是圖的索引還是與文本索引大不同，在實際使用中需要依賴集成 Lucene之類的全文檢索引擎。由于文本不是“一等公民”，很多建模難以實現(xiàn)，比如在 RDF 里文本不能作為三元組的主語。
由于圖表示很復(fù)雜，最廣為接受的知識組織其實是樹（taxonomy，hierarchy）。這是人的認(rèn)知決定的。計算機發(fā)展這么多年，界面元素的組織，被廣為接受的也只有樹、列表、表格。那些看起來很復(fù)雜的知識庫，其基礎(chǔ)也都是樹。
所以樹形的 JSON 最終脫穎而出，不是偶然的。它符合人的認(rèn)知，滿足了結(jié)構(gòu)化和非結(jié)構(gòu)化混合表示的需要，兼容現(xiàn)有的工程實現(xiàn)。JSON 表示被稱為“文檔”（document），2009 年以來興起了很多文檔數(shù)據(jù)庫（document database）。最近又有了 PostgeSQL 和 OrientDB 這樣混合關(guān)系與文檔的數(shù)據(jù)庫，可以實現(xiàn)可讀性好、工程兼容性好、表達(dá)力也還夠用的知識表示。
JSON和YAML，易讀知識的藝術(shù)
JSON 是很簡單的數(shù)據(jù)格式。JSON 成為 Web API 的事實標(biāo)準(zhǔn)，部分實現(xiàn)了當(dāng)初語義網(wǎng)的一些目標(biāo)。但是幾年前，我和一位語義網(wǎng)領(lǐng)域的知名教授聊到語義數(shù)據(jù)的表示問題，我提到了 JSON，他表示沒聽說過。這讓我很震驚，學(xué)術(shù)界何以對工業(yè)界數(shù)據(jù)表示的事實標(biāo)準(zhǔn)如此不關(guān)心呢？
我們做研究，一定要從實踐中來，到實踐中去。實際的數(shù)據(jù)是什么樣，用什么樣的成本能獲得這些數(shù)據(jù)，這都不是隨便能假設(shè)的。JSON 在和 XML 的競爭中勝利，基于 JSON 的 REST 服務(wù)框架在和基于 XML 的 SOAP 的競爭中勝利，不是偶然的。因為 JSON 和 REST 更符合人的認(rèn)知的需要，生成他們的成本低，理解他們的成本低，工程師容易理解，最終就用起來了。所以現(xiàn)在 XML 和 SOAP 雖然是“國際標(biāo)準(zhǔn)”，但在 Web 上用的人很少，JSON 和 REST 這些“野路子”一統(tǒng)天下。這和屬性圖數(shù)據(jù)庫超越 RDF 數(shù)據(jù)庫是一個道理。
在 Python 中使用 JSON 超級簡單，JSON 和 Python 的字典很像，可以轉(zhuǎ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?？勺x/寫屬性，可遞歸訪問屬性，繼承dict的各種方法
-
marisa-trie https://github.com/kmike/marisa-trie 超級節(jié)約內(nèi)存的字典
-
DAWG http://dawg.readthedocs.org/en/latest/ 另一個超級節(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，一個快速的命令上的查詢工具
-
json-diff https://www.npmjs.org/package/json-diff 比較兩個json
以上都是良心推薦，經(jīng)多年工程實戰(zhàn)考驗的趁手工具。掌握了這些即使學(xué)不好知識圖譜，也可以成為不錯的數(shù)據(jù)科學(xué)家 :D
還有一些高級的話題，json pointer， json schema， xml2json， csv2json，暫時不提。我們只需要知道，json的工具鏈極為豐富。很多時候我們處理數(shù)據(jù)，就是卡在這些“小”工具上。你要是用了RDF，就會在無數(shù)小地方上因為缺少這些小工具而痛苦。
最后要隆重推薦一下YAML：JSON的超集，有更簡潔的語法 http://yaml.org/
警告 Yaml可能有嚴(yán)重的世界觀副作用，過敏者請謹(jǐn)慎使用。
YAML 在我看來比 JSON 的可讀性更好，更加 Pythonic（因為其語法接近Python）。當(dāng)然有人可能會不喜歡縮進(jìn)，不過 Python 社區(qū)的智力一般比較高，不會有這種偏見。YAML 里可以有節(jié)點之間的鏈接，因此可以表示圖。此外yaml里可以寫!注!釋！我認(rèn)為 YAML 是天然的最好的知識圖譜表示語法。
PyYAML 是 Python 里的 Yaml 處理庫 http://pyyaml.org/wiki/PyYAML
不過 Yaml 解析的速度比 json 慢得多，大概只有 1/10。但是我們要牢記，知識表示最重要的是對人的友好，不是對機器的友好。速度不是大的問題，大部分的知識庫都不是特別大。
最后多說一句無關(guān)的話，很多語言都有可讀性更好的類 Python 語法。下面是我收集的一個列表
有一本經(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)然這兩個語言非常的復(fù)雜，官方文檔打印出來有 1000 頁厚，展開講的話一個學(xué)期也講不完。好在我們是工程師，只關(guān)心如何應(yīng)用，不需要全面了解。
但基礎(chǔ)的RDF是非常非常簡單的，一頁紙就能說清楚。RDF 的基本單元是三元組（triple）。每個三元組是（主語 謂語 賓語）這樣的元組 tuple。主謂賓的取值稱為“資源”（Resource，也就是 RDF 里的 R）。資源可以是一個網(wǎng)址（URI），一個字符串或數(shù)字（嚴(yán)格來講都是帶類型的字符串，稱為literal），或者一個“空節(jié)點”（blank node）。主謂賓有一些限制，這里不細(xì)說，看后面提到的文檔。
有兩種特殊類型的資源。rdfs:Class 代表類。rdf:Property 代表二元關(guān)系。有一種特殊的關(guān)系叫 rdf:type ，聲明一個資源屬于某一個類。
用RDF建模，就要把所有的數(shù)據(jù)結(jié)構(gòu)分割為三元組。這對我們智人是很麻煩的事情，因為我們的認(rèn)知里還會有定語、狀語、補語，所以 RDF 提供了一些很麻煩的變通方法，例如 reification?？展?jié)點也是一種方法。這些在實踐中都會帶來無窮無盡的煩惱。
一個三元組就是一個關(guān)系。在 RDF 里我們可以聲明一些規(guī)則，從一些關(guān)系推導(dǎo)出另一些關(guān)系。這些規(guī)則我們稱為“schema”，所以有了 RDFS（RDF Schema）。這些規(guī)則用一些詞匯（可以類比編程語言里的保留字，不過RDF里任何詞匯都可以被重定義和擴展）表示，如 subClassOf subPropertyOf domain range。
RDF 里的推理規(guī)則有十幾條，其中最常用的大概就是父類子類關(guān)系（subClassOf）。有了它就可以表示分類樹，這種最常見的知識組織。后來在一些領(lǐng)域大家需要其他的一些推理規(guī)則，就又添加了幾十條規(guī)則，例如要表達(dá)女兒都是女生、哥哥的哥哥還是哥哥、爸爸的爸爸是爺爺、每人只有一個親爸爸，等等。這些規(guī)則被稱為 OWL，其中 O 代表 Ontology（本體）。我們不必關(guān)心本體的哲學(xué)定義，只要知道它是一些數(shù)據(jù)和推理規(guī)則的集合就好了。
RDF和OWL都有嚴(yán)格的語義。一種叫模型論語義，是一種非?？膳碌臇|西！它是一個高階的語義，充斥著難懂的話，什么“映射”、“外延”、“解釋”、“蘊涵” 之類。模型論語義是這樣的使人快活，可是沒有它，別人也便這么過。因為還有基于規(guī)則的語義；這是一種不完備的語義，因為有些推理可能不能100%得到模型論要求的結(jié)果。不過對于應(yīng)用，這種不完備性基本無所謂。
-
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/
各種語法里，優(yōu)先推薦用 Turtle 語法，因為它簡潔....得不像RDF http://www.w3.org/TR/turtle/
Python 里的 rdflib 包可以很方便處理 RDF。推薦按 rdflib 的文檔過一遍例子，加深對 RDF 的理解 http://rdflib.readthedocs.io/en/stable/
這個 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。感興趣的可以查查。我個人很喜歡pyDatalog，雖然不是RDF的推理機，但大部分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è)級”（如今這個詞差不多就是恐龍、笨拙、難用的代名詞）應(yīng)用。JSON-LD 就是想提供一個和互聯(lián)網(wǎng)事實標(biāo)準(zhǔn)更兼容的、“輕”的語法。
JSON-LD 基本思想是（我個人的理解）
-
盡可能用對人友好的字符串來寫作，而不是象在傳統(tǒng) RDF 里用難以理解的 URI。為了解釋字符串，就引入了@context，把字符串定義在一定的上下文下——這些上下文本身一般是 URI。這是比 XML domain更友好的設(shè)計，增強了可讀性。
-
引入模塊化組織，加強可讀性和可維護(hù)性。傳統(tǒng)的 RDF 的組織粒度太低，在三元組層面。JSON-LD 把同一個主語的三元組組織在一個 { } 塊下，方便寫作和理解。塊的主語可以用 @id 屬性聲明。更高層面上它還提供了 @graph 聲明，你可以把它理解成一個子模塊，模塊里的內(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ù)人還不知道。我個人認(rèn)為這是個好東西，雖然難以預(yù)料未來能不能火起來。
JSON-LD 體現(xiàn)了兩個對人友好的特性：可讀性和模塊化。第一代的 Web 知識語言如 RDF 和 OWL，可以類比為知識的“匯編語言”，對機器很友好，對人不友好。Turtle 和 JSON-LD 這類第二代語言，開始“高級化”，注意了方便人來寫作和閱讀，注意了引入適應(yīng)人的認(rèn)知需要的模塊。
模塊化機制引入 RDF，前后花了十多年的時間。我自己從 2004-2010 也參與了一些工作?？梢哉f，中間大家都犯了很多錯誤，走到今天的知識圖譜很不容易。今后大家肯定還會繼續(xù)犯錯誤。但是如果大家能多想想人的需要，而不僅是機器的需要，可能會少犯些錯誤吧。
知識圖譜的高級語言
最后再展開說說我對 Web 上知識表示的展望，基本基于我一篇老博文《語義網(wǎng)的高級語言》（2012-11-27）
-
http://baojie.org/blog/2012/11/27/advanced-language-of-semantic-web/
在談?wù)撜Z義網(wǎng)的時候，要和RDF路線區(qū)分開來。
和一些人談到語義網(wǎng)，他們說：“語義網(wǎng)死了”。如果從 RDF 的角度來說，是的——雖然 W3C 路線的支持者還不承認(rèn)。
但是這種觀點，就如同計算機在只有機器語言，沒有高級語言的時候就斷言：“計算機死了”。
我大膽提出兩個假設(shè)
-
RDF 是一門低級語言，只適合機器使用——如同機器語言或者匯編語言
-
語義網(wǎng)需要一門高級語言，面向工程師（人），用來做大規(guī)模知識庫的寫作、重用
為什么說 RDF 是低級機器語言？
-
用 URL 來尋址并不錯。但是把精確尋址的任務(wù)交給人，要求人來設(shè)計 URL，就如同在 C 編程中要求人對每個變量賦予內(nèi)存地址。 RDF 是一個“平坦”(flat)的語言，缺少內(nèi)部的組織單元。有很多建議，引入諸如package, named graph 這樣的組織單元，但目前還沒有達(dá)成共識或廣泛采用。
-
RDF 的語法，即使是 Turtle，也沒有可讀性，理解和重用起來非常困難。
-
RDF缺少“宏”或者構(gòu)造高層次組織的能力。其實 SPARQL 彌補了一點，就是 graph pattern；一些語言如 SPIN，把 graph pattern 作為可重用的單元，甚至可以生成新的數(shù)據(jù)。如果把這個能力作為 RDF 原生的能力就好了。
2010年RDF Working Group 開預(yù)備會議，我也與會了（ https://www.w3.org/2009/12/rdf-ws/papers/ws33 ）?，F(xiàn)在回來看，我那時的想法是錯誤的：為 RDF 引入更精確的語義，基于上下文(context)的組織和尋址，并不合適——雖然Pat Hayes后來很喜歡這個想法并在工作組內(nèi)推一個類似的想法。
RDF 的問題不是邏輯太少了，而是邏輯太多了。
知識工程的問題往往是太多考慮機器的需要，而不太考慮人的需要。而知識工程的瓶頸，又恰恰在人而不在機器。
三元組的問題在于模型的進(jìn)化能力有限。想為一句話再加個時間戳？想表示 Provenance？在 RDF 制定的早期，就提出了 reification 作為彌補。但是后來所有人都討厭這個丑陋的補丁。后來陸續(xù)有四元組、五元組、六元組、Context、Named Graph 等等各種其他的補丁。越搞越復(fù)雜，越來越?jīng)]人懂。所以我認(rèn)為，為知識表現(xiàn)專門開發(fā)一門語言沒必要。特別是在 RDF 里 Literals 是二等公民（比如subject不允許是字符串！！），和它們真實的地位不相稱。直接利用現(xiàn)有高級語言，如Python或Javascript，某個子集就好，不需要搞三元組。
RDF 1.1 現(xiàn)在的幾個努力方向：JSON 語法，Named Graph, Turtle Syntax，這些都是好的。但是還不夠。我甚至懷疑，在 RDF 框架內(nèi)能不能達(dá)到易用性的目的。
因為從一開始，RDF 就被設(shè)計成 machine understandable 語言。這本是好的，至少在 1999 年。但是一個缺少高級語言的情況，就好像編程語言的早期。結(jié)果就是知識工程的人月神話。
現(xiàn)在的情況也很象Web發(fā)明的時候：在 Internet 上，TCP/IP 是面向機器的低級語言，而 HTML 和 URL 是面向人的高級語言。我覺得，現(xiàn)在有一個強烈的需要來設(shè)計一個 Semantic Web 的高級語言。
這樣的高級語言要有什么特征呢？我覺得大體有這樣幾點
-
支持多粒度的知識/數(shù)據(jù)組織和重用
-
用字符串而不是URL來尋址。不追求addressing uniqueness, 而是probable and eventual addressing uniqueness
-
支持知識的分布式傳輸（按一定粒度）
-
使用目前主流程序員熟悉的語法形式。
-
盡可能少重新發(fā)明輪子——比如rdf:plainLiteral（我是作者之一）這樣的字符串類型就沒什么必要
-
支持結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的混合表達(dá)（RDF有Literal，不過，那個太局限了）
-
這個語言的文檔不要提什么“語義”（有幾個程序員關(guān)心SQL的語義？）,不要規(guī)定什么schema
-
把推理轉(zhuǎn)化為圖的操作或者編程語言內(nèi)置的運算。在這之外的推理都先不考慮。
-
從一開始就設(shè)計成在cluster上能運行的語言
-
拜托，用程序員看的懂的語言和例子寫文檔。
其實這樣的語言雛形的一些部分，在不同的技術(shù)平臺上都已經(jīng)自發(fā)出現(xiàn)了。語義維基，圖數(shù)據(jù)庫，新一代檢索引擎，都包含了上述部分概念。有心人要做的，就是一個有機的組合。我想，在我寫這一段的時候，大概已經(jīng)有人開始做了。
我甚至覺得，都沒有必要引入一個新的高級語言語法，就在現(xiàn)有的某種貼近 RDF 的編程語言里，做少量的增加就能實現(xiàn)目的。最理想的就是 Python。為什么這么說？JSON 本身就是 Python 的數(shù)據(jù)結(jié)構(gòu)。而幾乎所有的數(shù)據(jù) API 都吃 JSON。Python 的類與屬性定義與關(guān)系就是 RDF 的翻版。
其實更合適的是 Lisp。但是 Lisp 對抽象思維要求太高，社區(qū)又太小。做面向 Web 的開發(fā)，為了工程經(jīng)濟性（人力上的），還是 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)題。
點擊閱讀原文，進(jìn)入 OpenKG 博客。
總結(jié)
以上是生活随笔為你收集整理的鲍捷 | 知识表示——面向实战的介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python实现requests访问接口
- 下一篇： 梁家卿 | 百科知识图谱同步更新