1.3-知識圖譜怎麼去作？

知識圖譜怎麼去作，這固然不是幾句話說得清楚的。首先確定要先基於自身的業務進行思考，這裏整理一些知識圖譜構建的主要路徑。

構建的邏輯思路

• 一、梳理業務，構建本體：是否須要用知識圖譜？成本怎麼樣，能達到怎麼的效果？是否有能力構建知識圖譜？數據、團隊等狀況是否能支撐？若是有必要，如何根據業務梳理一套本體框架？
• 二、編輯本體，給出業務知識表示框架：能夠利用Protege進行本體編輯，得到一個用OWL表示的知識表示文件。
• 三、給本體補充實例數據：先找一些示例數據，便於理解。

構建的不一樣方式

• 自頂向下的構建方式：先定義本體和數據模式，再將實體加入知識庫。利用一些現有的結構化知識庫做爲其基礎知識庫。
• 自底向上的構建方式：從一些開放連接數據中提取出實體，選擇其中置信度較高的加入到知識庫，再構建頂層的本體模式。

構建過程當中的關鍵技術

• 大致包含五個方面：知識抽取、知識表示、知識融合、知識加工、知識評估
• 經過知識提取技術，能夠從一些公開的半結構化、非結構化和第三方結構化數據庫的數據中提取出實體、關係、屬性等知識要素。
• 知識表示則經過必定有效手段對知識要素表示，便於進一步處理使用。分佈式的知識表示造成的綜合向量對知識庫的構建、推理、融合以及應用均具備重要的意義。
• 而後經過知識融合，可消除實體、關係、屬性等指稱項與事實對象之間的歧義，造成高質量的知識庫。
• 知識加工則是在已有的知識庫基礎上進一步挖掘隱含的知識，構建新本體，補全關係，從而豐富、擴展知識庫。
• 知識評估能夠對知識的可信度進行量化，保留置信度較高的，捨棄置信度較低的，有效確保知識的質量。
• 除此以外，大規模知識圖譜構建，還須要多種技術的支持：分佈式存儲和計算、圖數據庫、圖推理、內存數據庫等。

數據的存儲數據庫選擇

• 知識圖譜的存儲和查詢語言也經歷了歷史的洗滌，從RDF到OWL以及SPARQL查詢，都逐漸由於使用上的不便及高昂的成本，而被工業界主流所遺棄。

圖數據庫逐步成爲目前主要的知識圖譜存儲方式。

• 目前應用比較普遍的圖數據庫包括Neo4j、graphsql、sparkgraphx（包含圖計算引擎）、基於hbase的Titan、BlazeGraph等，各家的存儲語言和查詢語言也不盡相同。

實際應用場景下，OrientDB和postgresql也有不少的應用，主要緣由是其相對低廉的實現成本和性能優點。

應用推理和知識自學習

• 在知識圖譜構建過程當中，還存在不少關係補全問題。雖然一個普通的知識圖譜可能存在數百萬的實體和數億的關係事實，但相距補全還差很遠。

知識圖譜的補全是經過現有知識圖譜來預測實體之間的關係，是對關係抽取的重要補充。

• 傳統方法TransE和TransH經過把關係做爲從實體A到實體B的翻譯來創建實體和關係嵌入，可是這些模型僅僅簡單地假設實體和關係處於相同的語義空間。

而事實上，一個實體是由多種屬性組成的綜合體，不一樣關係關注實體的不一樣屬性，因此僅僅在一個空間內對他們進行建模是不夠的。

相關資料

• 大規模知識圖譜的構建、推理及應用
• 肖仰華 | 大規模知識圖譜構建與應用