1. 為什么我勸你先搞懂本體工程再動手建圖知識圖譜這個詞這幾年被說得太多了多到很多人一上來就問“用Neo4j怎么建圖”卻很少有人先問自己一句我到底要建一個什么樣的圖我見過太多團隊數(shù)據(jù)灌進去了節(jié)點和關(guān)系也連上了結(jié)果查詢的時候發(fā)現(xiàn)關(guān)系類型混亂、實體粒度不統(tǒng)一、同一個人在三張表里有三種寫法最后整個圖譜變成一團理不清的毛線球。問題的根子不在圖數(shù)據(jù)庫而在建模之前的那一步——本體工程。打個比方建知識圖譜就像蓋一棟樓。圖數(shù)據(jù)庫是施工隊和建材RDF/屬性圖是磚塊的形狀而本體是建筑圖紙。你可以沒有圖紙就讓施工隊直接砌墻砌出來的東西也能住人但一旦想加個房間、改個承重結(jié)構(gòu)整棟樓就得推倒重來。本體工程干的就是畫圖紙這件事定義這個領(lǐng)域里有哪些概念類、這些概念有什么屬性數(shù)據(jù)屬性、概念之間能建立什么關(guān)系對象屬性、以及有哪些不能違反的規(guī)則公理和約束。這篇內(nèi)容適合三類人看。第一類是完全沒接觸過知識圖譜、想從零搭一個的開發(fā)者我會把每一步的操作和背后的理由都講清楚。第二類是已經(jīng)用過Neo4j或者圖數(shù)據(jù)庫、但建?？偸欠倒さ墓こ處熌隳茉谶@里找到返工的根因。第三類是做數(shù)據(jù)治理、想往語義方向轉(zhuǎn)型的朋友本體工程是你繞不開的基本功。核心工具我會圍繞Protégé展開格式以RDF/OWL為主最后落到Neo4j的落地映射。整套流程我自己走過不止一遍踩過的坑會在對應(yīng)位置標(biāo)出來。2. 本體工程到底在解決什么問題2.1 從“數(shù)據(jù)表”思維切換到“概念”思維大部分人第一次做知識圖譜腦子里裝的還是關(guān)系型數(shù)據(jù)庫那套東西。表、字段、外鍵一對一、一對多。這套思維在結(jié)構(gòu)化數(shù)據(jù)里沒問題但一放到知識圖譜里就會出問題。原因很簡單關(guān)系型數(shù)據(jù)庫的schema是給存儲和查詢優(yōu)化的而本體的schema是給語義和推理優(yōu)化的兩者的目標(biāo)根本不一樣。舉個具體的例子。假設(shè)你要建一個“企業(yè)知識圖譜”里面有公司、人、產(chǎn)品三個核心概念。在關(guān)系型數(shù)據(jù)庫里你可能會建三張表然后用外鍵關(guān)聯(lián)。但在本體里你要先問公司和組織是什么關(guān)系公司是不是組織的一個子類人是不是可以同時是員工和股東產(chǎn)品有沒有可能屬于多個公司這些問題的答案決定了你的類層次結(jié)構(gòu)怎么設(shè)計。我自己的經(jīng)驗是做本體設(shè)計時先別打開Protégé拿一張白紙把領(lǐng)域里所有的名詞先列出來。名詞就是候選的類動詞就是候選的對象屬性形容詞和數(shù)量就是候選的數(shù)據(jù)屬性。這個“名詞動詞法”聽起來土但極其有效。列完之后你會發(fā)現(xiàn)有些名詞其實是同一個概念的不同叫法有些動詞其實指向的是同一個關(guān)系這時候再去做歸并和抽象比直接上手建模要靠譜得多。2.2 本體、RDF、OWL三者的關(guān)系別搞混這三個詞經(jīng)常被混著用但它們的層次是不一樣的。RDF是一個數(shù)據(jù)模型它規(guī)定了“三元組”這種表達形式主語-謂語-賓語就這么簡單。你可以把RDF理解成“句子的語法”它只告訴你句子怎么造不告訴你句子對不對。OWL是建立在RDF之上的本體描述語言它提供了更豐富的詞匯來表達類、屬性、個體以及它們之間的邏輯關(guān)系。OWL讓你能說“A是B的子類”“X和Y是不相交的”“這個屬性的定義域是C”這些聲明就是本體的核心內(nèi)容。OWL有不同表達力的子語言從OWL Lite到OWL DL再到OWL Full表達力越強推理的復(fù)雜度越高。實際項目里我一般用OWL DL它在表達力和可計算性之間取得了比較好的平衡。本體則是你用OWL或者RDFS寫出來的那套概念體系的統(tǒng)稱。本體是內(nèi)容OWL是寫內(nèi)容的語言RDF是底層的存儲格式。三者是“內(nèi)容-語言-格式”的關(guān)系不是并列關(guān)系。搞清楚這一點你在看Protégé里的各種設(shè)置時就不會暈。2.3 本體工程能幫你避開的三個大坑第一個坑是實體粒度不統(tǒng)一。沒有本體約束的情況下有人把“北京市”當(dāng)成一個實體有人把“北京市朝陽區(qū)”也當(dāng)成一個實體還有人把“北京”和“北京市”當(dāng)成兩個不同的實體。本體通過定義類的實例化規(guī)則和等價關(guān)系能在建模階段就把粒度問題解決掉。第二個坑是關(guān)系類型泛濫。我見過一個圖譜里有“屬于”“隸屬于”“歸屬”“從屬”四個關(guān)系實際上表達的是同一個意思。本體工程要求你在設(shè)計階段就明確對象屬性的集合并且通過屬性層次結(jié)構(gòu)來管理同義關(guān)系避免后期數(shù)據(jù)灌入時出現(xiàn)關(guān)系爆炸。第三個坑是推理能力缺失。沒有本體的圖譜就是一個靜態(tài)的圖你存了什么它就只能查什么。有了本體你可以定義傳遞屬性、對稱屬性、函數(shù)屬性讓圖譜具備推理能力。比如你定義了“位于”是傳遞屬性那么“A位于BB位于C”就能自動推出“A位于C”不需要你手動加邊。這個能力在實體鏈接和關(guān)系補全場景里非常關(guān)鍵。3. 用Protégé從零搭建本體的完整實操3.1 環(huán)境準(zhǔn)備與Protégé基礎(chǔ)配置Protégé是斯坦福大學(xué)開發(fā)的本體編輯器開源免費目前主流版本是5.6.x。下載地址在官網(wǎng)就能找到Windows、Mac、Linux都有對應(yīng)的安裝包。安裝過程沒什么好說的一路下一步就行。但有幾個配置項我建議你在開始建模前就調(diào)好能省掉后面很多麻煩。第一個是渲染器設(shè)置。Protégé默認(rèn)的渲染器在某些系統(tǒng)上會顯示異常尤其是中文環(huán)境下。你可以在Preferences里找到Renderer把實體渲染器改成“Render entities as qname”或者“Render entities as label”。我一般用label渲染因為建模時看中文標(biāo)簽比看英文ID直觀得多。第二個是推理機配置。Protégé本身不帶推理機你需要裝一個插件。最常用的是HermiT和PelletHermiT對OWL DL的支持比較完整推理速度也還行。在Preferences的Reasoner選項卡里可以設(shè)置默認(rèn)推理機。裝好之后記得在Reasoner菜單里點一下“Start reasoner”這樣你在建模過程中就能實時看到推理結(jié)果比如某個類被推斷為不可滿足unsatisfiable時會標(biāo)紅。第三個是文件格式。Protégé默認(rèn)保存為OWL/XML格式這個格式機器友好但人不好讀。如果你需要版本管理或者人工review建議同時導(dǎo)出一份Turtle格式.ttl可讀性好很多。我自己的習(xí)慣是主文件用OWL/XML每次提交前導(dǎo)出一份Turtle做diff。注意Protégé的自動保存功能默認(rèn)是關(guān)閉的建模過程中一定要養(yǎng)成CtrlS的習(xí)慣。我丟過一次做了三個小時的本體從那以后就設(shè)了每5分鐘自動保存。3.2 定義類層次結(jié)構(gòu)從頂層本體到領(lǐng)域本體類層次結(jié)構(gòu)是本體的骨架。我的做法是先搭一個輕量的頂層框架再往里填領(lǐng)域內(nèi)容。頂層框架不需要太復(fù)雜通常包含“實體”“事件”“屬性”“關(guān)系”這幾個大類就夠了。有些項目會直接復(fù)用BFO或者DOLCE這些成熟的頂層本體但對于大多數(shù)業(yè)務(wù)場景來說自己搭一個簡單的頂層反而更靈活。具體操作上在Protégé的Classes標(biāo)簽頁里你可以通過“Add subclass”來創(chuàng)建子類。我建議一開始就把命名規(guī)范定好比如類名用大駝峰Company、Person、Product屬性名用小駝峰hasName、belongsTo實例名用全小寫加下劃線。這個規(guī)范看起來是小事但等到圖譜有幾千個節(jié)點的時候命名混亂會讓你痛不欲生。類層次結(jié)構(gòu)的深度也要控制。我見過有人把類層次做到七八層結(jié)果自己都記不住哪個類在哪個位置。一般來說三到五層就夠了。第一層是頂層概念第二層是領(lǐng)域大類第三層是具體子類再往下就是實例了。如果發(fā)現(xiàn)需要更深的層次往往說明你的抽象方式有問題可能需要引入新的維度而不是繼續(xù)往下分。還有一個實操技巧在Protégé里可以用“Create class hierarchy from indentation”功能批量導(dǎo)入類結(jié)構(gòu)。你可以先在文本編輯器里用縮進寫好類層次然后粘貼進去Protégé會自動解析成樹形結(jié)構(gòu)。這個功能在類數(shù)量多的時候特別好用比一個個點快得多。3.3 對象屬性與數(shù)據(jù)屬性的設(shè)計要點屬性設(shè)計是本體工程里最容易出問題的地方。對象屬性描述的是類與類之間的關(guān)系數(shù)據(jù)屬性描述的是類與字面量字符串、數(shù)字、日期之間的關(guān)系。兩者的設(shè)計思路完全不同。對象屬性設(shè)計時首先要確定定義域domain和值域range。定義域是“這個屬性從哪個類出發(fā)”值域是“這個屬性指向哪個類”。比如“belongsTo”這個屬性定義域是Product值域是Company意思就是“產(chǎn)品屬于公司”。定義域和值域設(shè)好之后推理機就能幫你檢查數(shù)據(jù)的一致性如果某個產(chǎn)品指向了一個不是公司的實體推理機就會報錯。對象屬性還有幾個重要的特性需要根據(jù)業(yè)務(wù)語義來設(shè)置。函數(shù)屬性Functional表示“每個主體最多只有一個值”比如“hasCEO”就是函數(shù)屬性一個公司只能有一個CEO。逆函數(shù)屬性InverseFunctional表示“每個值最多被一個主體指向”比如“hasID”就是逆函數(shù)屬性一個身份證號只能對應(yīng)一個人。傳遞屬性Transitive表示“關(guān)系可以傳遞”比如“l(fā)ocatedIn”。對稱屬性Symmetric表示“關(guān)系雙向成立”比如“marriedTo”。這些特性設(shè)對了推理機就能幫你自動補全很多隱含關(guān)系。數(shù)據(jù)屬性的設(shè)計相對簡單但有一個坑要注意數(shù)據(jù)類型的選擇。Protégé支持string、integer、float、boolean、dateTime等多種數(shù)據(jù)類型。我建議在建模階段就把數(shù)據(jù)類型定死不要都用string。原因很簡單如果你把年齡存成string后面想做數(shù)值比較查詢就麻煩了。另外對于有固定取值范圍的屬性可以用枚舉enumeration來約束比如“status”只能是“active”“inactive”“pending”三個值之一。提示屬性命名時加前綴能大幅提升可讀性。對象屬性用“has”“is”“belongsTo”這類動詞開頭數(shù)據(jù)屬性用“has”“is”開頭一眼就能區(qū)分。3.4 個體、公理與約束的添加方法個體Individual是類的實例是本體里最底層的元素。在Protégé的Individuals標(biāo)簽頁里可以創(chuàng)建個體并指定它屬于哪個類。個體創(chuàng)建時要注意兩點一是命名要唯一且有意義不要用“個體1”“個體2”這種二是要盡量填寫數(shù)據(jù)屬性值這些值在后續(xù)映射到圖數(shù)據(jù)庫時會直接變成節(jié)點屬性。公理Axiom是本體的靈魂它定義了概念之間必須滿足的邏輯約束。最常見的公理包括子類關(guān)系SubClassOf、等價關(guān)系EquivalentTo、不相交關(guān)系DisjointWith、屬性約束someValuesFrom、allValuesFrom、minCardinality、maxCardinality。這些公理寫好了推理機就能幫你做一致性檢查、分類推斷和實例推斷。我舉一個實際場景來說明公理的價值。假設(shè)你定義了“Employee”和“Company”兩個類并且定義了“worksFor”這個對象屬性。如果你給“worksFor”加上“someValuesFrom Company”的約束那么任何聲明了worksFor關(guān)系的個體推理機都會自動把它推斷為Employee類的實例。這就是推理帶來的自動化能力你不需要手動給每個員工打標(biāo)簽。約束的添加要循序漸進。一開始不要寫太多復(fù)雜的公理先把基本的類層次和屬性關(guān)系建好跑一遍推理機看看有沒有報錯。確認(rèn)基礎(chǔ)沒問題之后再逐步添加更精細(xì)的約束。我見過有人一上來就寫了幾十條公理結(jié)果推理機跑不動或者報了一堆自己看不懂的錯最后只能全部刪掉重來。4. 從本體到Neo4j知識圖譜的落地映射4.1 本體模型到屬性圖模型的轉(zhuǎn)換規(guī)則本體建好了接下來要把它落到圖數(shù)據(jù)庫里。這里有一個關(guān)鍵認(rèn)知OWL本體和屬性圖Property Graph不是一一對應(yīng)的中間需要一個轉(zhuǎn)換層。OWL的類對應(yīng)屬性圖的節(jié)點標(biāo)簽LabelOWL的個體對應(yīng)屬性圖的節(jié)點NodeOWL的數(shù)據(jù)屬性對應(yīng)節(jié)點的屬性PropertyOWL的對象屬性對應(yīng)屬性圖的邊Relationship。但這個對應(yīng)關(guān)系有幾個細(xì)節(jié)需要處理。第一OWL支持多繼承一個個體可以同時屬于多個類而屬性圖的節(jié)點可以有多個標(biāo)簽這一點是對得上的。第二OWL的對象屬性可以有屬性比如“worksFor”這個關(guān)系本身有“startDate”屬性但屬性圖的邊雖然理論上可以帶屬性實際使用中很多圖數(shù)據(jù)庫對邊屬性的支持有限這時候就需要把邊升級為節(jié)點即“關(guān)系實體化”。第三OWL的推理能力在屬性圖里是沒有的你需要在數(shù)據(jù)導(dǎo)入階段就把推理結(jié)果算好或者在圖數(shù)據(jù)庫層面用查詢來實現(xiàn)部分推理。我一般的做法是先用Protégé把本體建好然后用SPARQL查詢把推理后的三元組導(dǎo)出來再寫一個轉(zhuǎn)換腳本把三元組轉(zhuǎn)成Neo4j的Cypher導(dǎo)入語句。這個流程雖然多了一步但能保證本體里的推理結(jié)果被完整地帶到圖數(shù)據(jù)庫里。4.2 用Python腳本實現(xiàn)本體到Cypher的自動轉(zhuǎn)換手動把本體里的每個類、每個屬性、每個個體都寫成Cypher語句是不現(xiàn)實的必須自動化。我用的是Python的rdflib庫來解析OWL文件然后生成Cypher語句。核心邏輯分三步解析類生成節(jié)點標(biāo)簽約束解析對象屬性生成關(guān)系類型解析個體生成節(jié)點和邊。from rdflib import Graph, Namespace, RDF, RDFS, OWL g Graph() g.parse(my_ontology.owl, formatxml) # 提取所有類 classes [] for s in g.subjects(RDF.type, OWL.Class): label g.value(s, RDFS.label) classes.append((s, label)) # 提取所有對象屬性 obj_props [] for s in g.subjects(RDF.type, OWL.ObjectProperty): domain g.value(s, RDFS.domain) range_ g.value(s, RDFS.range) obj_props.append((s, domain, range_)) # 生成Cypher cypher_lines [] for cls, label in classes: cypher_lines.append(fCREATE CONSTRAINT IF NOT EXISTS FOR (n:{label}) REQUIRE n.uri IS UNIQUE;) for prop, domain, range_ in obj_props: cypher_lines.append(f// Relationship: {prop} from {domain} to {range_})這段代碼只是骨架實際使用時要處理命名空間、多語言標(biāo)簽、屬性特性函數(shù)屬性、傳遞屬性等細(xì)節(jié)。但核心思路就是這樣把本體的結(jié)構(gòu)信息提取出來映射成圖數(shù)據(jù)庫的schema。注意Neo4j的標(biāo)簽和關(guān)系類型不支持中文和特殊字符所以在本體建模時最好給每個類和一個英文ID中文放在label屬性里。這樣轉(zhuǎn)換時用英文ID做標(biāo)簽中文做顯示名兩邊都不耽誤。4.3 數(shù)據(jù)導(dǎo)入后的圖譜質(zhì)量校驗數(shù)據(jù)灌進去不代表就完事了必須做質(zhì)量校驗。我一般從四個維度來查完整性、一致性、唯一性、連通性。完整性查的是有沒有該有的邊沒連上。比如每個Product節(jié)點都應(yīng)該有一條belongsTo邊指向Company如果存在沒有這條邊的Product就說明數(shù)據(jù)有問題。這個可以用Cypher查詢來檢查MATCH (p:Product) WHERE NOT (p)-[:BELONGS_TO]-(:Company) RETURN p.name AS product_name一致性查的是有沒有違反本體約束的數(shù)據(jù)。比如本體里定義了“Person”和“Company”是不相交的那就不應(yīng)該存在一個節(jié)點同時是Person和Company。這個檢查在本體層面用推理機做在圖數(shù)據(jù)庫層面可以用Cypher做。唯一性查的是有沒有重復(fù)節(jié)點。同一個實體被導(dǎo)入了兩次或者同一個實體有不同的URI都會導(dǎo)致圖譜里出現(xiàn)重復(fù)。這個可以用節(jié)點的關(guān)鍵屬性比如名稱、ID做分組查詢來發(fā)現(xiàn)。連通性查的是圖譜有沒有孤島。如果有一部分節(jié)點和主圖完全不連通要么是數(shù)據(jù)缺失要么是建模時漏了關(guān)系。這個用弱連通分量算法就能查出來。5. 實操中踩過的坑與排查技巧5.1 本體建模階段的典型錯誤第一個典型錯誤是類層次過深。我一開始做本體的時候總覺得分類越細(xì)越好結(jié)果建了一個七層的類層次到第四層的時候自己都記不清哪個類該放哪里了。后來我總結(jié)了一個原則如果一個類下面只有一兩個子類而且這些子類沒有本質(zhì)區(qū)別那就不要往下分了用屬性來區(qū)分就行。第二個典型錯誤是屬性定義域設(shè)得太寬。比如把“hasName”的定義域設(shè)成“Thing”意思是所有東西都可以有名字。這看起來沒問題但實際上會讓推理機無法做有效的類型檢查。正確的做法是把定義域設(shè)成具體的類比如“Person”和“Company”各自定義自己的名稱屬性或者定義一個“NamedEntity”類作為它們的父類。第三個典型錯誤是忽略命名空間。Protégé默認(rèn)會給你一個base URI但很多人建模時不在意這個結(jié)果導(dǎo)出的OWL文件里全是自動生成的URI可讀性極差。我建議在新建本體時就設(shè)置一個有意義的base URI比如“http://yourdomain.com/ontology/yourdomain#”這樣導(dǎo)出的文件里所有實體都有清晰的URI。5.2 推理機報錯的常見原因與解決推理機報錯是新手最頭疼的問題。最常見的報錯是“Unsatisifiable class”意思是某個類是不可滿足的即不存在任何個體能同時滿足這個類的所有約束。這通常是因為約束之間互相矛盾比如一個類同時被約束為“必須有一個值來自A”和“必須有一個值來自B”而A和B是不相交的。排查這類問題的方法是在Protégé里點“Explain”按鈕它會告訴你哪些公理導(dǎo)致了矛盾。然后你逐條檢查這些公理看哪條寫錯了或者哪兩條不應(yīng)該同時存在。另一個常見報錯是“Inconsistent ontology”意思是整個本體不一致存在某個個體同時屬于兩個不相交的類。這個排查起來更麻煩因為問題可能出在任何一個個體的聲明上。我的做法是先把推理機關(guān)掉手動檢查所有DisjointWith聲明確認(rèn)沒有個體同時屬于兩個不相交的類。然后再開推理機看是否還有報錯。提示推理機跑得慢的時候可以先關(guān)掉“EquivalentTo”和“DisjointWith”這些復(fù)雜公理只保留基本的類層次和屬性關(guān)系跑一遍看看基礎(chǔ)有沒有問題?；A(chǔ)沒問題再逐步加回復(fù)雜公理這樣能快速定位問題。5.3 圖譜查詢性能優(yōu)化的幾個手段圖譜建好之后查詢性能是繞不開的問題。我總結(jié)下來優(yōu)化手段主要有三個層次schema層、查詢層、存儲層。Schema層的優(yōu)化主要是加索引和約束。Neo4j里對經(jīng)常用來做查詢?nèi)肟诘膶傩约铀饕艽蠓嵘樵兯俣?。比如你?jīng)常按名稱查節(jié)點那就給name屬性加索引。另外給每個節(jié)點加一個唯一性約束比如uri屬性不僅能保證數(shù)據(jù)質(zhì)量還能加速基于該屬性的查詢。查詢層的優(yōu)化主要是避免全圖掃描。Cypher查詢里如果用了沒有索引的屬性做過濾Neo4j會做全圖掃描數(shù)據(jù)量大的時候會非常慢。寫查詢時盡量從有索引的屬性入手然后用關(guān)系擴展來縮小范圍。另外合理使用“PROFILE”命令來分析查詢計劃看看有沒有可以優(yōu)化的地方。存儲層的優(yōu)化主要是調(diào)整Neo4j的內(nèi)存配置。Neo4j的性能很大程度上取決于頁面緩存page cache的大小。如果圖譜數(shù)據(jù)量大于可用內(nèi)存查詢就會頻繁讀磁盤速度會急劇下降。我一般會把頁面緩存設(shè)成可用內(nèi)存的50%到70%剩下的留給操作系統(tǒng)和查詢執(zhí)行。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案推理機報Unsatisifiable class約束矛盾用Explain功能查看矛盾公理刪除或修改沖突的約束圖譜查詢返回空結(jié)果關(guān)系方向?qū)懛礄z查Cypher里的箭頭方向調(diào)整查詢中的關(guān)系方向?qū)霐?shù)據(jù)后節(jié)點重復(fù)URI不唯一按關(guān)鍵屬性分組統(tǒng)計合并重復(fù)節(jié)點或修正URI推理機跑不動公理太復(fù)雜逐步減少公理測試簡化公理或換用更輕量的推理機圖譜查詢慢缺少索引用PROFILE分析查詢計劃給過濾屬性加索引本體文件打不開格式不兼容檢查文件擴展名和內(nèi)容轉(zhuǎn)換格式或修復(fù)文件6. 本體版本管理與團隊協(xié)作的實操建議6.1 用Git管理OWL文件的正確姿勢OWL文件本質(zhì)上是文本文件完全可以用Git做版本管理。但直接管理OWL/XML格式的diff可讀性很差因為XML的標(biāo)簽嵌套很深稍微改一個地方就會產(chǎn)生大量diff。我的做法是主文件用OWL/XML但每次提交前用Protégé導(dǎo)出一份Turtle格式的文件Turtle的diff可讀性好很多review的時候看Turtle文件就行。Git的commit message也要有規(guī)范。我一般用“feat: 添加Product類”“fix: 修正belongsTo的定義域”“refactor: 重構(gòu)類層次結(jié)構(gòu)”這樣的格式和代碼提交的規(guī)范保持一致。這樣回溯歷史的時候能快速定位到某次修改。還有一個細(xì)節(jié)Protégé保存文件時會改變文件的內(nèi)部排序?qū)е录词箖?nèi)容沒變diff也會顯示大量變化。解決方法是每次保存后先跑一遍格式化工具比如rdflib的序列化把文件內(nèi)容規(guī)范化然后再提交。這樣diff就只顯示真正的語義變化了。6.2 多人協(xié)作時的命名沖突解決多人同時編輯一個本體時命名沖突是最大的問題。兩個人可能給同一個概念起了不同的名字或者給不同的概念起了相同的名字。解決這個問題的關(guān)鍵是建立命名規(guī)范并嚴(yán)格執(zhí)行。我的做法是在項目開始時就建一個“命名約定”文檔規(guī)定類名、屬性名、實例名的命名規(guī)則和命名空間前綴。每個人在創(chuàng)建新實體之前先搜索一下是否已經(jīng)存在類似的實體。Protégé的搜索功能可以按名稱和URI搜索用起來很方便。如果沖突已經(jīng)發(fā)生了解決方法是先找出所有沖突的實體然后確定哪個是“正確”的把另一個的引用全部改成正確的最后刪除錯誤的實體。在Protégé里可以用“Refactor”菜單下的“Rename entity”功能來批量修改引用比手動改要安全得多。6.3 本體文檔化與知識傳承本體建完之后如果不寫文檔過三個月自己都看不懂。文檔不需要很復(fù)雜但必須包含幾個核心內(nèi)容類的定義和用途、屬性的語義和約束、典型的使用示例、版本變更記錄。我一般會在本體文件里用rdfs:comment給每個類和屬性加注釋這些注釋在Protégé里可以直接看到也能導(dǎo)出成文檔。另外我會單獨維護一個Markdown格式的“本體設(shè)計說明”記錄設(shè)計決策的背景和理由。比如“為什么把Company和Organization分開”“為什么belongsTo是函數(shù)屬性”這些決策背后的思考比本體本身更有價值。知識傳承方面我建議每個季度做一次本體review檢查是否有過時的類或?qū)傩孕枰獜U棄是否有新的業(yè)務(wù)需求需要擴展。Review的時候拉上業(yè)務(wù)方一起確保本體和實際業(yè)務(wù)保持一致。本體不是建完就完了它是一個活的資產(chǎn)需要持續(xù)維護。