RIB Version 2.x is a complete rewrite of the version 1.0 code and makes use of the World Wide Web (W3C) Consortium's eXtensible Markup Language (XML) 4 standard to achieve maximum interoperability. XML is a new standard for structured documents that promises to revolutionize the way metadata are exchanged on the Web. XML is already supported by many Web applications, including the newest generations of Web browsers and it provides a way to structure documents. Because RIB has adopted this standard, many other applications is able to parse the data maintained by RIB. By using XML, the metadata generated by RIB is usable by the broader Web user community.
The most substantial improvement in RIB version 2.x is a totally revamped administration interface. In the previous version of RIB, the interface used HTML forms which could be cumbersome and tedious. At the time RIB 1.0 was implemented, Java and JavaScript were not used because of reservations about security and portability. Now that these technologies have matured considerably and become more acceptable, they have been embraced throughout the design of RIB. They provide a more flexible and intuitive interface. However, RIB 2.x does not require Java or JavaScript in order to view the catalogs that it creates.
RIB version 2.x supports a much greater variety of data models than did the previous version. The Basic Interoperability Data Model (BIDM) served as the default model for previous versions and it is an IEEE standard (1420.1-1995) for cataloging interoperable metadata on the Internet. While the BIDM remains the default data model, RIB 2.x extends the capabilities of version 1.0 by allowing the repository administrator to add or delete entire classes from the data model. In effect, the repository administrator can stray completely from the BIDM and design a new data model from the ground up. This improvement makes RIB capable of managing practically any type of Internet-accessible resource. While this improvement opens the door to an entirely new range of applications for RIB, care must also be taken to prevent the proliferation of redundant data models. Interoperating repositories should follow the example set by the BIDM standardization effort and approach the data modeling stage of repository development with great care.
With RIB version 2.x, any attribute in a repository's data model is able to use a controlled vocabulary. A controlled vocabulary is a predetermined set of terms that are used for the value of an attribute; any other values are not allowed. The previous version of RIB used a controlled vocabulary for the Domain attribute in the Asset class. Just as the Domain attribute was used to sort catalogs in RIB 1.0, any attribute that uses a controlled vocabulary is usable for sorting catalogs in RIB 2.x. The sorting attribute is adjustable dynamically, thus allowing the creation of many different organizations of catalogs from the same set of information.
The flat file database underlying RIB 1.0 limited the ability to make sweeping changes to large collections of data without a great deal of overhead. RIB version 2.x interfaces to a database backend to make data management much more reliable and straightforward. SQL commands are used by RIB to perform updates to large numbers of records in an optimized fashion. Using database concurrency control helps prevent race conditions in multi-user environments where the same data might be modified simultaneously by different users. A database makes RIB's data more portable in that the data can be moved to different locations without changes. The data can also be easily exported to other applications via standard SQL.
Many users of RIB version 1.0 asked for a feature that would enable them to add new data to a holding area before it appears in their HTML catalog. This feature enables them to accept input from sources not deemed completely reliable, and to check that input before incorporating it into their catalog. This feature is included in RIB 2.x in the form of an "object approval" operation. Whenever data is entered into the RIB system, it is marked as "not approved" by default. Until the data has been explicitly approved, it will not appear in the catalog, nor will it be available for interoperation. This feature can be disabled if it is not needed.
Another improvement in RIB 2.x is its interoperation facilities. Previously, interoperation was only possible on a per-object basis. This meant that in order for repositories to interoperate, they had to manage individual pointers to each other's data objects. This fine-grained level of interoperation was difficult to manage because it forced administrators to constantly monitor each other's collections and to manually add or remove pointers whenever remote objects were added or deleted. Interoperation becomes much easier to manage in RIB 2.x because it is handled on a per-repository basis. Repositories that wish to interoperate need only retain a pointer to each other's repositories. Each repository dynamically generates a list of its objects and when they were last modified. Other repositories poll this list and update their collections whenever necessary.
The HTML catalog generation feature in RIB version 2.x also includes many improvements. The table of contents for the catalog is now organized in a fashion that Web users are more familiar with - instead of listing the entire table of contents on one page, it is categorized into separate pages. This improvement eliminates the cluttered look that was apparent in larger RIB 1.0 catalogs. A "What's New" feature has been added to the catalog to automatically track new additions to the repository and allow users to query this listing based on the number of days that they wish to look back. Another improvement to the catalog is greater flexibility in the views that may be constructed from the underlying database. RIB 1.0 always generated catalogs for the Asset class, sorting by the Domain attribute. With 2.x, catalogs can be generated based on any class and sorted by any attribute that contains a controlled vocabulary. Management of the HTML catalog is now easier because the administrator does not need to ask RIB to regenerate the repository's table of contents after making changes to the database. Since all HTML pages are dynamically generated, any changes made to a repository are immediately visible in the repository catalog, provided approval has been granted via the object approval function.
