簡單來說，壹個知識圖譜的schema就是相當於壹個領域內的數據模型，包含了這個領域裏面有意義的概念類型以及這些類型的屬性。任何壹個域的schema主要由類型（type）和屬性（property）來表達。圖1是plantdata內的創投schema，主要是為了發掘壹級市場的投資和融資構建的schema。該schema主要是去定義需求，哪些數據對創投有用，才往上構建，例如：人物都有身高 體重，但是這些數據對創投來說意義不大，在schema中就不用構建了。關註創投的人會關註這些基金與人物投資了哪些公司，投資的公司所屬行業，投資的公司屬於哪壹類企業，在該schema中就需要詳細構建。
1.如何構建域（domain）
域（domain）的概念是淩駕於所有類型之上，對於域的定義應該盡量的抽象，不應該具體，同時域與域之間應盡量做到相互獨立，不交叉。例如，省份就不應該是壹個域的概念，在思考是否應該把壹個概念當做域時，需要考慮到該概念是否能夠繼續向上抽象，例如：省份；城市；國家；縣等等，他們同屬於地理位置域。在明確域的概念時，應該定義好域的邊界，這樣比較容易區分不同域之間的區域劃分。
2.如何確定壹個域的類型（type）
這裏需要產品經理去思考，構建這個schema的核心需求是什麽，到底需要解決用戶什麽問題。為了滿足這些核心需求，我們需要創造出哪些概念？
舉個例子，在汽車領域，用戶主要關心什麽問題，例如：汽車的品牌、車系、發動機。
在NBA領域，用戶主要關心球隊、所屬聯盟、教練、球員等等。
針對不同的需求，需要在域下面構建不同的類型來滿足用戶的需求。
3.如何確定屬性（property）
思考的角度如下：
1.以用戶需求為出發點
2.以數據統計為證據
比如在構建完足球領域中的球隊類型後，該類型集合了所有的球隊實體，站在用戶角度觸發，用戶會關註球隊的哪些關系？
圖2是我簡單的針對足球領域構建的壹個圖譜，上面包含了梅西（球隊的球員）， 埃內斯托·巴爾韋德 （球隊的教練），西甲（球隊的所屬聯賽），其中梅西、西甲、埃內斯托.巴爾韋德又分屬於不同的類型：足球球員，足球聯賽，足球教練，這些所有的類型構成了足球域。
從上圖的common sense配合圖查詢和自然語言處理技術已經可以支持基礎的問答了，例如，梅西是哪個球隊的？埃內斯托巴爾韋德是哪些球員的教練？西甲有哪些球隊在踢球？等等
schema的應用是產品經理需要重點考慮的內容，因為產品需求決定了schema應該怎麽構建，構建的是否完備。而產品的具體應用則主導了schema的整體構建方式，如果不仔細考慮產品應用的話，最慘的情況可能構建了很久的schema會因為壹個邏輯坑而徹底報廢掉，由於知識圖譜又是壹個牽壹發而動全身的工程，根據實際經驗來說，如果圖譜構建和應用有部分脫節，可能修改圖譜schema比重新構建圖譜schema的成本還要高。所以，首先確認好具體的應用場景對於壹個schema構建的成功與否是至關重要的。
筆者寫壹套曾經用過的確認schema的流程
先將應用根據需求的強弱劃分，分為基礎核心需求，schema特色需求，錦上添花需求，未來擴展性需求。
基礎核心需求：是經過需求分析後，構建這個schema需要完成最核心的需求，該需求優先級最高
schema特色需求：構建圖譜時可能會經常遇到圖譜可以實現而其他方法實現比較困難的特色需求，這類需求可能需求強度不是很高，但是由於能夠實現壹定的差異性，經常會有意想不到的效果。
錦上添花需求：非基礎核心需求，做了更好，不做也可以接受
未來擴展性的需求：確認schema的時候要充分考慮到未來的擴展性，因為這類需求有可能會大改圖譜的schema結構
在構建schema的時候，根據上述分類，需要去考慮該schema壹期需要滿足哪些具體的功能，將功能壹壹列下來，哪些功能是需要放在第二期、第三期完成的，未來的擴展性需求需要在構建的哪壹塊區域留下可擴展的內容。
常用的方法可以使用excel去列出壹、二、三期所需要的功能點。
列出上述的功能點後，針對每壹個功能點在後面備註好該功能的構建要點（註：這個非常重要），通常需求只需要將產品需求轉化成壹定的查詢結構即可，筆者原來用的是cypher查詢語法。以圖2為例，我要支持某個教練教了哪些球員？轉化成查詢語言就是（a:足球教練）<-{b:教練}-（c:球隊）-{d:球員}-（e:足球球員） return e。將a變成參數，輸入a即可返回所有的e，即輸入埃內斯托巴爾韋德，返回就是梅西。
流程如下：query:埃內斯托巴爾韋德帶了哪些球員？→語義解析→轉化成上述查詢，將埃內斯托巴爾韋德作為參數a代入查詢→返回結果→前端包裝展示
註：上面在每個功能點後面備註了構建要點，當大部分功能點的構建要點都寫完的時候，需要集中查看構建要點，因為如果需求本身比較大的話，不同的需求很容易造成schema的構建沖突，正如前面所講，schema盡量要保證少出錯。這個時候由於備註了構建要點，可以全局的來審視這個schema中間有沒有邏輯黑洞。常出現的問題主要是在屬性的設計，以及知識融合上。
拿著上述文件去找開發，確認壹下哪些是比較好實現的，壹般來說做到這種程度大多數需求開發都是會接的。如果開發同學足夠專業的話，他會從他的視角去給妳提出他的寶貴意見。通常產品經理在思考schema這壹塊更傾向於思考這個schema的作用，而開發同學會思考工程實現、實現效率、運行效率、計算量等問題。
大規模構建schema的時候需要認真考慮數據源的情況，由於不同公司掌握的數據不同，所應用的對策也不同。
通常筆者會將數據源分為如下幾種：
1.已經清洗好的結構化數據：這部分數據壹般是公司的核心數據，或者其他公司的核心數據，構建的時候應該優先考慮這類數據。這部分數據通常只需要改變數據格式即可入圖譜。
2.清洗好的結構化數據，但數據殘缺：這部分數據通常需要數據挖掘，知識融合。清洗難度是由殘缺比例決定的。
3.無數據：沒有這部分數據，但是又需要這部分數據，通常只能去選擇讓BD去購買數據，或者讓爬蟲組去專業網站爬取，例如：企業數據可以去企查查，電影的數據可以去貓眼，產業的數據可以去產業信息網等等。
假設需要構建的圖譜entity數量在千萬級別，開發力量不夠強大的時候，慎用純數據挖掘方案，有條件的話筆者建議直接去買結構化數據，因為可能挖掘和知識融合在經濟上的成本比直接買數據要高，而且時間周期也會很長。
個人認為，大規模構建schema最難的地方就在於挖掘數據的知識融合上，舉個例子：全國有10000個叫王剛的人，爬蟲從A網站挖下來5000個“王剛”，從B網站挖下來7000個“王剛”，那麽這5000個王剛和那7000個王剛到底是不是壹個人？在沒有身份證號碼的情況下如何確定哪些王剛是壹個人呢？常規的做法是去挖掘出“王剛”的其他信息，例如出生年月，任職信息，籍貫等等，然後通過壹定的算法進行知識融合。通常，網站的數據不壹定全面，即使經過知識融合後，挖掘的數據中壹定會有大量的噪音，不同的需求對噪音的承受能力是不同的，構建schema的時候需要充分考慮數據出現噪音的可能性，去評價這部分需求對噪音的承受能力。
如果知識融合完成了話，大規模構建其實就是壹個導數據的過程，由於圖譜數據結構的關系，壹般存2張表（點、邊）或者使用RDFs存儲，在entity數量上千萬以後，圖譜的查詢壓力會比較大，單機查詢可能會直接跪掉，開發壹般會采用graphX的分布式的存儲，不過由於點和邊的切割方式的問題，會有壹定的副作用。