信息无限关联的补充说明

   

《无限制信息关联技术的研究》一文的补充说明

一、     单一数据结构能否实现所谓的“无限制关联”？

我在上一篇文章中可能未能明确说明，其实我所处理的目标是一种“有限集”中的对象。就是假设所有相关联的信息对象存在于一个有限集中，比如在一个或几个数据库中。处理有限集中对象的无限制关联，用单一的数据结构是有可能的（极端一点，这个集合中可以只有两个对象）。当然，严格来说，需要证明。

所以，我把这种关联技术还称为“狭义的无限关联”。当我们面对 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 ）相同，而关联方向相反。

在我设计的结构中，关联类别是核心，关联方向是关键。