《无限制信息关联技术的研究》一文的补充说明
一、
单一数据结构能否实现所谓的“无限制关联”?
我在上一篇文章中可能未能明确说明,其实我所处理的目标是一种“有限集”中的对象。就是假设所有相关联的信息对象存在于一个有限集中,比如在一个或几个数据库中。处理有限集中对象的无限制关联,用单一的数据结构是有可能的(极端一点,这个集合中可以只有两个对象)。当然,严格来说,需要证明。
所以,我把这种关联技术还称为“狭义的无限关联”。当我们面对
Internet
时,可以想象互联网上的信息是一个无限集。我甚至也幻想过解决无限集中的无限关联的问题,但这就成为“广义的无限关联”。这种广义的无限关联能否用单一结构来解决,可以说:难以想象。
另外,我还追求一种“精确的”无限关联。就是我处理两个相互关联的对象时,这两个对象均是可以唯一定位的,所以我在表达对象时,用的都是定位标识(如
ID
)。而在互联网上能否或必须精确定位,则需要研究。比如
W3C
的
RDF
中对客体的描述就没有“精确”的要求。
二、
与资源描述框架
(RDF)
的比较。
W3C
的
RDF
(
Resource Description Framework
)从
1998
年提出,到
2004
被批准,现在已经成为互联网的基础标准之一,也是目前语义
Web
(
Semantic Web
)的技术核心基础。
RDF
与我提出的结构有相近之处,当然,我的东西跟这相比确实显得初级。但在思路上也有不同之处。
1
、资源描述框架
(RDF)
是一种用于表示
Web
上信息的框架(标准见:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
)。它表达的重点在信息主体,而非信息关系(尽管它也含有关系)。在
RDF
中任何表达式的基本结构是一个三元组的集合,每个三元组由一个主体、一个谓词和一个客体组成。比如我们要表达一篇文章及其作者:
<RDF>
<Description about="文章一">
<author>
<Bag>
<li>张三</li>
<li>李四</li>
<li>王二</li>
</Bag>
</author>
</Description>
</RDF>
(注:上面的例子是简化了的。名称空间已省略了。)
这里,主体是
"
文章一
"
,谓词是“
author
”,而客体是“
Bag
”,包括三个作者:张三、李四、王二。这样做,从主体的角度很方便,只要找到主体
"
文章一
"
,那么它的作者就很容易检索出来。但从客体的角度却很麻烦,你必须查阅所有的主体,才能知道一个作者到底写了几篇文章。假如信息庞大或分散的话,这种做法近乎愚蠢。就好比我们的电话机都能记录拨出的号码,却没有来电显示,要查拨出的电话很容易,而要查谁给我打了电话,就必须到全国所有的电话机上去翻阅它们的拨出记录。当然我说“愚蠢”二字,并不是贬低
RDF
,而是说它不着重于关联关系。
当然,为了解决上面的问题,你也可以在建立前述结构的同时,再建一个类似如下的结构:
<RDF>
<Description about="张三">
<article>
<Bag>
<li>文章一</li>
<li>文章二</li>
<li>文章三</li>
</Bag>
</article>
</Description>
</RDF>
这确实解决了上面的问题,但注意,谓词变化了,一个是
author
,另一个是
article
。也就是说,
author
是用文章来找作者,而反过来时,你必须记着从作者找文章是用
article
,如果你用了其他类似的谓词
report
,则不会有结果。那么,两个结构里都用同一个谓词(比如:
article
)可以吗?不行,一方面会意义混淆,另一方面
RDF
标准也不允许(注:标准写道:一个谓词(也称为属性),它表示一个关系。边的方向很重要:它总是指向客体。见《RDF标准》的3.1
)。当然,这也还不难,只要再建立一个映射表,将
author
与
article
对应起来就可以解决。但还要注意,如果我们系统中以后又增加了有关雕塑作品的信息,那与
author
对应的谓词可能还有
works
或
production
。所以,对于系统自动运行来说,这将增加系统负担;而对于处于开发阶段的人来说,这增加了工作量和出错机会。
2
、
RDF
重点是描述主体信息,其他的,谓词也好、客体也好,可以有很多东西,但这些均是主体的属性,是主体的附属物,处于统治地位的始终是主体。就表述
Web
上信息而言,
RDF
是当之无愧的标准或权威,但就信息关联关系而言,则不敢恭维。
RDF
不是解决关联关系的最佳方案。
3
、我构造的结构是以关联关系为重点的,在这里,关联和被关联的信息对象在结构上是平等的。如果我用
XML
来表达上面的关系,是这样:
<Relationship name="author" direction="A">
<InfoA>文章一</InfoA>
<InfoB>张三</InfoB>
</Relationship>
这里
name="author"
对应我文章中的关联类别,
direction
对应关联方向,
"A"
表示正向,即表示:
InfoA
的
author
是
InfoB
。
还可以反过来,就这样:
<Relationship name="author" direction="B">
<InfoA>张三</InfoA>
<InfoB>文章一</InfoB>
</Relationship>
因此,无论是正过来,还是反过去,一对关系中的两个对象在形式上是处于平等地位的。而实际上的关系指向则取决于
direction
中的值是“正向”,还是“反向”,抑或是“双向”。在这里,关联关系及其方向是主角,信息对象成了配角,而且对象间彼此地位形式平等。(这种形式上的平等是否有助于提高“非中心化(
decentralized
)和可移动性(
mobility
)”等特性?)
用前面查电话的例子,就是说,每部电话都不作记录,而通话记录在电信局,查询时,都不能在本机上进行,无论查询打入或打出都要到电信局。这种方式虽也不理想,但总比跑遍全国去翻每部电话的打出记录要现实得多。理想的方式是电信局无需记录,而让每部电话均有一个记录本,既记录打出,又记录打入。这虽然造成关联记录数量翻倍的冗余,但对于效率而言则相当值得。所以我的做法是:每个信息都有自己的独立关联记录区。当
InfoA
和
InfoB
发生关联时,关联数据既记录在
InfoA
的关联记录区,又记录在
InfoB
的关联记录区。两条关联数据中关联类别(如本例中的
author
)相同,而关联方向相反。
在我设计的结构中,关联类别是核心,关联方向是关键。