2. RDF数据容易聚合
对RDF数据来说,它相对于XML数据的一个最大的优势就是容易聚合,因为RDF有URIref标识资源,数据模型又是基于图的,RDF陈述的主体,客体都可以是URIref,因此,很容易通过URI把RDF数据合并。而XML数据是很难聚合的,根本原因是XML中的数据没有标识符。
3. 基于URI的聚合
如果资源都有URIref标识,聚合的过程就是把关于这个URIref的陈述都合并起来就行了。
例如,在香港某网站上的A.rdf中,说了
http://foo.com/JackChen ex:girlfriend http://foo.com/QiliWu(吴绮莉)
然后在马来西亚某网站上有个B.rdf,说了,
http://foo.com/QiliWu ex:hasChild “小龙女”
RDF聚合软件(Aggregator)就会根据URI http://foo.com/QiliWu, 把这两个陈述合并,得到结论:JackChen的女朋友有个女儿。如果这个Aggregator大胆些的话,有一条规则:?x ex:girlfriend ?y 且 ?y ex:hasChild ?z ?x ex:hasChild ?z 的话,就会得到JackChen还有个女儿。 特大新闻!呵呵, 这就是聚合的威力!这当然也侵犯了某人的隐私。
4. 基于IFP的聚合
基于基于URI的聚合的前提是资源都有URIref标识, 并且不同的人对同一个资源使用相同的URIref,这显然是不现实的。例如,同一本书,不同卖书网站给的URIref一般不同。
解决这个问题的一个办法是cross-mapping:即维护一个映射,说明 ex:a owl:sameAs ex:b, 即说明哪些URI标识的对象是相同的,这个方法也比较麻烦,因为这个映射难以维护。何况很多资源还不一定有URIref呢,可能是匿名资源。
另外一个方法是基于IFP属性(InverserFunctionalProperty), 即OWL中的反函数型属性,类似于数据库中的主键。即这个属性的值唯一标识了有个对象。如身份证号码标识了一个公民。如果一个地方都说有个人,它的身份证号码是1001,它的名字是xxx,另外一个地方说说有个人,它的身份证号码是1001,它的年龄是yyy, 虽然没有URIref来标识它,聚合器可以得到把这两条信息合并起来。
对RDF数据的基于IFP的聚合,现在有个特定的名词很流行:Smushing (is an informal term for ’merging data based on knowledge of uniquely identifying properties’.)
基于IFP的聚合减少了对URI的依赖,但同时引入了新问题:即大家要使用同一个关于这个IFP属性的词汇表。
后面的参考文献中有对聚合算法的讨论。这里不多说了。
5. 进一步的讨论
a) 数据聚合要考虑不同数据的来源(provenance)以及其上下文(context).
b) 可以放宽对属性的限制,即不一定要是IFP属性,更通用的是reference-by-description(Guha’s works, TAP project in Stanford)
c) 不同数据源的数据含有矛盾,怎么处理?
参考文献:
Finally… a couple of points of further reading on the technical rather than social side of this problem. A couple of years ago I wrote a brief note on aggregation strategies which describes the ’smushing’ problem. A more recent writeup by Matt Biddulph describing his Java implementation is worth a read too, as are many of the documents from the TAP project, which share FOAF’s concern for reference-by-description. Guha and Rob’s overview paper sets out the issues very clearly.