技术编程像图一样的数据模型( 四 )


不幸的是 , 语义网在2000年代初期被过度炒作 , 但到目前为止 , 它并没有表现出在实践中被实现的任何迹象 , 这使许多人对此表示怀疑 。 它还遭受了令人眼花乱的首字母缩略词 , 过于复杂的标准提案和自负 。
但是 , 如果您回过头来看这些失败 , 语义Web项目中还是有很多出色工作的 。 即使您没有兴趣在语义Web上发布RDF数据 , 三元组也可能是应用程序的良好内部数据模型 。 RDF数据模型
上文中的Turtle语言是一种人类可读的RDF数据 。 有时RDF被写成XML的格式 , 更详细的描述了上文中Turtle语言所做的事情 , 如下图:
技术编程像图一样的数据模型
本文插图
由于看起来更简单 , Turtle/N3是完美的 , 像Apache Jena这样的工具能够自动在必要的情况下转换不同的RDF格式 。
由于RDF专为整个Internet的数据交换而设计 , 因此存在一些怪癖 。 三元组的主题 , 谓词和宾语通常是URI 。 subject , predicate , 和object的三元组通常都是URI 。 比方说 , predicare可能是诸如

这样的URI , 而不是像WTHIN或LIVES_IN这样 。 这样设计的理由是这样可以和他人的数据合并 , 并且 , 如果他们对within或libves_in添加了不同的意思 , 你不会因此而冲突 , 因为他们的pridicate实际上是这样的:


从RDF的角度上来看 , URL
不是必须去解决什么问题的 , 他就是个命名空间 。 幸运的是 , 您只需在文件顶部指定一次该前缀 , 然后就不用管它了 。 SPARQL查询语言
SPARQL是像triple-stores这样用RDF数据模型的数据库的查询语言 。 它是SPARAL Protocol and RDF Query Language的缩写 , 读作“sparkle” 。 它早于Cypher , 并且由于Cypher的模式匹配是从SPARQL借来的 , 因此它们看起来非常相似 。
与之前相同的查询(查找从美国移居到欧洲的人)在SPARQL中比在Cypher中更为简洁 , 如下图:
技术编程像图一样的数据模型
本文插图
结构非常相似 。 下面的两句表达式是相等的:
技术编程像图一样的数据模型
本文插图
因为RDF并不区分属性和边 , 把它们都看作predicate , 因此你可以使用相同的语法去匹配属性 。 在下面的表达式中 , 变量usa被绑定到一个有name属性且属性值是字符串“United States”的顶点:
技术编程像图一样的数据模型
本文插图
SPARQL是一种不错的查询语言 , 即使语义网从未发生过 , 它也可以成为应用程序在内部使用的强大工具 。
图数据库与网络模型的比较
之前我们讨论过CODASYL和关系行模型是怎样在IMS中竞争去解决多对多关系的问题的 。 第一眼看上去 , CODASYL的网络模型和图模型很相似 。 那么 , 图数据库是CODASYL的第二次变相吗?
不 , 它们有以下几点的不同:
- 在CODASYL中 , 数据库有专门的模式去指定需要的记录怎么嵌入到其他的记录中 。 在图数据库中 , 没有这样的限制:任何顶点都可以和任何其他的顶点有一条边 。 这为应用程序提供了更大的灵活性 , 以适应不断变化的需求 。
- 在CODASYL中 , 到达特定记录的唯一方法是对这条记录的访问路径中的一条 。 在图数据库中 , 你可以直接引用顶点独一无二的ID , 或是用一个特定值作为索引去找到顶点 。
- 在CODASYL中 , 记录的子记录是一个有序的组 , 所以数据库不得不维护这个序列并且往数据库插入新数据的应用必须注意新记录在这个组中的位置 。 而在图数据库中 , 顶点和边是没有顺序的(当然 , 你可以根据查询的结果排序)


推荐阅读