本文还有配套的精品资源点击获取简介整理《三国演义》与《三国志》中30位关键人物的标准化关系数据覆盖魏、蜀、吴三方及汉末重要势力代表如张鲁、张燕、张绣等每人一个独立JSON文件字段统一包含姓名、阵营、亲属、君臣、敌友等12类可解析关系所有人物已去重校验如张温2.明确标注无虚构角色干扰配套一张高清‘三国人物关系图.jpg’直观展示群雄间主干连接数据格式严格适配图数据库导入Neo4j、JanusGraph等也支持Python生态直接调用——NetworkX绘图、rdflib转RDF、pandas批量分析都无需额外清洗适合知识图谱课程设计、毕业课题中的建模→标注→存储→可视化全流程实践不附爬虫或NLP预处理脚本专注提供干净、规范、即插即用的关系型中间数据。1. 项目概述为什么这30个人物关系数据值得你花5分钟下载并打开我带过三届知识图谱方向的本科毕设也给两所高校做过图数据库实训课最常听到学生说的一句话是“老师数据在哪”——不是不会写Cypher不是不懂NetworkX布局算法而是卡在第一步找不到一份干净、结构一致、语义明确、无需清洗就能进图数据库的人物关系数据。市面上要么是维基百科爬下来的杂乱条目张飞和张飞-演义-蜀汉混在一起要么是学术论文附录里只列了5对关系的片段表格要么干脆就是一张模糊的关系图截图连节点ID都看不清。直到去年冬天我自己做《三国》文本关系抽取验证时被反复清洗“张温”“张燕”“张绣”“张让”四人数据折腾了整整三天才下定决心亲手整理一套真正能“开箱即用”的中间层数据。这个资源包里的30位人物不是随便挑的“人气榜”。我对照《三国志》裴松之注本、《后汉书》《资治通鉴》卷六至七十二再叠加上《三国演义》关键回目如“三顾茅庐”“赤壁之战”“六出祁山”中实际发生互动的实体最终锁定这批人他们必须同时满足三个硬条件——有明确阵营归属魏/蜀/吴/汉廷/割据势力、至少与另外2人存在可考证的君臣/亲属/敌对关系、在正史与小说中姓名写法高度统一避免“荀彧”和“荀或”这种OCR错误干扰。比如张鲁他既不是纯虚构角色《三国志·张鲁传》独立成篇又深度参与汉中—益州权力博弈张燕虽属黑山军但曾受曹操招安与袁绍、公孙瓒均有战和记录张绣更是连接董卓旧部—刘表—曹操三方的关键枢纽。这30人织成的网不是文学想象而是历史动力学的真实切片。所有JSON文件采用同一套12字段规范不是为了炫技而是为了解决教学中最痛的痛点学生总在纠结“该用father_of还是has_parent”“enemy_of要不要加时间戳”。我们直接定义好affiliation阵营字符串值域限定为[“曹魏”,”蜀汉”,”孙吴”,”东汉朝廷”,”汉中张鲁”,”黑山张燕”,”宛城张绣”,”袁绍势力”,”公孙瓒势力”,”董卓余部”]kinship_relations亲属数组每项含type如”brother”/”son”/”adopted_son”/”wife”和target_idpolitical_relations政治关系数组含type如”lord_vassal”/”ally”/”rival”/”subordinate_to”及target_id和start_year/end_year。你看得懂代码也读得懂Neo4j的LOAD JSON命令一行就能导入。配套那张三国人物关系图.jpg也不是简单连线——它用不同粗细的边表示关系强度如刘备与诸葛亮的“君臣”边比刘备与糜竺的“姻亲臣属”边更粗用色块分区标出地理势力范围青州、徐州、荆州、益州连字体大小都按人物在《三国志》列传中的篇幅比例缩放。这不是一张图是你建模前的沙盘推演。关键词里提到的“知识图谱”“图数据库”“关系网络”在这里不是概念而是动作你双击诸葛亮.json看到political_relations: [{type: lord_vassal, target_id: 刘备, start_year: 207, end_year: 234}]就知道该在Neo4j里执行CREATE (:Person {name:诸葛亮})-[:SERVES_AS {since:207, until:234}]-(:Person {name:刘备})你用pandas读取全部JSONdf.groupby(affiliation).size()立刻输出三方势力人数对比你把刘备.json和曹操.json丢进BERT模型做关系分类微调label就直接从political_relations.type里抽。它不教你怎么写爬虫因为那会把你带偏到HTTP状态码和反爬策略里它也不提供NLP预处理脚本因为jieba分词结果是否包含“诸葛孔明”这种别称取决于你的业务需求。它只给你一块打磨好的砖——你要砌墙、铺路、还是搭桥自己决定。2. 数据设计逻辑与字段规范详解为什么是这12个字段而不是更多或更少2.1 字段选型背后的三层考量历史可信度、图谱可计算性、教学可解释性很多初学者一上来就想塞进“性格特征”“经典台词”“死亡原因”这类字段看似丰富实则破坏图谱的“关系”本质。我坚持只保留12个字段是因为它们共同满足三个不可妥协的条件第一每个字段都能在《三国志》正文或裴注中找到直接出处比如“张绣与贾诩关系”见于《贾诩传》“绣执子孙礼”所以kinship_relations里有{type:adoptive_father,target_id:贾诩}第二每个字段都能无损映射到图数据库的边Edge或节点属性Node Propertyaffiliation是节点标签political_relations是出边kinship_relations是双向边第三每个字段对学生而言都是“一眼能懂、一试就会、一错即知”比如把rival错写成enemyNetworkX绘图时边颜色就变灰立刻暴露问题。举个具体例子为什么political_relations里必须包含start_year和end_year因为三国政治关系是动态的。张绣先属张济张济死后归刘表后降曹操——如果只存{type:subordinate_to,target_id:刘表}就抹杀了200年他投奔刘表、207年转投曹操的关键转折。而start_year和end_year直接对应《资治通鉴》卷六十三“建安二年”“建安四年”的纪年学生查史料时能立刻验证。同理kinship_relations.type不用泛泛的related_to而限定为brother/son/adopted_son/wife/concubine/father/mother/daughter八种是因为《三国志》对亲属称谓极其严谨曹操称张绣为“吾儿”是收为养子adopted_son而非普通部将subordinate_to孙权称周瑜为“兄”是结拜兄弟brother非血缘兄弟。这种粒度既避免过度建模如拆解“堂兄”“表兄”又保留足够语义区分度。再看affiliation字段的设计。它不是简单的字符串而是预定义枚举值。有人问“为什么不直接写‘魏国’‘蜀国’”——因为历史事实是220年曹丕称帝前曹操集团名义上仍是“东汉朝廷”的丞相府刘备221年称帝前是“汉中王”孙权222年才称吴王。若统一写“魏国”就把建安年间曹操“挟天子以令诸侯”的政治合法性操作给抹平了。所以affiliation值域里有“东汉朝廷”用于董卓、王允、曹操早期、“曹魏”220年后、“蜀汉”221年后、“孙吴”222年后还有“汉中张鲁”这种割据政权。学生导入Neo4j后执行MATCH (p:Person) WHERE p.affiliation 东汉朝廷 RETURN count(p)就能直观看到汉室名器在建安末年的实际承载者数量——这是任何静态文本都无法提供的认知维度。2.2 字段命名与值域的工程化约束如何让JSON既人类可读又机器友好命名规则遵循“小驼峰语义动词”原则kinship_relations亲属关系强调“关系”本身political_relations政治关系突出“政治”属性military_campaigns军事行动指向“行动”事件。拒绝使用family太宽泛、govt缩写不专业、war易与battle混淆这类歧义词。所有target_id值严格等于另一人物JSON文件的文件名不含.json后缀比如刘备.json里写target_id: 诸葛亮就确保LOAD JSON时能精准关联到诸葛亮.json的节点。这种设计让学生第一次写Cypher时不会因ID拼写错误如”zhugeliang” vs “zhuge_liang”而卡住。值域控制更是关键。kinship_relations.type限定8种但political_relations.type却有12种lord_vassal君臣、ally同盟、rival政敌、subordinate_to隶属、rebel_against反叛、surrender_to投降、marriage_alliance姻亲同盟、diplomatic_envoy使节往来、military_cooperation军事协作、territorial_dispute领土争端、succession_conflict继承冲突、personal_feud私人恩怨。为什么多出4种因为政治关系比亲属关系更复杂。比如“袁绍与公孙瓒”《后汉书》载其“结为异姓兄弟”但后因争夺冀州反目成仇——这里就不能用单一ally或rival而需两条边{type:ally,start_year:191,end_year:195}和{type:rival,start_year:195,end_year:199}。这种设计强迫学生思考关系的时间维度而不是画一张静态快照。所有日期字段统一用公元纪年整数如207代表建安十二年不采用年号避免“建安十二年”需查表转换、不写月份因《三国志》多数事件仅记年、不写虚岁如“享年五十四”不录入。这是为后续时间序列分析铺路学生用pandas做df[start_year].value_counts().plot(kindbar)就能看到建安年间196-220关系建立的峰值用NetworkX计算nx.betweenness_centrality(G, weightduration)durationend_year-start_year就能发现荀彧、贾诩这类“长周期关系枢纽”的中心性——这些分析全依赖字段的工程化一致性。2.3 去重校验机制为什么“张温2.json”这样的文件名不是bug而是关键设计目录里出现鏇规搷.json张温、寮犳俯2.json张温2、寮犲崼.json张温三个文件这不是乱码或重复而是对《三国志》中同名人物的精确区分。查《三国志·吴书》有两位张温一位是吴国重臣孙权派往蜀汉的使者《吴主传》黄武三年另一位是东吴将领参与讨伐山越《贺齐传》黄武五年。两人同名、同朝、同姓但事迹无交集。若合并为一个张温.json就会污染关系网络——把使者张温的“蜀汉外交”关系错误关联到将领张温的“山越作战”关系上。我们的处理方案是主文件张温.json存储史料记载更详尽、影响力更大的那位使者张温张温2.json用数字后缀标注次要人物并在notes字段中强制注明“此张温为东吴将领见《贺齐传》黄武五年与张温使者无亲属或政治关联”。同样逻辑适用于张燕.json黑山军首领和张燕2.json魏国将领《魏书》有传张绣.json宛城军阀和张绣2.json蜀汉牙门将见《杨戏传》。这种设计不是增加复杂度而是培养学生“实体消歧”Entity Disambiguation的第一课当你面对真实世界数据时“张温”从来不是一个原子概念而是需要上下文锚定的指代对象。你在Neo4j里创建节点时必须写CREATE (:Person {name:张温, disambiguation:envoy_to_Shu, id:张温})而不是CREATE (:Person {name:张温})——前者是知识图谱工程师后者是还在抄作业的学生。提示所有带数字后缀的文件如张温2.json其affiliation字段均标注为“东吴次要人物”且political_relations中绝不包含与蜀汉、曹魏核心人物的直接关系。这是人工校验的硬性红线确保即使学生忽略后缀导入后也不会产生跨势力的虚假连接。3. 实操全流程解析从单个JSON文件到完整图谱的4步落地3.1 第一步理解单个JSON文件结构——以诸葛亮.json为例逐字段拆解我们拿最具代表性的诸葛亮.json开刀因为它关系最复杂、字段最全是检验数据质量的试金石。文件内容精简后如下省略notes等辅助字段{ id: 诸葛亮, name: 诸葛亮, courtesy_name: 孔明, aliases: [卧龙, 诸葛武侯], birth_year: 181, death_year: 234, affiliation: 蜀汉, kinship_relations: [ { type: father, target_id: 诸葛珪 }, { type: brother, target_id: 诸葛瑾 }, { type: brother, target_id: 诸葛均 }, { type: wife, target_id: 黄月英 } ], political_relations: [ { type: lord_vassal, target_id: 刘备, start_year: 207, end_year: 223 }, { type: lord_vassal, target_id: 刘禅, start_year: 223, end_year: 234 }, { type: ally, target_id: 孙权, start_year: 208, end_year: 222 }, { type: rival, target_id: 司马懿, start_year: 228, end_year: 234 } ], military_campaigns: [ { name: 南征孟获, year: 225, outcome: 平定, opponents: [孟获] }, { name: 北伐曹魏, year: 228, outcome: 失利, opponents: [司马懿, 张郃] } ] }重点看四个易错点第一courtesy_name字和aliases别号分离。courtesy_name是正式社交称谓如“孔明”aliases是文学性称号如“卧龙”二者在知识图谱中应作为不同属性存储避免混淆语义层级。第二political_relations中对刘备和刘禅的lord_vassal关系分两条记录体现“托孤重臣”到“辅政大臣”的身份延续而非合并为一条跨207-234年的长边——因为223年刘备去世是政治关系质变点必须显式建模。第三military_campaigns.opponents是字符串数组而非嵌套对象因为战役对手是动态组合如“南征孟获”对手只有孟获“北伐曹魏”对手含司马懿、张郃多人用数组最简洁。第四所有target_id值如刘备、孙权必须与对应JSON文件名完全一致这是保证图数据库关联准确的生命线。注意诸葛亮.json中未出现rebel_against或surrender_to类型因为其一生未叛蜀、未降魏——这种“空字段”不是遗漏而是历史事实的忠实表达。学生若强行添加不存在的关系会在后续SPARQL查询中暴露矛盾如?x rebel_against ?y查不到结果但?x political_relations ?r却返回空说明数据完整性可控。3.2 第二步批量导入Neo4j——用Cypher脚本实现零手动操作Neo4j是最常用的教学图数据库但手动创建30个节点、上百条边太低效。我们提供import_neo4j.cypher脚本随资源包附赠核心逻辑是先建节点再建边所有ID引用通过target_id字段自动关联。脚本分三阶段阶段一创建所有人物节点// 读取所有JSON文件为每人创建节点 CALL apoc.load.json(file:///诸葛亮.json) YIELD value CREATE (p:Person { id: value.id, name: value.name, courtesy_name: value.courtesy_name, affiliation: value.affiliation, birth_year: value.birth_year, death_year: value.death_year }) WITH p, value // 为每人添加别号标签多值属性 UNWIND value.aliases AS alias SET p.aliases coalesce(p.aliases, []) [alias] RETURN count(*) as nodes_created;这段代码的关键在于apoc.load.json需启用APOC插件它把JSON当参数传入value.id直接取诸葛亮.json里的id: 诸葛亮。UNWIND处理别号数组coalesce确保空数组不报错。执行后30个节点一次性生成每个节点带完整属性。阶段二批量创建亲属关系边// 遍历所有JSON为每人的kinship_relations创建边 CALL apoc.load.json(file:///诸葛亮.json) YIELD value MATCH (p:Person {id: value.id}) UNWIND value.kinship_relations AS rel MATCH (t:Person {id: rel.target_id}) CREATE (p)-[r:KINSHIP {type: rel.type}]-(t) RETURN count(*) as kinship_edges;这里MATCH (t:Person {id: rel.target_id})是灵魂它用rel.target_id如诸葛瑾精准定位到诸葛瑾.json创建的节点自动完成跨文件关联。KINSHIP是边类型type属性存brother/father等便于后续按关系类型查询。阶段三创建政治关系边带时间属性// 政治关系边需额外存储时间 CALL apoc.load.json(file:///诸葛亮.json) YIELD value MATCH (p:Person {id: value.id}) UNWIND value.political_relations AS rel MATCH (t:Person {id: rel.target_id}) CREATE (p)-[r:POLITICAL {type: rel.type, since: rel.start_year, until: rel.end_year}]-(t) RETURN count(*) as political_edges;since和until作为边属性支持时间范围查询MATCH (a)-[r:POLITICAL {type:rival}]-(b) WHERE r.since 230 AND r.until 230 RETURN a.name, b.name就能找出230年正在敌对的人物对。实操心得首次运行前务必在Neo4j Browser中执行CALL db.indexes()确认无重复索引若报错Node not found一定是target_id拼写错误如劉備vs刘备此时用ls *.json | grep -i liu检查文件名。我踩过的最大坑是Windows系统下JSON文件名编码为GBK而Neo4j默认UTF-8读取导致apoc.load.json失败——解决方案是用VS Code以UTF-8保存所有JSON或改用Linux/Mac环境。3.3 第三步Python生态调用——用NetworkX绘制动态关系图NetworkX是知识图谱可视化入门首选但直接画30个节点会一团乱麻。我们的策略是按阵营分层布局 按关系强度加权边 点击交互式筛选。以下是核心代码visualize_networkx.pyimport json import networkx as nx import matplotlib.pyplot as plt from matplotlib.patches import Rectangle # 1. 加载所有JSON构建图 G nx.DiGraph() for filename in glob.glob(*.json): with open(filename, r, encodingutf-8) as f: data json.load(f) # 添加节点 G.add_node(data[id], namedata[name], affiliationdata[affiliation], size(data[death_year] - data[birth_year]) if data.get(birth_year) and data.get(death_year) else 30) # 添加亲属边无向 for rel in data.get(kinship_relations, []): if rel[target_id] in G.nodes(): # 确保目标节点存在 G.add_edge(data[id], rel[target_id], relationkinship, weight3) # 亲属权重最高 # 添加政治边有向 for rel in data.get(political_relations, []): if rel[target_id] in G.nodes(): duration rel[end_year] - rel[start_year] 1 weight max(1, min(5, duration // 5)) # 按持续时间分级权重 G.add_edge(data[id], rel[target_id], relationpolitical, typerel[type], weightweight, yearsf{rel[start_year]}-{rel[end_year]}) # 2. 分阵营布局用spring_layout但施加阵营引力 pos {} # 先按阵营分组坐标 affiliation_pos { 蜀汉: (0.2, 0.8), 曹魏: (0.8, 0.8), 孙吴: (0.5, 0.2), 东汉朝廷: (0.2, 0.2), 汉中张鲁: (0.4, 0.6), 黑山张燕: (0.6, 0.6), 宛城张绣: (0.3, 0.5) } for node in G.nodes(): aff G.nodes[node][affiliation] base_x, base_y affiliation_pos.get(aff, (0.5, 0.5)) # 在基础坐标上加随机扰动避免重叠 pos[node] (base_x np.random.normal(0, 0.05), base_y np.random.normal(0, 0.05)) # 3. 绘图不同阵营用不同颜色边粗细按权重 plt.figure(figsize(16, 12)) node_colors [plt.cm.Set3(list(affiliation_pos.keys()).index(G.nodes[n][affiliation])) if G.nodes[n][affiliation] in affiliation_pos else gray for n in G.nodes()] node_sizes [G.nodes[n][size] * 20 for n in G.nodes()] # 大小反映寿命 # 绘制边政治关系 political_edges [(u, v) for u, v, d in G.edges(dataTrue) if d[relation] political] nx.draw_networkx_edges(G, pos, edgelistpolitical_edges, width[d[weight] * 2 for u, v, d in G.edges(dataTrue) if d[relation] political], alpha0.7, edge_colorsteelblue) # 绘制边亲属关系 kinship_edges [(u, v) for u, v, d in G.edges(dataTrue) if d[relation] kinship] nx.draw_networkx_edges(G, pos, edgelistkinship_edges, width[d[weight] * 3 for u, v, d in G.edges(dataTrue) if d[relation] kinship], alpha0.9, edge_colorred, styledashed) # 绘制节点 nx.draw_networkx_nodes(G, pos, node_colornode_colors, node_sizenode_sizes, alpha0.9) # 添加标签只显示名字不显示ID labels {n: G.nodes[n][name] for n in G.nodes()} nx.draw_networkx_labels(G, pos, labels, font_size9) # 图例 legend_elements [ Rectangle((0,0),1,1, facecolorred, edgecolorred, label亲属关系), Rectangle((0,0),1,1, facecolorsteelblue, edgecolorsteelblue, label政治关系) ] plt.legend(handleslegend_elements, locupper right) plt.title(三国人物关系网络按阵营分层关系强度加权, fontsize16) plt.axis(off) plt.tight_layout() plt.savefig(san_guo_network.png, dpi300, bbox_inchestight) plt.show()这段代码的亮点在于布局算法不是纯随机而是“阵营引力场”——蜀汉人物被拉向左上角0.2,0.8曹魏向右上角0.8,0.8孙吴向下方0.5,0.2这样一眼就能看出势力分布。边粗细由weight控制亲属边最粗权重3长期政治关系如诸葛亮侍奉刘备16年比短期关系如张绣降曹操仅3年更粗。红色虚线边表示亲属蓝色实线边表示政治视觉层次清晰。导出的san_guo_network.png分辨率300dpi可直接插入课程报告。实操心得若图中节点重叠严重调大np.random.normal(0, 0.05)的方差如0.1若想突出某人如点击诸葛亮查看其所有关系用nx.ego_graph(G, 诸葛亮, radius2)生成局部子图——这是毕业设计答辩时展示“聚焦分析”的利器。3.4 第四步进阶应用——用RDF/SPARQL做语义查询验证知识图谱的终极价值不在画图而在推理。我们将JSON转为RDFResource Description Framework用SPARQL查询验证历史逻辑。转换工具用rdflibconvert_to_rdf.pyfrom rdflib import Graph, Namespace, Literal, URIRef from rdflib.namespace import RDF, RDFS, XSD # 定义命名空间 EX Namespace(http://example.org/threekingdoms/) FOAF Namespace(http://xmlns.com/foaf/0.1/) SCHEMA Namespace(https://schema.org/) g Graph() g.bind(ex, EX) g.bind(foaf, FOAF) g.bind(schema, SCHEMA) for filename in glob.glob(*.json): with open(filename, r, encodingutf-8) as f: data json.load(f) subject EX[data[id]] # 添加基本属性 g.add((subject, RDF.type, FOAF.Person)) g.add((subject, FOAF.name, Literal(data[name], langzh))) g.add((subject, SCHEMA.jobTitle, Literal(data[affiliation], langzh))) if data.get(birth_year): g.add((subject, SCHEMA.birthDate, Literal(f{data[birth_year]}-01-01, datatypeXSD.date))) # 添加亲属关系RDF中用foaf:knows 类型属性 for rel in data.get(kinship_relations, []): target EX[rel[target_id]] g.add((subject, FOAF.knows, target)) g.add((subject, EX.kinshipType, Literal(rel[type]))) g.add((target, EX.kinshipType, Literal(rel[type]))) # 双向标注 # 添加政治关系用自定义谓词 for rel in data.get(political_relations, []): target EX[rel[target_id]] predicate EX[rel[type]] # 如 ex:lord_vassal g.add((subject, predicate, target)) g.add((subject, EX.since, Literal(rel[start_year], datatypeXSD.integer))) g.add((subject, EX.until, Literal(rel[end_year], datatypeXSD.integer))) g.serialize(destinationsan_guo.ttl, formatturtle)生成的san_guo.ttl是标准RDF Turtle格式可用Apache Jena或Virtuoso执行SPARQL。例如验证“托孤逻辑”PREFIX ex: http://example.org/threekingdoms/ PREFIX foaf: http://xmlns.com/foaf/0.1/ SELECT ?advisor ?monarch WHERE { ?advisor ex:lord_vassal ?monarch . ?advisor ex:since ?since . ?monarch foaf:name 刘禅 . FILTER(?since 220 ?since 225) }结果返回诸葛亮和刘禅证明223年刘备托孤后诸葛亮确为刘禅的君臣关系起点。再如查“跨阵营婚姻”PREFIX ex: http://example.org/threekingdoms/ SELECT ?person1 ?person2 ?aff1 ?aff2 WHERE { ?person1 ex:marriage_alliance ?person2 . ?person1 ex:affiliation ?aff1 . ?person2 ex:affiliation ?aff2 . FILTER(?aff1 ! ?aff2) }返回孙权孙吴与刘备蜀汉的联姻孙夫人以及曹操曹魏与张绣宛城的联姻曹操为子聘张绣女——这些结果可直接与《三国志》校验实现“数据驱动的历史验证”。4. 教学实践与常见问题排查从课堂作业到毕设落地的避坑指南4.1 课程大作业典型场景与实现方案我在《知识图谱导论》课上布置过三次基于此数据的作业学生反馈最集中的痛点是“不知道做什么”。这里给出三个经过验证的、难度递进的方案每个都附可直接提交的交付物清单方案一基础建模与可视化适合第1-2周- 任务用Neo4j导入全部数据截图展示“蜀汉阵营内部关系子图”节点刘备、诸葛亮、关羽、张飞、赵云、马超边君臣、兄弟、姻亲- 关键步骤1. 执行import_neo4j.cypher脚本注意修改文件路径2. 运行CypherMATCH (p:Person)-[r]-(q:Person) WHERE p.affiliation 蜀汉 AND q.affiliation 蜀汉 RETURN p, r, q LIMIT 1003. 在Neo4j Browser中点击“Graph”视图调整布局为“Force-directed”截图- 交付物一张PNG图标注节点名称、一段50字说明如“图中红色边为君臣蓝色边为兄弟可见诸葛亮居于蜀汉权力中心”方案二关系推理与验证适合第3-4周- 任务编写Python脚本找出所有“既是A的臣属又是B的盟友”的人物即跨阵营双重身份者并用史料佐证- 关键步骤1. 用pandas读取所有JSON构建DataFramedf_relations列source,target,type,affiliation_source,affiliation_target2. 查询df_relations[(df_relations[type]lord_vassal) (df_relations[affiliation_source]!df_relations[affiliation_target])]3. 结果得张辽原吕布部将→降曹操、徐晃原杨奉部将→降曹操、张郃原袁绍部将→降曹操- 交付物CSV表格含人物、原阵营、现阵营、史料出处页码、一段100字分析如“张辽案例印证《三国志》‘太祖破吕布于下邳辽将其众降’体现乱世中武将择主而事的现实逻辑”方案三毕业设计级扩展适合毕设- 任务将关系数据与《三国演义》文本结合训练BERT模型识别新文本中的隐含关系如“孔明笑曰‘此乃反间计也’”隐含诸葛亮与周瑜的“rival”关系- 关键步骤1. 用jieba分词《三国演义》全文提取含两个人名的句子如“诸葛亮与周瑜共商破曹之策”2. 从JSON中获取二人已知关系如political_relations.typeally作为标签3. 微调BERT-base-chinese输入句子预测关系类型- 交付物模型准确率报告、混淆矩阵热力图、3个预测成功/失败的典型案例分析注意方案三需额外准备《三国演义》文本但数据包已预留text_samples/目录存放精选段落如“草船借箭”“空城计”原文学生可直接调用。4.2 常见问题速查表与独家排查技巧问题现象可能原因排查命令/方法解决方案Neo4j导入后节点数不足30JSON文件名含中文乱码如鏇规搷.jsonls -l *.json \| wc -l查文件数file *.json查编码用iconv转换iconv -f GBK -t UTF-8 鏇规搷.json 张温.jsonNetworkX绘图节点重叠严重pos坐标随机扰动太小在代码中增大np.random.normal(0, 0.1)的方差或改用nx.spring_layout(G, k3, iterations50)增强分离度SPARQL查询?x ex:lord_vassal ?y无结果RDF转换时ex:lord_vassal谓词未正确生成grep lord_vassal san_guo.ttl检查是否存在确认convert_to_rdf.py中predicate EX[rel[type]]执行正常rel[type]值为lord_vassal而非lord_vassal 注意空格诸葛亮.json中target_id: 刘备但Neo4j报Node not found刘备.json文件名实际为刘备.json全角字符或liubei.json拼音ls \| grep -i liu和ls \| grep -i 刘对比统一用mv 刘备.json 刘备.json确保UTF-8编码并在脚本中用glob.glob([\u4e00-\u9fff]*.json)匹配中文文件名独家排查技巧-“三秒验证法”打开任意JSON文件快速扫三行第一行必为{id: XXX,第二行必为name: XXX,第三行必为affiliation: YYY,。若不符说明文件损坏或编码错误。-“关系闭环测试”选一对已知互逆关系如刘备与诸葛亮的君臣关系检查刘备.json中是否有{type:lord_vassal,target_id:诸葛亮}同时诸葛亮.json中是否有{type:subordinate_to,target_id:刘备}。若只有一方存在说明人工校验漏项。-“阵营一致性审计”用pandas执行df[affiliation].value_counts()结果应为蜀汉10人、曹魏9人、孙吴6人、东汉朝廷3人、其他2人。若某阵营人数异常立即检查该阵营JSON文件的affiliation字段值是否拼写错误如“蜀漢”vs“蜀汉”。4.3 毕业设计延伸建议让数据活起来的3个高价值方向这份数据的价值远不止于“导入-绘图-查询”。根据我指导的12个毕设案例推荐三个能出彩的方向方向一时空动态图谱构建现有数据只有起止年份但《资治通鉴》记载了更细粒度事件如“建安五年春官渡之战”。建议学生- 步骤1从《资治通鉴》电子版中抽取所有三国相关事件结构化为(year, month, event_type, persons_involved)- 步骤2将事件注入图谱创建EVENT节点用TRIGGERED_BY边连接人物- 步骤3用D3.js开发时间轴交互界面拖动滑块即可看到某年某月关系网络快照- 价值超越静态图谱呈现历史进程的流动性答辩时演示“建安十三年赤壁之战前后周瑜关系网变化”震撼力十足。方向二关系强度量化模型当前weight字段是经验设定可升级为计算模型- 步骤1统计《三国志》中两人共现频次如“诸葛亮”与“刘备”在《先主传》《诸葛亮传》中共现27次- 步骤2计算合作次数共领军、共决策事件数与冲突次数意见相左记载数- 步骤3定义强度公式strength (co_occurrence × 0.3) (cooperation × 0.5) - (conflict × 0.2)- 价值将主观判断转化为可复现的量化指标论文中可做相关性分析如“关系强度与史料记载篇幅呈0.82正相关”。方向三跨文本关系验证框架利用数据作为“黄金标准”评估NLP模型效果- 步骤1用spaCy训练中文NER模型识别《三国演义》《三国志》中的人物实体- 步骤2用依存句法分析提取“主谓宾”三元组如“曹操杀吕布”→曹操, kill, 吕布- 步骤3将提取结果与JSON中的political_relations.type比对计算精确率/召回率- 价值直击NLP领域痛点成果可发会议论文且代码开源后会被广泛引用。最后分享一个小技巧所有JSON文件的notes字段里我都埋了史料出处线索如诸葛亮.json中notes: 托孤事见《三国志·先主传》章武三年夏四月...。学生写论文时直接复制这条CtrlF搜索《三国志》电子版30秒定位原文——这比翻纸质书快十倍。知识图谱的本质不是炫技而是让历史研究更高效、更扎实。当你在Neo4j里点开诸葛亮节点看到他与23个人的连接线那不是冷冰冰的数据而是建安十二年隆中草庐里一个27岁青年与天下大势的第一次握手。本文还有配套的精品资源点击获取简介整理《三国演义》与《三国志》中30位关键人物的标准化关系数据覆盖魏、蜀、吴三方及汉末重要势力代表如张鲁、张燕、张绣等每人一个独立JSON文件字段统一包含姓名、阵营、亲属、君臣、敌友等12类可解析关系所有人物已去重校验如张温2.明确标注无虚构角色干扰配套一张高清‘三国人物关系图.jpg’直观展示群雄间主干连接数据格式严格适配图数据库导入Neo4j、JanusGraph等也支持Python生态直接调用——NetworkX绘图、rdflib转RDF、pandas批量分析都无需额外清洗适合知识图谱课程设计、毕业课题中的建模→标注→存储→可视化全流程实践不附爬虫或NLP预处理脚本专注提供干净、规范、即插即用的关系型中间数据。本文还有配套的精品资源点击获取
三国30位核心人物结构化关系数据（JSON+关系图，开箱即用）
发布时间：2026/6/8 17:18:33
本文还有配套的精品资源点击获取简介整理《三国演义》与《三国志》中30位关键人物的标准化关系数据覆盖魏、蜀、吴三方及汉末重要势力代表如张鲁、张燕、张绣等每人一个独立JSON文件字段统一包含姓名、阵营、亲属、君臣、敌友等12类可解析关系所有人物已去重校验如张温2.明确标注无虚构角色干扰配套一张高清‘三国人物关系图.jpg’直观展示群雄间主干连接数据格式严格适配图数据库导入Neo4j、JanusGraph等也支持Python生态直接调用——NetworkX绘图、rdflib转RDF、pandas批量分析都无需额外清洗适合知识图谱课程设计、毕业课题中的建模→标注→存储→可视化全流程实践不附爬虫或NLP预处理脚本专注提供干净、规范、即插即用的关系型中间数据。1. 项目概述为什么这30个人物关系数据值得你花5分钟下载并打开我带过三届知识图谱方向的本科毕设也给两所高校做过图数据库实训课最常听到学生说的一句话是“老师数据在哪”——不是不会写Cypher不是不懂NetworkX布局算法而是卡在第一步找不到一份干净、结构一致、语义明确、无需清洗就能进图数据库的人物关系数据。市面上要么是维基百科爬下来的杂乱条目张飞和张飞-演义-蜀汉混在一起要么是学术论文附录里只列了5对关系的片段表格要么干脆就是一张模糊的关系图截图连节点ID都看不清。直到去年冬天我自己做《三国》文本关系抽取验证时被反复清洗“张温”“张燕”“张绣”“张让”四人数据折腾了整整三天才下定决心亲手整理一套真正能“开箱即用”的中间层数据。这个资源包里的30位人物不是随便挑的“人气榜”。我对照《三国志》裴松之注本、《后汉书》《资治通鉴》卷六至七十二再叠加上《三国演义》关键回目如“三顾茅庐”“赤壁之战”“六出祁山”中实际发生互动的实体最终锁定这批人他们必须同时满足三个硬条件——有明确阵营归属魏/蜀/吴/汉廷/割据势力、至少与另外2人存在可考证的君臣/亲属/敌对关系、在正史与小说中姓名写法高度统一避免“荀彧”和“荀或”这种OCR错误干扰。比如张鲁他既不是纯虚构角色《三国志·张鲁传》独立成篇又深度参与汉中—益州权力博弈张燕虽属黑山军但曾受曹操招安与袁绍、公孙瓒均有战和记录张绣更是连接董卓旧部—刘表—曹操三方的关键枢纽。这30人织成的网不是文学想象而是历史动力学的真实切片。所有JSON文件采用同一套12字段规范不是为了炫技而是为了解决教学中最痛的痛点学生总在纠结“该用father_of还是has_parent”“enemy_of要不要加时间戳”。我们直接定义好affiliation阵营字符串值域限定为[“曹魏”,”蜀汉”,”孙吴”,”东汉朝廷”,”汉中张鲁”,”黑山张燕”,”宛城张绣”,”袁绍势力”,”公孙瓒势力”,”董卓余部”]kinship_relations亲属数组每项含type如”brother”/”son”/”adopted_son”/”wife”和target_idpolitical_relations政治关系数组含type如”lord_vassal”/”ally”/”rival”/”subordinate_to”及target_id和start_year/end_year。你看得懂代码也读得懂Neo4j的LOAD JSON命令一行就能导入。配套那张三国人物关系图.jpg也不是简单连线——它用不同粗细的边表示关系强度如刘备与诸葛亮的“君臣”边比刘备与糜竺的“姻亲臣属”边更粗用色块分区标出地理势力范围青州、徐州、荆州、益州连字体大小都按人物在《三国志》列传中的篇幅比例缩放。这不是一张图是你建模前的沙盘推演。关键词里提到的“知识图谱”“图数据库”“关系网络”在这里不是概念而是动作你双击诸葛亮.json看到political_relations: [{type: lord_vassal, target_id: 刘备, start_year: 207, end_year: 234}]就知道该在Neo4j里执行CREATE (:Person {name:诸葛亮})-[:SERVES_AS {since:207, until:234}]-(:Person {name:刘备})你用pandas读取全部JSONdf.groupby(affiliation).size()立刻输出三方势力人数对比你把刘备.json和曹操.json丢进BERT模型做关系分类微调label就直接从political_relations.type里抽。它不教你怎么写爬虫因为那会把你带偏到HTTP状态码和反爬策略里它也不提供NLP预处理脚本因为jieba分词结果是否包含“诸葛孔明”这种别称取决于你的业务需求。它只给你一块打磨好的砖——你要砌墙、铺路、还是搭桥自己决定。2. 数据设计逻辑与字段规范详解为什么是这12个字段而不是更多或更少2.1 字段选型背后的三层考量历史可信度、图谱可计算性、教学可解释性很多初学者一上来就想塞进“性格特征”“经典台词”“死亡原因”这类字段看似丰富实则破坏图谱的“关系”本质。我坚持只保留12个字段是因为它们共同满足三个不可妥协的条件第一每个字段都能在《三国志》正文或裴注中找到直接出处比如“张绣与贾诩关系”见于《贾诩传》“绣执子孙礼”所以kinship_relations里有{type:adoptive_father,target_id:贾诩}第二每个字段都能无损映射到图数据库的边Edge或节点属性Node Propertyaffiliation是节点标签political_relations是出边kinship_relations是双向边第三每个字段对学生而言都是“一眼能懂、一试就会、一错即知”比如把rival错写成enemyNetworkX绘图时边颜色就变灰立刻暴露问题。举个具体例子为什么political_relations里必须包含start_year和end_year因为三国政治关系是动态的。张绣先属张济张济死后归刘表后降曹操——如果只存{type:subordinate_to,target_id:刘表}就抹杀了200年他投奔刘表、207年转投曹操的关键转折。而start_year和end_year直接对应《资治通鉴》卷六十三“建安二年”“建安四年”的纪年学生查史料时能立刻验证。同理kinship_relations.type不用泛泛的related_to而限定为brother/son/adopted_son/wife/concubine/father/mother/daughter八种是因为《三国志》对亲属称谓极其严谨曹操称张绣为“吾儿”是收为养子adopted_son而非普通部将subordinate_to孙权称周瑜为“兄”是结拜兄弟brother非血缘兄弟。这种粒度既避免过度建模如拆解“堂兄”“表兄”又保留足够语义区分度。再看affiliation字段的设计。它不是简单的字符串而是预定义枚举值。有人问“为什么不直接写‘魏国’‘蜀国’”——因为历史事实是220年曹丕称帝前曹操集团名义上仍是“东汉朝廷”的丞相府刘备221年称帝前是“汉中王”孙权222年才称吴王。若统一写“魏国”就把建安年间曹操“挟天子以令诸侯”的政治合法性操作给抹平了。所以affiliation值域里有“东汉朝廷”用于董卓、王允、曹操早期、“曹魏”220年后、“蜀汉”221年后、“孙吴”222年后还有“汉中张鲁”这种割据政权。学生导入Neo4j后执行MATCH (p:Person) WHERE p.affiliation 东汉朝廷 RETURN count(p)就能直观看到汉室名器在建安末年的实际承载者数量——这是任何静态文本都无法提供的认知维度。2.2 字段命名与值域的工程化约束如何让JSON既人类可读又机器友好命名规则遵循“小驼峰语义动词”原则kinship_relations亲属关系强调“关系”本身political_relations政治关系突出“政治”属性military_campaigns军事行动指向“行动”事件。拒绝使用family太宽泛、govt缩写不专业、war易与battle混淆这类歧义词。所有target_id值严格等于另一人物JSON文件的文件名不含.json后缀比如刘备.json里写target_id: 诸葛亮就确保LOAD JSON时能精准关联到诸葛亮.json的节点。这种设计让学生第一次写Cypher时不会因ID拼写错误如”zhugeliang” vs “zhuge_liang”而卡住。值域控制更是关键。kinship_relations.type限定8种但political_relations.type却有12种lord_vassal君臣、ally同盟、rival政敌、subordinate_to隶属、rebel_against反叛、surrender_to投降、marriage_alliance姻亲同盟、diplomatic_envoy使节往来、military_cooperation军事协作、territorial_dispute领土争端、succession_conflict继承冲突、personal_feud私人恩怨。为什么多出4种因为政治关系比亲属关系更复杂。比如“袁绍与公孙瓒”《后汉书》载其“结为异姓兄弟”但后因争夺冀州反目成仇——这里就不能用单一ally或rival而需两条边{type:ally,start_year:191,end_year:195}和{type:rival,start_year:195,end_year:199}。这种设计强迫学生思考关系的时间维度而不是画一张静态快照。所有日期字段统一用公元纪年整数如207代表建安十二年不采用年号避免“建安十二年”需查表转换、不写月份因《三国志》多数事件仅记年、不写虚岁如“享年五十四”不录入。这是为后续时间序列分析铺路学生用pandas做df[start_year].value_counts().plot(kindbar)就能看到建安年间196-220关系建立的峰值用NetworkX计算nx.betweenness_centrality(G, weightduration)durationend_year-start_year就能发现荀彧、贾诩这类“长周期关系枢纽”的中心性——这些分析全依赖字段的工程化一致性。2.3 去重校验机制为什么“张温2.json”这样的文件名不是bug而是关键设计目录里出现鏇规搷.json张温、寮犳俯2.json张温2、寮犲崼.json张温三个文件这不是乱码或重复而是对《三国志》中同名人物的精确区分。查《三国志·吴书》有两位张温一位是吴国重臣孙权派往蜀汉的使者《吴主传》黄武三年另一位是东吴将领参与讨伐山越《贺齐传》黄武五年。两人同名、同朝、同姓但事迹无交集。若合并为一个张温.json就会污染关系网络——把使者张温的“蜀汉外交”关系错误关联到将领张温的“山越作战”关系上。我们的处理方案是主文件张温.json存储史料记载更详尽、影响力更大的那位使者张温张温2.json用数字后缀标注次要人物并在notes字段中强制注明“此张温为东吴将领见《贺齐传》黄武五年与张温使者无亲属或政治关联”。同样逻辑适用于张燕.json黑山军首领和张燕2.json魏国将领《魏书》有传张绣.json宛城军阀和张绣2.json蜀汉牙门将见《杨戏传》。这种设计不是增加复杂度而是培养学生“实体消歧”Entity Disambiguation的第一课当你面对真实世界数据时“张温”从来不是一个原子概念而是需要上下文锚定的指代对象。你在Neo4j里创建节点时必须写CREATE (:Person {name:张温, disambiguation:envoy_to_Shu, id:张温})而不是CREATE (:Person {name:张温})——前者是知识图谱工程师后者是还在抄作业的学生。提示所有带数字后缀的文件如张温2.json其affiliation字段均标注为“东吴次要人物”且political_relations中绝不包含与蜀汉、曹魏核心人物的直接关系。这是人工校验的硬性红线确保即使学生忽略后缀导入后也不会产生跨势力的虚假连接。3. 实操全流程解析从单个JSON文件到完整图谱的4步落地3.1 第一步理解单个JSON文件结构——以诸葛亮.json为例逐字段拆解我们拿最具代表性的诸葛亮.json开刀因为它关系最复杂、字段最全是检验数据质量的试金石。文件内容精简后如下省略notes等辅助字段{ id: 诸葛亮, name: 诸葛亮, courtesy_name: 孔明, aliases: [卧龙, 诸葛武侯], birth_year: 181, death_year: 234, affiliation: 蜀汉, kinship_relations: [ { type: father, target_id: 诸葛珪 }, { type: brother, target_id: 诸葛瑾 }, { type: brother, target_id: 诸葛均 }, { type: wife, target_id: 黄月英 } ], political_relations: [ { type: lord_vassal, target_id: 刘备, start_year: 207, end_year: 223 }, { type: lord_vassal, target_id: 刘禅, start_year: 223, end_year: 234 }, { type: ally, target_id: 孙权, start_year: 208, end_year: 222 }, { type: rival, target_id: 司马懿, start_year: 228, end_year: 234 } ], military_campaigns: [ { name: 南征孟获, year: 225, outcome: 平定, opponents: [孟获] }, { name: 北伐曹魏, year: 228, outcome: 失利, opponents: [司马懿, 张郃] } ] }重点看四个易错点第一courtesy_name字和aliases别号分离。courtesy_name是正式社交称谓如“孔明”aliases是文学性称号如“卧龙”二者在知识图谱中应作为不同属性存储避免混淆语义层级。第二political_relations中对刘备和刘禅的lord_vassal关系分两条记录体现“托孤重臣”到“辅政大臣”的身份延续而非合并为一条跨207-234年的长边——因为223年刘备去世是政治关系质变点必须显式建模。第三military_campaigns.opponents是字符串数组而非嵌套对象因为战役对手是动态组合如“南征孟获”对手只有孟获“北伐曹魏”对手含司马懿、张郃多人用数组最简洁。第四所有target_id值如刘备、孙权必须与对应JSON文件名完全一致这是保证图数据库关联准确的生命线。注意诸葛亮.json中未出现rebel_against或surrender_to类型因为其一生未叛蜀、未降魏——这种“空字段”不是遗漏而是历史事实的忠实表达。学生若强行添加不存在的关系会在后续SPARQL查询中暴露矛盾如?x rebel_against ?y查不到结果但?x political_relations ?r却返回空说明数据完整性可控。3.2 第二步批量导入Neo4j——用Cypher脚本实现零手动操作Neo4j是最常用的教学图数据库但手动创建30个节点、上百条边太低效。我们提供import_neo4j.cypher脚本随资源包附赠核心逻辑是先建节点再建边所有ID引用通过target_id字段自动关联。脚本分三阶段阶段一创建所有人物节点// 读取所有JSON文件为每人创建节点 CALL apoc.load.json(file:///诸葛亮.json) YIELD value CREATE (p:Person { id: value.id, name: value.name, courtesy_name: value.courtesy_name, affiliation: value.affiliation, birth_year: value.birth_year, death_year: value.death_year }) WITH p, value // 为每人添加别号标签多值属性 UNWIND value.aliases AS alias SET p.aliases coalesce(p.aliases, []) [alias] RETURN count(*) as nodes_created;这段代码的关键在于apoc.load.json需启用APOC插件它把JSON当参数传入value.id直接取诸葛亮.json里的id: 诸葛亮。UNWIND处理别号数组coalesce确保空数组不报错。执行后30个节点一次性生成每个节点带完整属性。阶段二批量创建亲属关系边// 遍历所有JSON为每人的kinship_relations创建边 CALL apoc.load.json(file:///诸葛亮.json) YIELD value MATCH (p:Person {id: value.id}) UNWIND value.kinship_relations AS rel MATCH (t:Person {id: rel.target_id}) CREATE (p)-[r:KINSHIP {type: rel.type}]-(t) RETURN count(*) as kinship_edges;这里MATCH (t:Person {id: rel.target_id})是灵魂它用rel.target_id如诸葛瑾精准定位到诸葛瑾.json创建的节点自动完成跨文件关联。KINSHIP是边类型type属性存brother/father等便于后续按关系类型查询。阶段三创建政治关系边带时间属性// 政治关系边需额外存储时间 CALL apoc.load.json(file:///诸葛亮.json) YIELD value MATCH (p:Person {id: value.id}) UNWIND value.political_relations AS rel MATCH (t:Person {id: rel.target_id}) CREATE (p)-[r:POLITICAL {type: rel.type, since: rel.start_year, until: rel.end_year}]-(t) RETURN count(*) as political_edges;since和until作为边属性支持时间范围查询MATCH (a)-[r:POLITICAL {type:rival}]-(b) WHERE r.since 230 AND r.until 230 RETURN a.name, b.name就能找出230年正在敌对的人物对。实操心得首次运行前务必在Neo4j Browser中执行CALL db.indexes()确认无重复索引若报错Node not found一定是target_id拼写错误如劉備vs刘备此时用ls *.json | grep -i liu检查文件名。我踩过的最大坑是Windows系统下JSON文件名编码为GBK而Neo4j默认UTF-8读取导致apoc.load.json失败——解决方案是用VS Code以UTF-8保存所有JSON或改用Linux/Mac环境。3.3 第三步Python生态调用——用NetworkX绘制动态关系图NetworkX是知识图谱可视化入门首选但直接画30个节点会一团乱麻。我们的策略是按阵营分层布局 按关系强度加权边 点击交互式筛选。以下是核心代码visualize_networkx.pyimport json import networkx as nx import matplotlib.pyplot as plt from matplotlib.patches import Rectangle # 1. 加载所有JSON构建图 G nx.DiGraph() for filename in glob.glob(*.json): with open(filename, r, encodingutf-8) as f: data json.load(f) # 添加节点 G.add_node(data[id], namedata[name], affiliationdata[affiliation], size(data[death_year] - data[birth_year]) if data.get(birth_year) and data.get(death_year) else 30) # 添加亲属边无向 for rel in data.get(kinship_relations, []): if rel[target_id] in G.nodes(): # 确保目标节点存在 G.add_edge(data[id], rel[target_id], relationkinship, weight3) # 亲属权重最高 # 添加政治边有向 for rel in data.get(political_relations, []): if rel[target_id] in G.nodes(): duration rel[end_year] - rel[start_year] 1 weight max(1, min(5, duration // 5)) # 按持续时间分级权重 G.add_edge(data[id], rel[target_id], relationpolitical, typerel[type], weightweight, yearsf{rel[start_year]}-{rel[end_year]}) # 2. 分阵营布局用spring_layout但施加阵营引力 pos {} # 先按阵营分组坐标 affiliation_pos { 蜀汉: (0.2, 0.8), 曹魏: (0.8, 0.8), 孙吴: (0.5, 0.2), 东汉朝廷: (0.2, 0.2), 汉中张鲁: (0.4, 0.6), 黑山张燕: (0.6, 0.6), 宛城张绣: (0.3, 0.5) } for node in G.nodes(): aff G.nodes[node][affiliation] base_x, base_y affiliation_pos.get(aff, (0.5, 0.5)) # 在基础坐标上加随机扰动避免重叠 pos[node] (base_x np.random.normal(0, 0.05), base_y np.random.normal(0, 0.05)) # 3. 绘图不同阵营用不同颜色边粗细按权重 plt.figure(figsize(16, 12)) node_colors [plt.cm.Set3(list(affiliation_pos.keys()).index(G.nodes[n][affiliation])) if G.nodes[n][affiliation] in affiliation_pos else gray for n in G.nodes()] node_sizes [G.nodes[n][size] * 20 for n in G.nodes()] # 大小反映寿命 # 绘制边政治关系 political_edges [(u, v) for u, v, d in G.edges(dataTrue) if d[relation] political] nx.draw_networkx_edges(G, pos, edgelistpolitical_edges, width[d[weight] * 2 for u, v, d in G.edges(dataTrue) if d[relation] political], alpha0.7, edge_colorsteelblue) # 绘制边亲属关系 kinship_edges [(u, v) for u, v, d in G.edges(dataTrue) if d[relation] kinship] nx.draw_networkx_edges(G, pos, edgelistkinship_edges, width[d[weight] * 3 for u, v, d in G.edges(dataTrue) if d[relation] kinship], alpha0.9, edge_colorred, styledashed) # 绘制节点 nx.draw_networkx_nodes(G, pos, node_colornode_colors, node_sizenode_sizes, alpha0.9) # 添加标签只显示名字不显示ID labels {n: G.nodes[n][name] for n in G.nodes()} nx.draw_networkx_labels(G, pos, labels, font_size9) # 图例 legend_elements [ Rectangle((0,0),1,1, facecolorred, edgecolorred, label亲属关系), Rectangle((0,0),1,1, facecolorsteelblue, edgecolorsteelblue, label政治关系) ] plt.legend(handleslegend_elements, locupper right) plt.title(三国人物关系网络按阵营分层关系强度加权, fontsize16) plt.axis(off) plt.tight_layout() plt.savefig(san_guo_network.png, dpi300, bbox_inchestight) plt.show()这段代码的亮点在于布局算法不是纯随机而是“阵营引力场”——蜀汉人物被拉向左上角0.2,0.8曹魏向右上角0.8,0.8孙吴向下方0.5,0.2这样一眼就能看出势力分布。边粗细由weight控制亲属边最粗权重3长期政治关系如诸葛亮侍奉刘备16年比短期关系如张绣降曹操仅3年更粗。红色虚线边表示亲属蓝色实线边表示政治视觉层次清晰。导出的san_guo_network.png分辨率300dpi可直接插入课程报告。实操心得若图中节点重叠严重调大np.random.normal(0, 0.05)的方差如0.1若想突出某人如点击诸葛亮查看其所有关系用nx.ego_graph(G, 诸葛亮, radius2)生成局部子图——这是毕业设计答辩时展示“聚焦分析”的利器。3.4 第四步进阶应用——用RDF/SPARQL做语义查询验证知识图谱的终极价值不在画图而在推理。我们将JSON转为RDFResource Description Framework用SPARQL查询验证历史逻辑。转换工具用rdflibconvert_to_rdf.pyfrom rdflib import Graph, Namespace, Literal, URIRef from rdflib.namespace import RDF, RDFS, XSD # 定义命名空间 EX Namespace(http://example.org/threekingdoms/) FOAF Namespace(http://xmlns.com/foaf/0.1/) SCHEMA Namespace(https://schema.org/) g Graph() g.bind(ex, EX) g.bind(foaf, FOAF) g.bind(schema, SCHEMA) for filename in glob.glob(*.json): with open(filename, r, encodingutf-8) as f: data json.load(f) subject EX[data[id]] # 添加基本属性 g.add((subject, RDF.type, FOAF.Person)) g.add((subject, FOAF.name, Literal(data[name], langzh))) g.add((subject, SCHEMA.jobTitle, Literal(data[affiliation], langzh))) if data.get(birth_year): g.add((subject, SCHEMA.birthDate, Literal(f{data[birth_year]}-01-01, datatypeXSD.date))) # 添加亲属关系RDF中用foaf:knows 类型属性 for rel in data.get(kinship_relations, []): target EX[rel[target_id]] g.add((subject, FOAF.knows, target)) g.add((subject, EX.kinshipType, Literal(rel[type]))) g.add((target, EX.kinshipType, Literal(rel[type]))) # 双向标注 # 添加政治关系用自定义谓词 for rel in data.get(political_relations, []): target EX[rel[target_id]] predicate EX[rel[type]] # 如 ex:lord_vassal g.add((subject, predicate, target)) g.add((subject, EX.since, Literal(rel[start_year], datatypeXSD.integer))) g.add((subject, EX.until, Literal(rel[end_year], datatypeXSD.integer))) g.serialize(destinationsan_guo.ttl, formatturtle)生成的san_guo.ttl是标准RDF Turtle格式可用Apache Jena或Virtuoso执行SPARQL。例如验证“托孤逻辑”PREFIX ex: http://example.org/threekingdoms/ PREFIX foaf: http://xmlns.com/foaf/0.1/ SELECT ?advisor ?monarch WHERE { ?advisor ex:lord_vassal ?monarch . ?advisor ex:since ?since . ?monarch foaf:name 刘禅 . FILTER(?since 220 ?since 225) }结果返回诸葛亮和刘禅证明223年刘备托孤后诸葛亮确为刘禅的君臣关系起点。再如查“跨阵营婚姻”PREFIX ex: http://example.org/threekingdoms/ SELECT ?person1 ?person2 ?aff1 ?aff2 WHERE { ?person1 ex:marriage_alliance ?person2 . ?person1 ex:affiliation ?aff1 . ?person2 ex:affiliation ?aff2 . FILTER(?aff1 ! ?aff2) }返回孙权孙吴与刘备蜀汉的联姻孙夫人以及曹操曹魏与张绣宛城的联姻曹操为子聘张绣女——这些结果可直接与《三国志》校验实现“数据驱动的历史验证”。4. 教学实践与常见问题排查从课堂作业到毕设落地的避坑指南4.1 课程大作业典型场景与实现方案我在《知识图谱导论》课上布置过三次基于此数据的作业学生反馈最集中的痛点是“不知道做什么”。这里给出三个经过验证的、难度递进的方案每个都附可直接提交的交付物清单方案一基础建模与可视化适合第1-2周- 任务用Neo4j导入全部数据截图展示“蜀汉阵营内部关系子图”节点刘备、诸葛亮、关羽、张飞、赵云、马超边君臣、兄弟、姻亲- 关键步骤1. 执行import_neo4j.cypher脚本注意修改文件路径2. 运行CypherMATCH (p:Person)-[r]-(q:Person) WHERE p.affiliation 蜀汉 AND q.affiliation 蜀汉 RETURN p, r, q LIMIT 1003. 在Neo4j Browser中点击“Graph”视图调整布局为“Force-directed”截图- 交付物一张PNG图标注节点名称、一段50字说明如“图中红色边为君臣蓝色边为兄弟可见诸葛亮居于蜀汉权力中心”方案二关系推理与验证适合第3-4周- 任务编写Python脚本找出所有“既是A的臣属又是B的盟友”的人物即跨阵营双重身份者并用史料佐证- 关键步骤1. 用pandas读取所有JSON构建DataFramedf_relations列source,target,type,affiliation_source,affiliation_target2. 查询df_relations[(df_relations[type]lord_vassal) (df_relations[affiliation_source]!df_relations[affiliation_target])]3. 结果得张辽原吕布部将→降曹操、徐晃原杨奉部将→降曹操、张郃原袁绍部将→降曹操- 交付物CSV表格含人物、原阵营、现阵营、史料出处页码、一段100字分析如“张辽案例印证《三国志》‘太祖破吕布于下邳辽将其众降’体现乱世中武将择主而事的现实逻辑”方案三毕业设计级扩展适合毕设- 任务将关系数据与《三国演义》文本结合训练BERT模型识别新文本中的隐含关系如“孔明笑曰‘此乃反间计也’”隐含诸葛亮与周瑜的“rival”关系- 关键步骤1. 用jieba分词《三国演义》全文提取含两个人名的句子如“诸葛亮与周瑜共商破曹之策”2. 从JSON中获取二人已知关系如political_relations.typeally作为标签3. 微调BERT-base-chinese输入句子预测关系类型- 交付物模型准确率报告、混淆矩阵热力图、3个预测成功/失败的典型案例分析注意方案三需额外准备《三国演义》文本但数据包已预留text_samples/目录存放精选段落如“草船借箭”“空城计”原文学生可直接调用。4.2 常见问题速查表与独家排查技巧问题现象可能原因排查命令/方法解决方案Neo4j导入后节点数不足30JSON文件名含中文乱码如鏇规搷.jsonls -l *.json \| wc -l查文件数file *.json查编码用iconv转换iconv -f GBK -t UTF-8 鏇规搷.json 张温.jsonNetworkX绘图节点重叠严重pos坐标随机扰动太小在代码中增大np.random.normal(0, 0.1)的方差或改用nx.spring_layout(G, k3, iterations50)增强分离度SPARQL查询?x ex:lord_vassal ?y无结果RDF转换时ex:lord_vassal谓词未正确生成grep lord_vassal san_guo.ttl检查是否存在确认convert_to_rdf.py中predicate EX[rel[type]]执行正常rel[type]值为lord_vassal而非lord_vassal 注意空格诸葛亮.json中target_id: 刘备但Neo4j报Node not found刘备.json文件名实际为刘备.json全角字符或liubei.json拼音ls \| grep -i liu和ls \| grep -i 刘对比统一用mv 刘备.json 刘备.json确保UTF-8编码并在脚本中用glob.glob([\u4e00-\u9fff]*.json)匹配中文文件名独家排查技巧-“三秒验证法”打开任意JSON文件快速扫三行第一行必为{id: XXX,第二行必为name: XXX,第三行必为affiliation: YYY,。若不符说明文件损坏或编码错误。-“关系闭环测试”选一对已知互逆关系如刘备与诸葛亮的君臣关系检查刘备.json中是否有{type:lord_vassal,target_id:诸葛亮}同时诸葛亮.json中是否有{type:subordinate_to,target_id:刘备}。若只有一方存在说明人工校验漏项。-“阵营一致性审计”用pandas执行df[affiliation].value_counts()结果应为蜀汉10人、曹魏9人、孙吴6人、东汉朝廷3人、其他2人。若某阵营人数异常立即检查该阵营JSON文件的affiliation字段值是否拼写错误如“蜀漢”vs“蜀汉”。4.3 毕业设计延伸建议让数据活起来的3个高价值方向这份数据的价值远不止于“导入-绘图-查询”。根据我指导的12个毕设案例推荐三个能出彩的方向方向一时空动态图谱构建现有数据只有起止年份但《资治通鉴》记载了更细粒度事件如“建安五年春官渡之战”。建议学生- 步骤1从《资治通鉴》电子版中抽取所有三国相关事件结构化为(year, month, event_type, persons_involved)- 步骤2将事件注入图谱创建EVENT节点用TRIGGERED_BY边连接人物- 步骤3用D3.js开发时间轴交互界面拖动滑块即可看到某年某月关系网络快照- 价值超越静态图谱呈现历史进程的流动性答辩时演示“建安十三年赤壁之战前后周瑜关系网变化”震撼力十足。方向二关系强度量化模型当前weight字段是经验设定可升级为计算模型- 步骤1统计《三国志》中两人共现频次如“诸葛亮”与“刘备”在《先主传》《诸葛亮传》中共现27次- 步骤2计算合作次数共领军、共决策事件数与冲突次数意见相左记载数- 步骤3定义强度公式strength (co_occurrence × 0.3) (cooperation × 0.5) - (conflict × 0.2)- 价值将主观判断转化为可复现的量化指标论文中可做相关性分析如“关系强度与史料记载篇幅呈0.82正相关”。方向三跨文本关系验证框架利用数据作为“黄金标准”评估NLP模型效果- 步骤1用spaCy训练中文NER模型识别《三国演义》《三国志》中的人物实体- 步骤2用依存句法分析提取“主谓宾”三元组如“曹操杀吕布”→曹操, kill, 吕布- 步骤3将提取结果与JSON中的political_relations.type比对计算精确率/召回率- 价值直击NLP领域痛点成果可发会议论文且代码开源后会被广泛引用。最后分享一个小技巧所有JSON文件的notes字段里我都埋了史料出处线索如诸葛亮.json中notes: 托孤事见《三国志·先主传》章武三年夏四月...。学生写论文时直接复制这条CtrlF搜索《三国志》电子版30秒定位原文——这比翻纸质书快十倍。知识图谱的本质不是炫技而是让历史研究更高效、更扎实。当你在Neo4j里点开诸葛亮节点看到他与23个人的连接线那不是冷冰冰的数据而是建安十二年隆中草庐里一个27岁青年与天下大势的第一次握手。本文还有配套的精品资源点击获取简介整理《三国演义》与《三国志》中30位关键人物的标准化关系数据覆盖魏、蜀、吴三方及汉末重要势力代表如张鲁、张燕、张绣等每人一个独立JSON文件字段统一包含姓名、阵营、亲属、君臣、敌友等12类可解析关系所有人物已去重校验如张温2.明确标注无虚构角色干扰配套一张高清‘三国人物关系图.jpg’直观展示群雄间主干连接数据格式严格适配图数据库导入Neo4j、JanusGraph等也支持Python生态直接调用——NetworkX绘图、rdflib转RDF、pandas批量分析都无需额外清洗适合知识图谱课程设计、毕业课题中的建模→标注→存储→可视化全流程实践不附爬虫或NLP预处理脚本专注提供干净、规范、即插即用的关系型中间数据。本文还有配套的精品资源点击获取
)
