In this article, Ozkarahan and Can attempt to combine relational database processing with document retrieval (textual searches) into a single, theoretical system. The paper is an extension of the research work done previously by the two authors (and others) using the Relational Associative Processor (RAP.3) database machine. The stated impetus of the article is that office automation systems of the future will need to have ready access to both documents and factual data in a single system. (There is also an implication that existing commercial and experimental systems do not provide this capability.)

The article correctly deduces that any attempt to combine document or Information Retrieval (IR) with relational DBMS processing would need a comprehensive design from the ground up. Otherwise, either an existing relational DBMS would have to be force-fitted to handle IR requirements or vice versa. With that in mind, the authors proceed to develop the theoretical basis for their combined system and then go ahead and force-fit it into the RAP.3 architecture]

The article has some good ideas. It proposes the representation of documents as vectors based upon the occurrence of terms in the text. These vectors can then be clustered, and the cluster can be represented with a centroid vector of weighted terms. The centroid vector would be used as an index for a gross match against the retrieval parameters. Once the initial match has been made, full textual scan would be initiated against the identified subset of documents.

The authors also propose a distributed (star network) architecture with storage of the complete textual documents on a central processor (VAX 11/780 in this case) and use of intelligent workstations. The central processor would be used to process the query and make the initial selection of documents using the centroid vectors. The intelligent workstation would be used to do the full text scan and to let the user iterate through his retrieval request.

The article also suffers from a number of omissions. First, it assumes that the reader is well versed in both IR fundamentals and the RAP.3 system (a requirement to appreciate what is being proposed). Second, although it compares the proposed approach to some current research areas, the paper fails to show how the approach is any better than existing operational systems such as STAIRS, INQUIRE, or GE-SCAN2. Third, the authors totally omit any mention of how the document terms will be extracted to build document vectors (a major real-world problem). Finally, they wave away any performance problems with general statements about how the system is expected to be efficient. (This final omission is probably because the RAP.3 is still a software emulation of a database machine).

The article could be useful for someone looking at current research efforts in integrating relational DBMSs and IR techniques. However, I doubt the article will impact anything except future RAP.3 system enhancements.