簡單來說，知識圖譜的模式相當於壹個領域中的數據模型，包含了這個領域中有意義的概念類型及其屬性。任何領域的模式主要通過類型和屬性來表達。圖1是plantdata中的創投圖式，主要是為了探索壹級市場的投融資而構建的。該模式主要是在建立風險投資之前定義需求以及哪些數據對風險投資有用。比如所有的人物都有身高體重，但是這些數據對風險投資的意義不大，所以沒有必要在圖式中構建。關註風險投資的人會關註這些資金和人物投資了哪些公司，投資的行業，投資的公司類型，這些都需要在這個圖式中詳細構建。
1.如何構建壹個域
定義域的概念是在所有類型之上的，定義域的定義要盡可能抽象，而不是具體，同時定義域要盡可能獨立，不交叉。例如，省不應該是壹個領域概念。在思考壹個概念是否應該作為壹個域的時候，我們需要考慮這個概念是否可以繼續向上抽象，比如:省；城市；國家；縣等，都屬於地理位置域。在界定域的概念時，要明確域的邊界，這樣更容易區分不同域之間的地域劃分。
2.如何確定壹個域的類型？
在這裏，產品經理需要思考構建這個模式的核心需求是什麽，用戶需要解決什麽問題。我們需要創造什麽概念來滿足這些核心需求？
比如汽車領域，用戶主要關心什麽問題，比如汽車的品牌、車系、發動機等。
在NBA領域，用戶主要關心球隊、聯賽、教練、球員等等。
根據不同的需求，需要在域下構建不同的類型來滿足用戶的需求。
3.如何確定財產
思考的角度如下:
1.從用戶需求出發
2.以統計數據為證據
例如，在足球領域建立了壹個團隊類型後，該類型從用戶的角度將所有團隊實體和觸發器集合在壹起。用戶會關註哪些關系？
圖2是我為足球領域構建的壹個簡單圖集，包括梅西(球隊的球員)、埃內斯托·巴爾韋德(球隊的教練)和西甲(球隊的聯賽)，其中梅西、西甲和埃內斯托·巴爾韋德分屬不同類型:足球運動員、足球聯賽和足球教練，這三者共同構成了足球領域。
從上圖來看，常識可以用圖形查詢和自然語言處理技術支持基本的問答。比如梅西是哪個隊的？埃內斯托·巴爾韋德的教練是誰？西甲有哪些球隊在踢？等等
模式的應用是產品經理需要考慮的重點內容，因為產品需求決定了模式應該如何構建，是否完整。但是，產品的具體應用主導了模式的整體構建模式。如果不仔細考慮產品應用，最糟糕的情況可能是構建了很久的模式會因為壹個邏輯坑而徹底報廢。因為知識地圖是牽壹發而動全身的工程，根據實踐經驗，如果地圖構建和應用部分脫節，修改地圖圖式的代價可能比重建地圖圖式的代價更大。因此，確認具體的應用場景對於模式構建的成功非常重要。
作者編寫了壹套用於確定模式的過程。
首先，將應用按照需求強度分為基本核心需求、模式特征需求、錦上添花需求和未來擴展需求。
基本核心需求:需求分析後構建這個模式需要完成的核心需求，這個需求的優先級最高。
模式特征需求:在構建地圖時，您可能會經常遇到可以通過其他方法實現的特征需求。這樣的要求可能不是很強烈，但往往會有意想不到的效果，因為可以達到壹定的差異性。
錦上添花:非基礎的核心需求，做的比較好的，不做也能接受。
未來的可擴展性需求:在確定模式時，要充分考慮未來的可擴展性，因為這樣的需求可能會極大地改變地圖的模式結構。
在構建模式的時候，按照上面的分類，需要考慮模式在第壹階段需要滿足哪些具體的功能，把功能壹壹列出來，第二、三階段需要完成哪些功能，未來的擴展需要在哪些區域留下可擴展的內容。
常用的方法可以用excel列出壹、二、三階段需要的功能點。
列出上述功能點後，針對每個功能點在後面註明功能的關鍵點(註意:這個很重要)。通常需求只需要將產品需求轉化為壹定的查詢結構即可。作者最初使用的是cypher查詢語法。以圖2為例。我要支持壹個教練教過哪些球員。翻譯成查詢語言就是(甲:足球教練)
流程如下:查詢:埃內斯托·巴爾韋德帶了哪些球員？→語義分析→轉化為上面的查詢，將Ernesto valverde作為參數A代入查詢→返回結果→前端打包顯示。
註意:上面每個功能點後面都註明了構造點。大部分功能點的構造點在編寫的時候，需要重點關註構造點，因為如果需求本身比較大，不同的需求很容易導致架構構造上的沖突。如前所述，模式應該盡量確保更少的錯誤。這時候因為註意到了構造的關鍵點，就可以從全局來看這個圖式中間是否存在邏輯黑洞。常見的問題主要在屬性設計和知識融合方面。
拿上面的文檔去找開發，確認壹下哪些比較好實現。壹般來說，大多數需求開發都會達到這個水平。如果開發同學足夠專業，他會站在他的角度給妳他的寶貴意見。通常產品經理在思考的時候更傾向於思考這個模式的作用，而開發者會思考工程實現、實現效率、運行效率、計算量等問題。
在大規模構建模式時，需要認真考慮數據源的情況。因為不同的公司有不同的數據，所以他們采用不同的對策。
通常，我會將數據源分為以下幾類:
1.清洗過的結構化數據:這部分數據壹般是本公司或其他公司的核心數據，在構建時應優先考慮這類數據。這部分數據通常只需要改變數據格式就可以進入地圖。
2.幹凈的結構化數據，但是數據不完整:這部分數據通常需要數據挖掘和知識融合。清洗的難易程度由缺陷的比例決定。
3.沒有數據:沒有這樣的數據，但是需要。通常只能選擇讓BD購買數據，或者讓爬蟲群在專業網站上抓取。比如企業數據可以查，電影數據可以查，行業數據可以在工業信息網上查。
假設要構建的圖集實體數量在千萬級，且開發力量不夠強大，則應慎用純數據挖掘方案。如果可能的話，我建議直接購買結構化數據，因為挖掘和知識融合的經濟成本可能比直接購買數據要高，時間周期會很長。
個人認為，大規模建立模式最難的地方在於挖掘數據的知識融合。比如中國有10000個叫王剛的人，爬蟲從A網站挖了5000個“王剛”，從b網站挖了7000個“王剛”，那麽這5000個王剛和那7000個王剛是壹個人嗎？如何確定哪個王剛是沒有身份證號的人？常規的做法是挖掘出“王剛”的其他信息，如出生日期、就業信息、籍貫等，然後通過壹定的算法進行知識融合。通常網站的數據不壹定全面，即使是知識融合後，挖掘出來的數據也會有很多噪音，不同的需求對噪音的容忍度也不同。在構建模式時，需要充分考慮數據中存在噪聲的可能性，以評估這部分需求對噪聲的容忍度。
如果知識融合完成，大規模的構建其實是壹個數據領先的過程。由於地圖集的數據結構，通常存儲兩個表(點和邊)或使用RDFs。實體數千萬後，圖譜的查詢壓力會更大，單機查詢可能會直接掉線。開發壹般會采用graphX的分布式存儲，但是會因為切點切邊的問題產生壹些副作用。