RIMMF Technical Notes

On this page [still under construction] are a few notes about the technical aspects of RIMMF.

The development tool that we use to produce RIMMF is called 'Delphi'.
Find out about it here: http://http://www.embarcadero.com/products/delphi

(At present, RIMMF is made with version XE8.)

Inside RIMMF, the interface is largely powered by data-aware components from DevExpress.
Here is a link to their site: https://www.devexpress.com/

Network connections are provided by Overbyte's Internet Component Suite.
http://www.overbyte.be/frame_index.html

Underneath it all, RIMMF is pretty much driven by data stored in … yes, tables, with columns and rows
But all tables are loaded into memory when the program starts, nothing is used from disk.
For this technology we rely on the 'kbmMemTable': http://www.components4developers.com/

The support for RIMMF program menus in different languages is provided by the TsiLang suite:
http://www.tsilang.com/overview.html

The windows installer is provided by InnoSetup.
http://www.jrsoftware.org/isinfo.php

Four 'libraries' are distributed with the program:

pcrelib.dll – http://pcre.org/ (PERL Compatible Regular Expressions)

libeay.dll, ssleay.dll – https://www.openssl.org (OPEN SSL libraries)

tmqXml.dll – MARC Report's MARC21 and MARCXML processing routines

To import/export linked data, we wrote our own code. Because our RDF support is based on the ntriples serialization, this task was not too hard; most of the needed string-handling routines were already in place.

The mapping of MARC to RDA (and back again) is, again, our own code.

MARC Report provides the tools for working with MARC and MARCXML records and files. For the RDA mapping, we implemented a simple syntax and linked each RDA element to one (or more, depending on context) mapping string (these strings can be seen in a RIMMF template if you expose the mapping columns). But after awhile we ran into problems–the basic instructions could not cope with the complex situations MARC presents. For these, alas, we hard-code solutions.

Perhaps the most interesting aspects of RIMMF are not due to code but to the data sources used by the program.

First and foremost is the RDA Registry
'The Registry contains linked data representations of the elements and relationship designators approved by the RDA Steering Committee'. Although early versions of RIMMF did not use the registry, its hard to imagine going back to those days now. Users simply need to know that every time they open a template, whenever they open a dropdown list, view a definition, or flip to a different language–they are using the RDA Registry. Its a brilliant resource and keeps getting better with every update.

Next in line is the RDA Toolkit: http://www.rdatoolkit.org/
For the average cataloger, the Toolkit probably is RDA. RIMMF was the first exemplar (and perhaps remains the best?) of an RDA application being tightly bound to the standards (as manifested by the RDA Toolkit). This integration was pretty much our only focus when we started developing RIMMF in 2012 (a focus which can still be seen in the columns of data labeled 'Entry', 'Source', 'Core', etc., which are present in every RIMMF template)

We cannot go much farther without mentioning ID.LOC.GOV and LC's implementation of an SRU/Z39.50 Gateway (via IndexData's MetaProxy).
One of the neatest things about RIMMF is searching the LC catalog, selecting a title, pressing Import, and watching what happens. The wealth of MARC authority data available today is a resource which is easily consumed by the RDA model, and RIMMF has illustrates how well this transition proceeds. None of this would be possible without a freely available resource using a simple transport¹⁾.

<!–

R-Balls

our own servers

–>