Company Background
In for the Long Haul
In the software industry, Information Dimensions Incorporated (IDI) could be considered an old timer. Founded in 1986, IDI was spun out of Battelle Memorial Institute, a private, nonprofit, research think tank, in order to sell commercially the document management system originally developed by Battelle for its clients in 1973. This product, Battelle's Automated Search Information System (BASIS), was indeed the first text-retrieval product on the market.
The original BASIS product provided index-based text retrieval as well as support for document attributes for cataloging and abstracting. It was designed as a tool for corporate librarians and information specialists who worked with such early online services as Lexis, Nexis, and Dialog and were now charged with maintaining the “vault” of internal documents.
The product ran on a number of servers but really came into its own when Digital Equipment tightly integrated BASIS with All-In-One, its extremely popular integrated office system. As a result of this integration, departmental users began to use the product, although a librarian still owned the documents and controlled access.
In 1989, IDI did a major rewrite of the product and released BASISPlus, which integrated text retrieval into an extended proprietary RDBMS for managing and supporting document-based transactions, providing journaling, joining collections of documents for cross-repository searching, and document assembly. BASIS is now available in 26 languages, including Chinese, Korean, and Arabic.
In 1993, Online Computer Library Center (OCLC), the world's largest provider of library information cataloging services, acquired IDI. Going back to its roots, IDI is the for-profit subsidiary to the nonprofit OCLC.
Of its competitors in the 1980s—IBM STAIRS, BRS, InfoData, and a bunch of other products you probably haven't heard of in at least five years—BASIS is the only product still being actively sold. And IDI is positioned to take its secure, controlled approach to document management into the next century with an innovative Web publishing strategy.
IDI Product Line
Today, the IDI product family is called the BASIS Document Management System (DMS), which includes:
- BASIS Document Manager Version 8.0. BASIS Document Manager Version 8.0, released in 4Q 1996, is the core product. It provides integrated security, retrieval, management, and document integrity functionality on an extended relational document database infrastructure.
- BASIS Client Suite. Two client applications are provided in the BASIS Client Suite: BASIS Desktop, a windowing interface for interacting with the BASIS DMS, and BASIS Administrator, a specialized client front end for administration of BASIS DMS. The Client Suite also includes a number of customization and application integration products, including the BASIS ODBC-SQL Driver, which provides full ODBC and SQL compatibility for accessing data in other databases as well as supporting alternate front-end application development using such tools as PowerBuilder, Visual Basic, or any existing ODBC or SQL applications. A set of APIs is also available, called the BASIS Open API, which supports development and integration with applications on platforms other than Windows.
- BASIS WEBserver Gateway. The BASIS WEBserver Gateway provides Web browser access to BASIS document databases via a gateway from BASIS DMS into any CGI-compliant Web environment. Currently, higher performance integration is supported to Netscape environments through the Netscape API (NSAPI). Microsoft's IISAPI optimization is coming in 1Q '97.
- BASIS Corporate Information Centre (CIC). IDI offers the BASIS Corporate Information Centre (CIC), a prototyping tool that includes predefined databases for common document collections, predefined Web interfaces for those collections, and sample documents that demonstrate how these work. With CIC, you build a customized corporate information center for making corporate infrastructure documents available to all personnel.
BASIS DMS Architecture
Underlying Relational Document Database
BASIS DMS is built on a relational database model that follows the ANSI three-schema architecture used in other RDBMSs, such as Oracle. The underlying database is proprietary to IDI and has been built specifically to handle robust security requirements and fast and flexible document retrieval, and to provide a high level of integrity and reliability. Each document database sits on a single server. BASIS runs on most flavors of Unix, NT, and VMS.
A single server can house multiple document databases. And users can access multiple databases distributed across servers from the same client. However, distributed queries across servers are not supported.
Each document database includes three independent layers, so changes can be made in one without affecting the other layers. (See Illustration 1.) The layers are:
- Storage Definition
- Document Definition
- Interface Definition
All database definitions are defined by the BASIS administrator.
BASIS Document Database
Illustration 1. The architecture of a BASIS Document Database includes three independent definition layers, so changes can be made to one layer without affecting the others.
Storage Definition
In the BASIS document database, the administrator specifies where documents, journal files, and indexes are to be stored (e.g., distributed across different disks, different drives, different partitions, etc.). Also defined is the type of indexes that are to be maintained (e.g., full text, specific data ranges, exact values, etc.).
Document Definition
A document definition is made up of two elements:
- Content. Content can be any object or combination of objects, such as a Word document with an embedded spreadsheet.
- Attributes. A single document can have up to 250 attributes per object and up to 500 attributes per document.
Each document can have a unique set of attributes. More effectively, however, administrators define document types, which have the same set of attributes (again, up to 500 attributes). A single document database can store up to 4,000 different document types.
The document definition works in conjunction with the storage definition. The document storage location can be based on document attributes.
Interface Definition
All user access to documents is controlled by the interface definition. The BASIS administrator creates multiple views of the document. A view is a combination of content and attributes that defines what a particular user can see. The view specifies which attributes should be visible to a particular user as well as whether or not the document itself can be viewed based on content. For example, a document that includes the phrase “top secret” cannot be viewed by anyone but the author and those users with high security clearance.
The only access to documents maintained in the BASIS document databases is via views.
A single document can have dozens of associated views, each with minor variations in what is viewable and what is hidden. This provides tight control over document access. And interface definitions can be pretty sophisticated, running full-text queries in combination with attribute queries to determine exactly which attributes a user can see. Attributes that are not accessible don't appear even as blank fields, so the user doesn't know they exist.
Security
Security is implemented at both the database level and the view level. Users are restricted to the databases they can access and are authorized to access documents only through views. Views can be grouped into models, and users can be given access to specific models (e.g., marketing models, finance models, etc.). Security can control what you see as well as what actions you can take on a document down to the attribute level.
BASIS has no named groups, such as the marketing group. But the administrator can, via the BASIS Administrator front-end tool, select a group of individuals and assign them to models in a single action. Unfortunately, he or she cannot save this group for future use.
Database Replication
An entire document database can be copied to another server explicitly or automatically via scripting. In addition, because BASIS supports batch manipulation of documents, a script can be written on the server to execute a query, locate a collection of documents, pull this collection out of the database, dump them into a single file, and then load them into another database on another server. Again, this can be scheduled to happen automatically via the script.
Scalability
BASIS scales well because of its architecture, which defines document storage separately from the actual definition of the documents. This allows administrators to tune the environment to fit the computing infrastructure. So, for example, as collections get bigger, file storage can be spread out to different locations on the network to improve performance.
The core database capabilities support large collections of up to 128 gigabytes per database and large documents of up to 128 megabytes each. As indicated earlier, each document can have up to 500 attributes. Thus, through joins with other tables, a single document has a virtually unlimited number of attributes and relationships.
Query performance is managed by an integrated retrieval engine that includes a built-in dynamic optimizer. This optimizer looks at the query and estimates the fastest path to resolve it. Because both the RDBMS and the full-text engine are from IDI and are integrated, a single query step is used. In other products, a single request results in two queries, which then have to reconcile.
In addition, query performance can be enhanced by changing the indexing strategy or, since multiple indexes are supported for a single collection of documents, by adding new indexes.
Application Integration
IDI positions BASIS DMS as a document management application development platform. The bulk of an application is generated simply by defining the document database with its storage, document, and interface definitions. All applications built on top of these definitions inherit the application logic automatically. BASIS Desktop, the end-user environment, is written with OLE controls and is designed to be customized, providing a rather generic interface. (See “Using BASIS DMS,” below.)
BASIS also includes an ODBC driver as well as an API set that provides support for a variety of development tools with which customers or resellers can build specialized applications as well as integrate with legacy applications.
Core Library Services
Search and Retrieval
IDI provides its own full-text searching engine, which includes:
- Proximity searching
- Phrase searching
- Full-text search of attribute values
- Thesaurus-based searching
- Character or phrase patterns
- Relevancy ranking based on term-weighting model
A single query can search for documents based on both attributes and full text. And full-text searching can be on both document content and the values within attribute fields. Attribute queries can be based on Boolean statements in combination with full-text searching of the values. (See Illustration 2.)
Searching for Documents from BASIS Desktop
Illustration 2. Users can search for documents based on profile attributes as well as on full-text matches in the same query.
Typically, a query runs against a single document database. Currently, there is no way for a single query to cross servers. But there are two methods for joining multiple document databases that reside on the same server to do a combined search:
- Views. An administrator can define a view that actually spans multiple databases.
- Joins in Applications. Using the integration tools, a database join can be executed from a front-end application, combining multiple databases on the same server for a query. In custom front end, you could code a join capability and create, for example, a screen where you can pick multiple collections to search at the same time.
When you execute a multidatabase query, a single query results set is returned. However, this list is not consolidated. Documents are presented in relevance order from one database, then from another. The query results set is more than just a hit list, that is, a list of documents that you can enter. These documents can actually be manipulated by users via the results set. For example, you could change the value of an attribute in all the documents in the set (e.g., change the project name) without opening any of the documents.
NO SAVED QUERIES. One of the biggest limitations we find in the BASIS DMS is that queries cannot be saved. They must be respecified each time. In the WEBserver Gateway environment, queries can be saved as bookmarks.
Version Control
BASIS DMS provides version control on both attributes and content. So, for example, if an author creates a document and someone else creates another version, the system can track the reviser who owns the new version.
Version control is pretty straightforward, but some advanced capabilities, such as subversioning and consolidating different versions, can be added via customization of the document database definition via scripting.
Document Tracking
In BASIS, document activity is tracked via journals. Journaling provides protection against media failures or usage errors, allowing roll-back and roll-forward capabilities for any updates within a transaction. (A transaction is an entire editing session, from when a document is checked out to when it is checked back in.) Both attributes and content are protected by transactions and journaling of the transaction. This even works when documents are deleted.
Activity journals are provided that monitor end-user activities, such as check-outs, updates, and others. Access to the journals depends on permissions. Also, in the Web environment (described in the “Internet/Intranet Support” section, below), a journal is maintained of all Web activity that touches the document database.
Archiving
BASIS DMS supports archiving in two ways:
- An aging function can be associated with attributes in a document, specifying how long a document is active. When the document becomes inactive, it is still housed in the collection, but it becomes inaccessible to all but administrators or users with permission to see “expired” documents. The logic of aging is created in a view, but it is often based on what is called a virtual attribute, which is not a specific value, but a value calculated from other attributes, such as “last access date” minus “today's date” compared to “predefined life span” of the document.
- Archiving can also be done by a batch dump and load of expired documents from one database to an archive database. This is a server-based scripted function. Administrators can also set up an archive date structure by document type. This, too, would be a scripted function.
Although a number of sample scripts, including some archiving scripts, are provided, we would like to see an explicit archiving capability available via the BASIS Administrator front end. It seems to us that archiving is a common enough action to warrant becoming a regular feature of the product.
Filing Hierarchy
BASIS does not provide a navigable filing hierarchy for browsing for documents à la File Manager, but you can create a filing hierarchy for establishing relationships among documents. By using folder attributes in a document type, you can group documents. The administrator would then provide a list of available folders, or users could define their own folders if the attribute is left unrestricted.
Although folders are not designed for browsing through your documents, they can become very useful when creating compound documents. (See “Support for Compound Documents,” below.)
Document Profiles
As stated earlier, each document can contain up to 500 attributes, and each document database can support up to 4,000 different document types (attribute sets). These attributes can support one-to-many relationships, that is, a single field can have multiple values. In a language field, for instance, the values could be French, Italian, and Arabic. (Certain other products, such as PC DOCS, offer this one-to-many capability only in special fields. BASIS offers it in any attribute field.)
ATTRIBUTE ONLY DOCUMENT TYPES. Because it is built on a relational database model that can store and represent complex field relationships, BASIS provides a lot of flexibility in creating attributes (which can be done only by an administrator). For example, you can have document types that are attributes only, with no associated content. These are useful when establishing relationships among documents and other information maintained in the database and when determining access rights to documents.
For example, let's assume three document types: author, article, and abstract. The author type contains attributes only, which describe hundreds of parameters related to an author. It is, in essence, a database list of all your authors. In the document database definition, the administrator would create associations to document types. So each author is associated to certain articles, and each article has an associated abstract, all based on field joins—a database relationship.
This comes in handy when a view is created for each type of user. For example, systems administrators wouldn't need to deal with articles or abstracts, so they just get to see and manipulate author document types. Cataloguers, however, would need to see all three types but would only get to edit or create abstracts. Authors would see only the articles to which they are associated.
VIRTUAL ATTRIBUTES. BASIS also supports attributes that are derived from the calculation of a number of other attributes or from information from the front-end application. So, for example, an “archiving date” can be derived by looking at the “last access date” and adding the value of the “document life span.”
Advanced Features
Support for Compound Documents
Workflow
When documents are routed for approval, a list of three options is included:
Using BASIS DMS
End-User Environment
THE BASIS DESKTOP. Out of the box, BASIS includes the BASIS Desktop, a network-based client for querying and library management. BASIS Desktop runs on Windows 3.1, 95, and NT. Desktop features include:
- Document Search and Retrieval. Users access documents by searching for them. There is no list of the last x number of documents or a default list of “my favorite” documents for instant access. A front-end form for searching is provided based on the document views to which you have access. When you select the collection (document database), the available attributes for searching are displayed. You then select operators from a context-sensitive list and fill in the field values. You cannot join databases in this front end. In fact, you can only query one predefined view at a time, typically representing one document type.
- Document Check-out/Check-in and Viewing. A document must be checked out to edit or to copy, although it can be viewed without checking it out. BASIS DMS supports a variety of viewing formats through a number of integrated viewers. The document could also be viewed within its native editor in read-only format. When you view a document, you also see all attributes to which you have viewing rights. In fact, if you have permission to modify these attributes, you can do it from a view rather than having to first check out the documents. This is accomplished by “checking in” a viewed document. When you check in any document, the attribute list becomes active and, as such, can be edited. However, as a safeguard, if you try to check in a document that you haven't checked out and it is already checked out to someone else, you cannot do any modifications of attribute values.
- Inbox Access for Routed and Shared Documents. Any document that has been routed to you will appear on the Inbox list and can be accessed from there. There is also a view of documents that you have routed to others.
The user interface (UI) for the BASIS Desktop is very rudimentary. It's not difficult to use, but you do have to go to the menus fairly often, and, even though search screens can have fields that include lookup tables, these aren't implemented with drop-down boxes, requiring you to go to another window display.
The bare-bones nature of the UI is justified by IDI because, remember, BASIS is a document management application platform and is designed to be customized. Still, we would like to see some enhancements to the default interface, thus allowing developers to start customization at a higher level.
BUILDING ALTERNATE FRONT ENDS. Customers can also choose to build customized front-end applications that are seamlessly integrated with BASIS DMS using APIs, Active Controls, and/or ODBC development tools. Thus, users can, for example, be working in an application such as PageMaker and have all documents accessed and managed by BASIS.
In fact, in Version 8, IDI has included all the coding and commands for integration with Microsoft Office applications. Users working within Word, Excel, PowerPoint, and the like will have access to all BASIS DMS commands from within the application menus.
System Administration
BASIS ADMINISTRATOR. The BASIS DMS also provides an out-of-the box front-end environment for administration of the system. This is used by the administrator—or anyone with administration permissions—to define the document databases, including attributes, views, etc. Via this easy-to-use front end, administrators can also batch load documents into the system, load thesaurus databases, and do all user administration and maintenance, including adding/deleting users and assigning access permissions.
For more advanced administrative duties, such as task automation (e.g., scheduled archiving, automatic backups of collections) or more CPU-intensive actions (e.g., system recovery), IDI provides its own standard 4GL command procedure language.
THE ROLE OF THE ADMINISTRATOR. It seems to us that there are really two sorts of administrators in the BASIS world:
- A librarian (our word, not IDI's) is an administrator who understands how documents should be accessed and managed. In the secure and controlled document environment of BASIS, this person “owns” the document collections. Unlike other software products, where the administrator tends to be a technologist or database guru, the librarian is more likely a businessperson charged with maintaining the integrity and security of the documents. The librarian does most of his or her work via the BASIS Administrator front end.
- A technical administrator is the individual who handles the scripting responsibilities and system troubleshooting. This technologist uses the scripting language primarily.
Internet/Intranet Support
Accessing Document via the Web
IDI was one of the first document management vendors to support Web access of documents. The BASIS WEBserver Gateway was first introduced in 1995, and a second version was released in June 1996. And, with the release of BASIS DMS Version 8 in November 1996, IDI enhanced its WEBserver Gateway capabilities significantly. Until then, users could query for documents and retrieve read-only views of the documents, as well as add new documents to the BASIS document databases.
With the new version, IDI is providing full document management capabilities, including document check-in/check-out, versioning, and others, via predefined CGI scripts. These capabilities are accessed via the Corporate Information Centre (CIC), IDI's Web-based context for intranet corporate publishing. Although you can still query and retrieve viewable documents directly from a Web browser, in order to access the new capabilities of Version 8 from a browser, you must explicitly take the CGI scripts from the CIC and run them through the Web server. These scripts will become automatic (native) to the Web server by early to mid-1997.
The CIC—Providing a Context for Web Publishing
KIOSK-LIKE FRONT-END NAVIGATION. With the Corporate Information Centre, IDI is providing an innovative context for the publishing of corporate documents. The CIC front end provides easy Web access to corporate documents in what could be considered a kiosk model, where users can easily navigate to the appropriate information without knowing the location of any of the source documents. (See Illustration 4.) The CIC is Web neutral, leveraging both Microsoft and Netscape out of the box.
The BASIS Corporate Information Centre
Illustration 4. The BASIS CIC provides a framework for creating “kiosk”-like access to corporate information on the Web.
The CIC is actually a prototyping tool for building this corporate publishing environment. A sample CIC comes with the product, which can be used as a starting point for rapidly developing customized solutions. This sample includes a front-end user interface for accessing and navigating through the documents. All front-end screens are in Hypertext Markup Language (HTML) format and, as such, can be modified using any standard HTML editor. Also included in the CIC are examples of how Java scripts can be used and how to incorporate advanced HTML formatting techniques such as frames and tables.
PREDEFINED DOCUMENT DATABASE DEFINITIONS. Key to the CIC are predefined database definitions for managing common types of document collections, including:
- Policies and procedures manuals, which are a collection of documents addressing corporate policies. (See Illustration 5.)
- Research information managements, which are a mixed bag of document types, including articles, abstracts, graphics, and others. The sample database categorizes this research information by project.
- Technical documentation, which is similar in structure to policies and procedures, but including a binder metaphor which, like a folder, acts as an organizational aid, containing relationship information but holding no content.
- Competitive information, which provides a procedure for hooking news feeds into corporate mail accounts.
- Knowledgebase, which is a centralized discussion database for collecting comments and documents from employees. Eventually, these will become threaded discussions. In the current version, the knowledgebase is basically a bulletin board where documents and/or comments can be posted.
The CIC basically gives you a template-driven default interface against collections managed in BASIS. The interface comes with predefined navigation buttons based on the default database definitions, such as the policies and procedures manuals. You have to explicitly change these if you don't want to use them, which is why this is considered a prototyping tool.
Policies and Procedures Template
Illustration 5. The BASIS CIC provides a template for a policies and procedures document database. Customers who follow the model of creating a compound document relationship among related document components can take advantage of the navigation and security granularity provided by the system.
Presupposes Compound Document Structure. The predefined database for, say, the policies and procedures, presupposes that the structure of the manual is a collection of related, but separate, documents. And, indeed, many organizations do structure their procedure manuals and technical documentation in this way. IDI strongly believes that the CIC provides the foundation for universal database definitions for these commonly-used compound document types. However, if your organization doesn't follow this model but creates large manuals with multiple subsections within a single document, navigating through the CIC front end is limited.
Limited Navigation for Single Documents. You see, navigation is done, naturally enough, via hyperlinks among the related documents. And a table of contents is automatically generated based on this relationship attribute in the document database. If your document is not structured as a BASIS compound document, you will be able to access it from the CIC, but there will be no table of contents generated and no internal navigation available other than searching for content.
Supports Rapid Development and Implementation. Assuming that you do structure your corporate information modularly as related documents, the CIC provides a number of advanced capabilities to help users navigate through the collections, including table of contents generation. When the BASIS administrator loads the documents into BASIS, he or she indicates the hierarchy of documents up to 10 levels deep. The system can either automatically generate a table of contents based on document title, or the administrator can specify in an attribute what should be included in the table of contents for that document. Also available in the policies and procedures manual and the technical documentation databases is a navigation tool to a frequently-asked-questions document, which must be created by the administrator.
Customers who manage their corporate documents in this fashion have found that they can set up a completed CIC in a matter of a few months. IDI is enhancing the CIC product, aiming toward a goal of getting a working prototype in one week, combining the software tools and IDI's professional services group.
Marketing Information
Channel Information
BASIS Document Management System Version 8, which includes the BASIS WEBserver Gateway and CIC, became available in November 1996. It is sold directly by IDI in the United States and in Europe. IDI has distributor partnerships internationally in South America, Australia, Asia, and the Pacific Rim.
BASIS is also sold through regional solution partners and other system integrators in vertical markets, including government. There are a number of value-added resellers who specialize in developing custom applications in BASIS DMS.
IDI works with distributors and solution partners to provide customer support via an international help desk organization. The company also provides field support and consulting services internationally.
BASIS Pricing
The standard BASIS software for client-server Unix, VMS, and NT environments is priced at $xx,xxx for the initial license fee for five concurrent user licenses with unlimited application usage. This includes the BASIS Document Manager and BASIS Client Suite (BASIS Desktop, BASIS OpenAPI, and BASIS ODBC-SQL Driver), as well as the first-year maintenance.
Pricing for the BASIS Intranet Solution for Unix and NT environments is $xx,xxx for the initial license fee for five concurrent users with unlimited application usage. This includes BASIS Document Manager, BASIS Client Suite, and BASIS WEBserver Gateway, as well as the first-year maintenance.
Single application licenses and unlimited usage enterprise licenses are also available upon request.
Future Plans
Enhanced Enterprise Publishing
IDI is focusing on its Web strategy and plans to build on its enterprise publishing model. The company plans to introduce full document management capabilities from a Web browser both via the CIC front end and as a direct BASIS client. Web users will also be able to participate in document-routing as currently offered, as well as in workflow applications via partnerships.
The BASIS WEBserver Gateway will also be enhanced to support a more dynamic publishing model, where Web pages are automatically generated based on who is accessing them and in what situation. Currently, everyone (who has access) sees the same presentation of a document via the CIC.
Concept-Based Retrieval
Another area targeted for enhancement is retrieval. BASIS DMS currently supports both attribute and text-based retrieval. In the future, concept-based searching will be supported via morphological indexing. This means that, instead of searching on an index of words, you would search on an index of ideas. For example, if you type in a phrase such as “Intranet Document Management,” you would retrieve documents containing that topic, even if those exact words don't actually appear in that order in the document.
Rapid Application Development
IDI is also dedicated to building on its rapid application development capabilities. Modeling the document structure in the relational database already yields a significant portion of application functionality, so developers really spend most of their time creating front-end applications for the users. The company hopes to make this task even easier in the future.
Conclusions
Controlling the Vault
Unlike many other document management systems available today, BASIS imposes rigid access controls on documents and does not enable ad hoc document retrieval. Obviously, this level of secure control is not required by all environments and is most appropriate in settings where tight security must be imposed for “mission critical documents.” In the BASIS world, the company owns the documents, not the writers or collaborators. The BASIS administrator has ultimate control over who can see what information as defined in views. Often, IDI has found that customers have implemented BASIS to manage secure document collections and have chosen a competitive product, such as PC DOCS, to address group-owned document management.
IDI explicitly positions BASIS DMS first and foremost as a document management platform rather than an application. Because of this, customers can create a variety of different document management applications, but the expectation is that these applications will be very customized and well-controlled solutions.
The value of such secure document environments is obvious, but there is a trade-off in the amount of administrative set-up required. The BASIS administrator must predetermine what each user can and cannot see and then define that access in an explicit view. This means that the administrator must truly understand how all documents are used by all levels of users. In many companies, there isn't one person who “owns” all this knowledge, so the administrator must be continually checking in with other decision-makers to determine document policy.
Because of this, it seems to us that a BASIS administrator must spend more dedicated time working on the database management system than on “office” document management systems, even after initial setup. If users identify new ways in which they need to access documents or attribute information, the administrator must build new views.
Make It Easier to Play
Many organizations require the vault-level security control and want a dedicated librarian (administrator) to manage mission-critical documents. However, we would like to see more capabilities made available to nontechnical administrators. For example, many capabilities now available only through scripting, such as batch archiving, could be surfaced into a standard feature within the BASIS Administrator front end.
There are also some capabilities that must be added to BASIS in order to keep it competitive. Number one is the ability to save queries in BASIS Desktop! Another needed capability is the support of distributed databases and easier multidatabase queries.
Expand the CIC for Legacy Documents
We are impressed with the concept of the CIC. Providing a rapid prototyping tool for developing Web-based kiosk-style access to published documents is definitely valuable in this era of intranet publishing.
We would like to see, however, the ability to “retrofit” documents that are not defined as separately managed sections into the predefined document databases for things like policies and procedures and technical documentation. An administration tool for splitting up these documents easily so that all the navigation features can be used to advantage would be very useful.
Getting the Proper Message Out
IDI is heavily promoting its intranet publishing solution, as well it should. However, we believe that the company is missing an opportunity by not stressing its secure document control. Competitors such as PC DOCS and Saros promote more open access to documents. Documentum, which is closer in capabilities, focuses more on the document-based processes than on “securing the vault.” We all would like to believe we live in a world where democratic access to information reigns supreme, but, in truth, there are many scenarios where you would want your documents locked up tight, with access privileges tightly controlled by someone whose job it is to make sure the information is secure.
Information Dimensions
6600 Frantz Road
P.O. Box 8007
Dublin, OH
43016-2007
Ronald Lee
Product Marketing Manager
Phone:
614.761.7384
Fax: 614.761.7290
E-Mail: rlee@idi.oclc.org
Internet: http://www.idi.oclc.org/
