「自描述」的 Neo4j 图数据库(第 2 部分)
#SmartData 元模型子图 (FactMiners 社交游戏生态系统) - 第 2 部分 共 2 部分
作者:Jim Salmons,项目总监 - Softalk Apple Project 和 FactMiners 生态系统
注:我的元模型子图 GraphGists 原稿的第二部分深入探讨了一些可能超出您兴趣水平的图数据库设计相关的“琐碎细节”。如需了解本材料大部分内容的更易读、更适合视频观看的版本,请参阅我在博物馆计算机网络 #MCN2014 会议上演示的 GraphGist 版本:《事实的栖息地:探索 FactMiners 事实云的元模型子图》。
关于 Softalk Apple Project 和 FactMiners 生态系统
在本 GraphGist 系列的第一部分中,我描述了元模型子图设计模式的基础知识,并看了一个非常基础的例子。有了这些基础,我们在这里开始探讨最初激发我开发 FactMiners 生态系统的有趣用例。
Softalk Magazine 于 1980 年 9 月至 1984 年 8 月期间每月出版,共四卷。其 9300 页提供了微型计算机革命早期逐月的宝贵详细编年史。虽然 FactMiners 社交游戏生态系统旨在拥有自己的生命力和影响力,但 FactMiners 和第一个事实云的开发灵感将来自本系列和未来 GraphGists 中描述的那个。我以及许多 Softalk 之友诚邀您了解这本伟大的杂志和 Softalk Apple Project。您可以通过此链接进一步了解我将 FactMiners 生态系统付诸实践的个人“回馈”灵感。
总而言之,创建一个权威的 Softalk Magazine 在线数字档案馆是一个很棒的主意。而“诞生”FactMiners 社交游戏生态系统作为探索此档案馆的工具,将充满乐趣和有趣的挑战。那么,让我们开始吧…
用例:FactMiners 事实云向导
FactMiners 背后的基本思想是利用玩家的游戏精力与兴趣,为拥有在线数字藏品并有兴趣创建事实云(即“自描述”图数据库)作为其在线藏品补充教育和研究资源的博物馆和档案馆,创建一个众包资源。
在 FactMiners 基于角色的玩家世界中,博物馆和档案馆的代表——通常是员工或其他授权代理人——只是 FactMiners 玩家,他们的玩家账户(位于 http://www.FactMiners.com 玩家社区)启用了“事实云所有者/创建者”权限。当博物馆或档案馆准备向其藏品添加事实云时,藏品的玩家将使用游戏应用程序或浏览器启动事实云向导。
就像您以前使用过的向导式设置功能一样,事实云向导是一种基于知识的程序化交互(即一种引导式“对话”UI 设计),通过将其分解为简单的微小决策和分步配置活动,帮助向导用户创建复杂内容。
我们在本 GraphGist 系列第二部分中看到的 Cypher 片段,是以“概念块”的形式呈现的,这些“概念块”将由向导根据引导式增量问题零散地生成和执行。因此,我在这里不再赘述向导交互的细枝末节。我们可以简单地认识到,我们在本 GraphGist 系列第二部分中创建的元模型,可以合理地由未来的事实云向导生成,该向导将是 FactMiners.org 开源开发者社区开发的平台的一部分。(目前只是占位页面… 感兴趣吗?这是本次 gist 之后的下一个“待办事项”!:-) )
Softalk Magazine FactMiners 元模型
在本 GraphGist 系列的第 1 部分中,我介绍了一个最基本的元模型子图,它看起来像第一个图。META 子图只需要节点(Nodes)和关系(Relationships)子集来概念性地组织介绍性示例的元素。
我们的第一步是将 Softalk 杂志的结构大致引入我们的事实云元模型中。您将看到我们如何扩展节点标签技术的使用,以处理我们现实世界、特定领域示例的复杂性增加。
为了将 Softalk Magazine 的结构包含在我们的事实云元模型中,我采用了一种标签命名约定,为我们的元模型组织提供子集包含语义。元模型子图中的每个节点有两个标签:
-
META - 由于元模型中的每个节点都带有 META 标签,我们可以快速地完全专注于或完全忽略自描述数据库中的元模型数据。
-
CamelCasedPathSubsetLabel - 这种标签命名约定概念性地代表了具有重要元模型访问、解释和组织意图的嵌套子集语义。
注:当前的 Neo4j 实现将节点上的多个标签视为一组独立的集合成员资格“令牌”。我同样可以直接使用多个标准 Neo4j 标签,只需采用按照“包含概念”顺序书写这些标签的约定即可。CamelCase 方法更安全,可以避免意外陷阱,同时还允许我在 Cypher 标签匹配子句中探索使用正则表达式,以便在路径包含语义方面获得我想要的大部分效果,而无需等待它添加到 Neo4j 功能集中。在 0.1 版本中,使用了 `backticked.dotted.path.string\` 语义。在 0.2 版本中,我采用 CamelCase 约定,以便 https://structr.com 的杰出代码向导 Axel 和 Christian 能够利用 structr 的出色能力,帮助 FactMiners 事实云向导和 FactMiners.org 网站尽快成为现实!!!我们牺牲了可读性,换来了实现的出色性。这是一笔非常划算的交易。:-) 也许这种约定最不幸的影响是需要将 PropertyMaps 称为 Propertymaps。这是一项正在进行的工作。
Softalk 事实云元模型中的节点至少有两个“原生”属性:
-
type - 元模型中类型属性为“PERSON”(即 (:META:Nodes {type: \"PERSON\"}))的节点意味着数据库中将存在一个带有“PERSON”标签(即 (:PERSON))的节点子集。
-
name - 技术上可选。此属性用作方便阅读的显示名称。
我所说的“原生”属性,是指显式输入到节点上的属性。正如您将在本 gist 的后续部分中看到的,我们将使用“分而治之”的策略,将节点和关系属性作为属性映射(Propertymaps)处理,这些属性映射可以通过节点类型匹配自动关联,或通过附加关联语义手动关联。
描述杂志基本结构
1980 年 9 月至 1984 年 8 月期间出版的 48 期 Softalk Magazine,提供了微型计算机革命早期最详细的时间胶囊式快照。这 48 期杂志被集结成四个年度卷,构成了该杂志的全部出版周期。每期杂志都包含若干页面。
以下是关于杂志经典结构的快速回顾(其中一些是 Softalk 杂志特有的示例,展示了典型杂志前部和后部的非专题内容):
-
杂志前部
-
封面
-
刊头
-
目录
-
编辑寄语
-
等等
-
-
专题“重点”
-
专题
-
-
杂志后部
-
专栏
-
操作指南
-
畅销书排行榜
-
封底
-
我们首先创建描述核心杂志结构的元模型元素。
对于我们的 Softalk Magazine 事实云,我们的档案馆代表玩家使用事实云向导,回应一系列关于待事实挖掘的数字藏品基本单位和组成的引导提示。
CREATE
(magazine:META:SourceStructureNodes {type: "MAGAZINE", name: "Magazine"}),
(volume:META:SourceStructureNodes {type: "VOLUME", name: "Volume"}),
(issue:META:SourceStructureNodes {type: "ISSUE", name: "Issue"}),
(page:META:SourceStructureNodes {type: "PAGE", name: "Page"})
// And hook them up to reflect their part-subpart relationship...
CREATE volume - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "PART_OF", name: "Part of"})
- [:TO_NODE] -> magazine
CREATE issue - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "PART_OF", name: "Part of"})
- [:TO_NODE] -> volume
CREATE page - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "PART_OF", name: "Part of"})
- [:TO_NODE] -> issue
在上面的 Cypher 查询中,我们的玩家使用事实云向导描述了源材料结构的分解,从而由向导生成了元模型中特定于 SourceStructure 元素子集的结构节点和 PART_OF 关系节点。当然,没有玩家——即使是创建和维护事实云元模型的玩家——需要了解或理解元模型、它们的解释或任何其他内容。向导才是编写我们在此探索的代码的部分。
根据您的浏览器或设备如何渲染这些新节点的图可视化,可能不清楚向导已经创建了一条蛇形路径,该路径由交替出现的结构元素节点和 PART_OF 关系节点组成,模拟了实际数据库中的 PART_OF 关系。如果向导在后续配置交互中发现 PART_OF 关系在上下文上很复杂,则元模型中关于该关系的 _metamodel 节点将作为元模型中描述该关系在非元数据库中的子图的“根”。
沿着与事实云向导的 ELIZA 式对话继续,我们的事实云创建者玩家继续深入探讨待事实挖掘的藏品项目的结构。接下来,我们的玩家告诉向导关于在任何给定页面上可能找到的所有各种杂志结构元素——从事实挖掘的角度来看,杂志是一个复杂的文档结构。以下是向导将添加的一些最明显的“页面部分”,以进一步表征事实云元模型中的 Softalk Magazine 档案馆:
CREATE
(fcov:META:SourceStructureNodes {type: "FCOV", name: "Front cover"}),
(ifcov:META:SourceStructureNodes {type: "IFCOV", name: "Inside front cover"}),
(bcov:META:SourceStructureNodes {type: "BCOV", name: "Back cover"}),
(ibcov:META:SourceStructureNodes {type: "IBCOV", name: "Inside back cover"}),
(masthead:META:SourceStructureNodes {type: "MASTHEAD", name: "Masthead"}),
(toc:META:SourceStructureNodes {type: "TOC", name: "Table of Contents"}),
(loa:META:SourceStructureNodes {type: "LOA", name: "List of Advertisers"}),
(column:META:SourceStructureNodes {type: "COLUMN", name: "Column"}),
(feature:META:SourceStructureNodes {type: "FEATURE", name: "Feature"}),
(review:META:SourceStructureNodes {type: "REVIEW", name: "Review"}),
(top30:META:SourceStructureNodes {type: "TOP30", name: "Top 30 List"}),
(top10biz:META:SourceStructureNodes {type: "TOP10BIZ", name: "Top 10 Business List"}),
(top10gam:META:SourceStructureNodes {type: "TOP10GAM", name: "Top 10 Games List"}),
(ad:META:SourceStructureNodes {type: "AD", name: "Advertisement"})
WITH [fcov, ifcov, bcov, ibcov, masthead, toc, loa, column, feature, review, top30, top10biz, top10gam, ad] as pg_parts
MATCH (page:META:SourceStructureNodes)
WHERE page.type = "PAGE"
FOREACH (pg_part IN pg_parts |
CREATE pg_part - [:FROM_NODE] ->
(r:META:SourceStructureRelationships {type: "PART_OF", name: "Part of"})
- [:TO_NODE] -> page)
GraphGist“弹跳球”图可视化的相当活泼且不可预测的渲染行为,可能会使这种新兴的杂志源藏品结构有点难以看清。但如果您伸手并根据需要拖动节点,您将看到一种我称之为“精子”的图结构,其中“尾部”是 PART_OF 路径,它将杂志一直分解到页面元模型节点周围的页面部分星群(即精子“头部”)。
在下一节中,我们的玩家将使用向导将这个“精子”变成一个“哑铃”。
描述杂志基本内容
在最基本的层面,Softalk 的内容涉及人物(People)、产品(Products)、公司(Companies)、技术(Technologies)、地点(Locations)和事件(Events)——以及许多其他事物。但我们将把本 GraphGist 的重点放在本 GraphGist 系列第三部分中“事实发现和录入”游戏玩法用例场景所需的最基本要素上。
以下 Cypher 查询创建了表示 Softalk Magazine 中发现的五种编辑内容类型的元模型节点:
CREATE
(person:META:SourceContentNodes {type: "PERSON", name: "Person"}),
(company:META:SourceContentNodes {type: "COMPANY", name: "Company"}),
(product:META:SourceContentNodes {type: "PRODUCT", name: "Product"}),
(location:META:SourceContentNodes {type: "LOCATION", name: "Location"}),
(event:META:SourceContentNodes {type: "EVENT", name: "Event"})
WITH [person, company, product, location, event] as content_elements
MATCH (magazine:META:SourceStructureNodes)
WHERE magazine.type = "MAGAZINE"
FOREACH (content_element IN content_elements |
CREATE magazine - [:FROM_NODE] ->
(r:META:SourceContentRelationships {type: "IS_ABOUT", name: "is about"})
- [:TO_NODE] -> content_element)
这些内容元素在 FactMiners 事实云的“事实”中用作“事物”节点“相关联”的基础,即最简单的图数据库基本语义表达:(thing_A) - :IS_RELATED → (thing_B)。
随着我们不断完善 Softalk Magazine 事实云的元模型,您会开始看到这些内容元素与杂志结构中特定细粒度元素关联的一些结构化方式。例如,在本 GraphGist 的第三部分中,我们将演示一个关于录入 Softalk 著名畅销榜 Top 30 中发现的信息的“事实发现和录入”游戏玩法场景。在我们快速了解元模型如何处理节点和关系属性后,我们将通过完成畅销榜文档结构的元模型覆盖来结束本系列这一部分。
对属性的初步探讨
属性元建模在 FactMiners 设计中将非常重要。这很可能是我们将要保留“提示包”运行时信息的地方,以便元模型感知的瘦客户端应用程序(例如 FactMiners 社交游戏应用)能够获取细粒度有用信息,以执行符合要求的数据访问、编辑和可视化任务。
尽管我可以想到几种不同的属性元建模方法,但有两个考虑因素让我采取了初步的方法:
-
在事实云向导中创建和编辑属性相当复杂,因此向导的这方面可能是一个独立的完整功能组件。此组件可以创建和维护其属性映射(Propertymaps),并将其放置在方便的位置,以便具有属性的非元节点和关系的元模型元素查找和使用。
-
Cypher 具有强大的参数化属性映射语义,在编写 Property-Builder 时将非常有用。
了解了这些要点,并且为了避免随着越来越多的元模型元素具有越来越多的互连而导致视觉复杂性爆炸,我采用了以下机制在 Softalk 事实云元模型中提供基本属性建模:
-
任何具有“type”属性的元模型节点(Node)或关系(Relationship)都可以拥有一个可选的关联属性映射(Propertymap),该属性映射描述了由该元模型元素建模的元素的实例属性。
-
该属性映射(Propertymap)将与与之关联的节点(Node)或关系(Relationship)具有相同的“type”。(注意:我还在考虑为属性映射元素上的 type 属性使用一个集合,作为处理不同类型元素之间共享属性集的一种方式;例如,Softalk Magazine 中页面元素的许多页面部分的共享属性。)
-
所有属性映射(Propertymaps)都与各自 Source…Propertymaps 子集中的“根”节点具有“IS_A”关系。这里是 Property-Builder “挂载”其生成输出的地方,以便于访问和维护。
将属性存储用于“小部件级别提示”以动态配置编辑和可视化任务的预期用途,足以假定属性元建模的整个领域将成为一个独立有趣且富有挑战性的领域。假设“关注点分离”有助于简化我们的事实云向导开发需求也是合理的。因此,这样处理属性映射(Propertymaps)可能对我们开发事实云向导的 Property-Builder 组件更有长期价值。
以下是一个关于元建模属性映射(Propertymaps)如何为 PERSON 和 COMPANY SourceContentNodes 提供一些基本属性的示例。我们首先在元模型的 SourceContentPropertymaps 子集中创建“根”节点。然后,为任何需要建模 Neo4j 数据库中数据属性的 SourceContentNodes 元素类型创建并链接一个属性映射节点。最后,创建示例属性节点,并将其组织在 SourceContentNodesPropertymaps 子集中(因为这是事实云向导 Property-Builder 的“工作空间”)。
// Create a root node where the Fact Cloud Property-Builder of the Wizard will hang its generated contributions
// to be picked up by a type-matching naming convention.
CREATE (propertyMapRoot:META:SourceContentPropertymaps {name: "Content Propertymaps"} )
// Again applying the type-->label mapping idea, (:PERSON) nodes in the non-meta data will have a set of properties described by the subgraph anchored in the metamodel at (:META:SourceContentPropertymaps {type: "PERSON"}). Same for (:COMPANY) nodes.
CREATE propertyMapRoot - [:IS_A] -> (personPropertymap:META:SourceContentPropertymaps {type: "PERSON", name: "Person properties"} )
CREATE propertyMapRoot - [:IS_A] -> (companyPropertymap:META:SourceContentPropertymaps {type: "COMPANY", name: "Company properties"} )
CREATE
personPropertymap - [:HAS_PROPERTY] -> (:META:SourceContentNodeProperties {property: "name", name: "Full name", valueType: "text"}),
personPropertymap - [:HAS_PROPERTY] -> (:META:SourceContentNodeProperties {property: "age", name: "Age", valueType: "number"}),
personPropertymap - [:HAS_PROPERTY] -> (phoneNum:META:SourceContentNodeProperties {property: "phone", name: "Phone", valueType: "phoneNumber"}),
companyPropertymap - [:HAS_PROPERTY] -> (:META:SourceContentNodeProperties {property: "name", name: "Name", valueType: "text"}),
companyPropertymap - [:HAS_PROPERTY] -> phoneNum
CREATE (propertyMapRoot2:META:SourceStructureNodePropertymaps {name: "Structure Node Propertymaps"} )
CREATE propertyMapRoot2 - [:IS_A] -> (pgPartCommonProperties:META:SourceStructureNodePropertymaps {name: "Page part common properties"})
// If the type property of a Propertymap is a collection, it contains the type values to which the shared map applies.
// NOTE: The wizard will likely generate individual Propertymap nodes pointing to shared/reusable Property nodes. I just
// did not want to bulk this gist with too much code or too many elements drawn in the graph visualizations.
SET pgPartCommonProperties.type = ["FCOV", "IFCOV", "BCOV", "IBCOV", "MASTHEAD", "TOC", "LOA", "COLUMN", "FEATURE", "REVIEW", "TOP30", "TOP10BIZ", "TOP10GAM", "AD"]
CREATE
pgPartCommonProperties - [:FROM_NODE] ->
(:META:MetaRelationships {type: "HAS_PROPERTY", name: "Has property"})
- [:TO_NODE] -> (:META:SourceStructureNodeProperties {property: "origin", name: "Origin (x,y)", valueType: "point"}),
pgPartCommonProperties - [:FROM_NODE] ->
(:META:MetaRelationships {type: "HAS_PROPERTY", name: "Has property"})
- [:TO_NODE] -> (:META:SourceStructureNodeProperties {property: "extent", name: "Extent (w,h)", valueType: "point"}),
pgPartCommonProperties - [:FROM_NODE] ->
(:META:MetaRelationships {type: "HAS_PROPERTY", name: "Has property"})
- [:TO_NODE] -> (:META:SourceStructureNodeProperties {property: "raw_text", name: "Raw text", valueType: "string"}),
pgPartCommonProperties - [:FROM_NODE] ->
(:META:MetaRelationships {type: "HAS_PROPERTY", name: "Has property"})
- [:TO_NODE] -> (:META:SourceStructureNodeProperties {property: "raw_image", name: "Raw image", valueType: "sourcecollection:url"})
为了支持本 GraphGist 系列第三部分用例场景的游戏玩法交互,关于属性我需要涵盖的就到此为止了。
不幸的是,我们现在也开始达到 GraphGist 图可视化控制变得有点难以控制的地步了。当元模型元素需要描述非元数据中节点和关系的属性时,您会开始看到属性映射(Propertymap)簇的“岛屿”。但是,和以前一样,如果您“伸手并拖动周围的物体”,您就可以很好地了解我们的 Softalk 事实云元模型进展如何。
当然,在事实云向导的受控用户环境中,优秀的 UI 设计将使元模型的创建、维护和扩展即使不有趣,至少也能做到有条理和可行。与此同时,抓住一个节点并稍微拖动一下也挺有趣的。
添加结构子部分
到目前为止,我们已将杂志的页面划分为(当前为矩形)区域,这些区域映射到刊头、广告商列表、专栏、专题、评论、畅销书列表、广告等文档结构元素。这些页面部分区域可能也有结构。Softalk Magazine 中一个数据非常丰富的子部分结构元素的例子是其各种畅销书列表。每个月,Top 30 列表根据 Apple 电脑软件的受欢迎程度进行排名,不分类别。Top 10 列表根据行业和消费市场的演变,对商业应用、游戏和教育软件等进行排名。这些列表由 Softalk 严谨且独立地研究和报告,因此是 Softalk Magazine 档案馆页面中包含的有趣且具有历史价值的数据。
每个畅销书列表都有其规定的列表项条目数量。这些畅销书列表项节点成为建模杂志结构元素的“PART_OF”路径中的新叶节点。我在这里建模了三个示例列表。由于它们都具有相同的行项目结构,这三个页面部分都成为新添加的 PART_OF 关系的终端节点,这些关系将畅销书列表项链接到杂志结构中。
CREATE (topXlist_item:META:SourceStructureNodes {type: "TOPX_LIST_ITEM", name: "A Bestseller List Line Item"})
WITH topXlist_item
MATCH (topXlist:META:SourceStructureNodes)
WHERE topXlist.type IN ["TOP30", "TOP10BIZ", "TOP10GAM"]
CREATE topXlist_item - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "PART_OF", name: "Part of"})
- [:TO_NODE] -> topXlist
当我们查看畅销书列表的行项目列表时,我们可以开始看到 Softalk 事实云中“事实”的“织物”(或“编织”)将如何捕获“绑定到”(即在...上下文中有意义)杂志结构的信息——列表项在畅销书列表中的序数位置以及由列表研究人员计算的月度统计指数——以及那些将列表与杂志编辑内容中涵盖的现实世界“领域对象”关联的信息——人物是(软件)产品的开发者,公司是(软件)产品的出版商。由于我们正在通过零敲碎打的方式探索和完善这个元模型,我们可以将这种内容/结构映射添加到元模型中。
正如“充满事实”拼贴图像中的特写所示,畅销书列表项具有(序数)位置和(月度评级)指数属性。由于我们的向导尚未在 SourceStructureRelationshipsPropertymaps 子集中创建任何属性映射(propertyMaps),它首先创建 Property-Builder 组件维护其对元模型的贡献的“根”节点,然后创建所需的属性映射(Propertymap)元素。
CREATE (propertyMapRoot:META:SourceStructureRelationshipsPropertymaps {name: "Structure Relationship Propertymaps"} )
CREATE propertyMapRoot - [:IS_A] -> (:META:SourceStructureRelationshipsPropertymaps {type: "PART_OF", property: "position", name: "Position", valueType: "number"})
CREATE propertyMapRoot - [:IS_A] -> (:META:SourceStructureRelationshipsPropertymaps {type: "PART_OF", property: "rating", name: "Rating", valueType: "number"})
现在我们来到了有趣的部分… 我们将创建我们的第一个元模型构造,它将杂志编辑内容中的某些内容(即 SourceContentNode 节点)与杂志结构元素(SourceStructureNode)关联起来。
Top X 列表项与软件:PRODUCT 相关联。列表项包括开发者和发布产品的公司名称。因此,列表项“穿透”ON_LIST 关系来确认或创建产品与其开发者:PERSON 和出版商:COMPANY 之间的关系,于是我们创建了相应的关系:
MATCH (item:META:SourceStructureNodes), (product:META:SourceContentNodes),
(developer:META:SourceContentNodes), (publisher:META:SourceContentNodes)
WHERE item.type = 'TOPX_LIST_ITEM' AND product.type = 'PRODUCT' AND developer.type = 'PERSON' AND publisher.type = 'COMPANY'
CREATE
// The listing's primary identity is the software:PRODUCT that has earned a place on a bestseller list
p3 = ((item) - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "ON_LIST", name: "on list"})
- [:TO_NODE] -> (product)),
// 'Fact bits' in a standard Softalk bestseller listing include the name of the primary developer:PERSON
// and the name of the publishing company. These 'fact bits' confirm/create relationships accordingly...
p4 = ((product) - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "DEVELOPER", name: "developer"})
- [:TO_NODE] -> (developer)),
p5 = ((product) - [:FROM_NODE] ->
(:META:SourceStructureRelationships {type: "PUBLISHER", name: "publisher"})
- [:TO_NODE] -> (publisher))
RETURN p3, p4, p5
我很确定您需要“连续拖动节点”才能专注于我们刚刚添加到元模型中的这些最终有趣的新内容。“内容与结构相遇”的方面在畅销书列表项结构元素和产品内容元素之间的 ON_LIST 关系中清晰可见。但真正最有趣并最能展示“自描述”图数据库力量的是“穿透”方面。我相信,元模型子图设计模式对于具有松散耦合但语义丰富的数据的应用将特别有用。
总结思考:关于松散耦合的富语义信息空间
是的,我们深入研究到能够看到杂志内容和结构在结构意义上(例如广告商列表、购买指南目录等)如何交织在一起的细粒度示例,这很有趣。但事实挖掘杂志的更大挑战在于,任何给定的“事实”可以以多种不同的方式显现。在最后的 Cypher 片段中,我们创建了 DEVELOPER 和 PUBLISHER 关系,这是因为在一个畅销书列表行项目中找到了表达这种关系的信息。但是,以这里“充满事实”图像中的示例为例,在 Softalk 杂志中将有许多地方可以找到“Dan Gorlin 是 Choplifter 的开发者”和“Choplifter 由 Broderbund Software 出版”这些事实的“出现”(实例)。实际上,这些事实实例的数量和分布是创建事实云所产生的有趣新数据。
关于这个项目,真正令我兴奋的一件事是,当我们完全事实挖掘 48 期 Softalk 杂志月刊后,我希望看到什么。当这本卓越而历史悠久的杂志中的所有“事实”都存储在一个“自描述”的 Neo4j 图数据库中时,我相信我们将拥有一副令人着迷且有价值的新“镜头”,来看待技术史上最卓越的一个时期。
如果实现途径(设计和开发 FactMiners 生态系统)或最终目标(帮助创建 Softalk Magazine 事实云)中的任何一个引起您的兴趣,请随时与我联系。(Twitter:@Jim_Salmons)
感谢您一直陪伴我阅读完本 GraphGist 系列的前两部分。
让我们继续本 GraphGist 系列的第 3 部分,在那里我们将探索一个双人游戏玩法场景,它将应用我们刚刚在这里构建的元模型。(实际上,第 3 部分还需要一段时间才能发布,因为它目前处于初稿阶段,第 4 部分紧随其后。但首先… 我要去搭建 FactMiners.org 网站了…)
本页面有帮助吗?