To RDA or not to RDA

Over the last few years there has been much talk about RDA in the library world. As an ILS vendor we are at times approached by our clients with questions about what RDA could mean for them and whether or not they should consider adopting it. For those of you who are curious here is a quick summary of our current and evolving perspective on RDA, what we are doing about it and some helpful links for those who want to learn more.
As you may know, RDA is a content standard that describes how to catalogue, but it is not an encoding standard (e.g. MARC) or display standard (e.g. ISBD), which means that as a vendor there is some interpretation required on our part.
Though SydneyPLUS has sent staff to conferences and we have staff taking workshops on RDA, one challenge we keep facing is that we have yet to see a comprehensive checklist that describes all the features an ILS system needs to have to be RDA ready. The best source we have found so far is the Full Report: Report and Recommendations of the U.S. RDA Test Coordinating Committee where the Library of Congress does make some recommendations to vendors on how to prepare for RDA (page 23-24).
Upon reviewing the recommendations in the report, however, we find that we are already compliant with RDA. Below is the list of functional capabilities that the report identifies as necessary to be RDA ready along with our answers to them.

1.“Additionally, integrated library systems changes should include… the new MARC tags…”

SydneyPLUS already supports the new MARC tags 336-338 through a configurable MARC Map.

2.“Use of buttons and checkboxes to more easily handle on/off elements.”

SydneyPLUS already developed an optional module called Views Designer that allows clients to create custom record views or screen layouts which include the ability to have checkboxes, radio buttons, etc. Furthermore, the Views Designer also supports field groups that can be expanded or collapsed just like RDA requires.

3.“Future applications where linked entities will only require one change (e.g. …attributes of the creator are only stored in one place)”

SydneyPLUS clients already use linked entities, such as authors, that store all attributes in one place and require only one change. For example, more than one “Book” can link to the same “Author.” A change to the Author is reflected across the whole system where the author is used.

4.“Systems that can ingest metadata in a variety of formats.”

SydneyPLUS has made it possible to import and export data in a variety of formats. For example, we have a module that allows us to import and export CSV and XML with a configurable map.

5.“In the longer term, vendors can be exploring innovative approaches… for exposing RDA data to the Web.”

SydneyPLUS has also made it possible for search engines to crawl its data through the Site Map module exposing RDA data to the Web. In addition, we also have integration with SharePoint which provides even further exposure.

6.“One of RDA’s goals is to be readily adaptable to newly emerging database structures...”

SydneyPLUS is readily adaptable to new emerging database structures through its kmBuilder technology. SydneyPLUS was one of the first ILS systems to support a relational database and we remain one of the only systems to allow clients to be able to modify the database dynamically through a simple user interface. SydneyPLUS kmBuilder easily allows us to create fields and change field names to support changes from AACR2R to RDA.

In general, because the RDA standard itself requires interpretation and because of the customizable nature of SydneyPLUS, we see that the steps needed to implement RDA will vary from client to client. Take the example of MARC records. If a library imports or exports to MARC or uses Z39.50, then it will need to modify MARC Mapping tables and create new fields to take advantage of the data for RDA’s new MARC tags 336, 337, 338. This however will only apply to those libraries using MARC. In another example, since SydneyPLUS libraries are able to customize different field sizes to suit their unique needs, field sizes can vary from client to client. As a result, some clients may need to increase their field sizes to accommodate RDA data requirements. Though such issues are not large, they should be reviewed before proceeding with an RDA implementation.

When deciding whether or not to adopt RDA, librarians should carefully consider the costs versus the benefits of the standard for their own libraries and ensure that it’s in line with their supporting organization’s strategic plans for the future. In the meantime, we feel we are ready to support the implementation of RDA with any client approaching us to do so. One last thought is that in SydneyPLUS both AACR2R records and RDA records can coexist. This means that for those libraries that would like to experiment and evaluate before considering full fledged adoption, it is entirely possible to do so.

Of course, as a vendor we would love to hear from those of you who are considering RDA. Questions that come to mind are:

1.Does your library have a specific question about RDA to us?

2.When does your library intend to adopt it?

3.How is your library preparing its staff to implement RDA?

4.What benefit does your library see to implementing RDA?

We look forward to your responses. Send your emails to sales@sydneyplus.com.

Here are some resources we hope will help if you want to learn more about RDA.

- RDA Toolkit (free trial): http://www.rdatoolkit.org/trial

- Library of Congress: http://www.loc.gov/aba/rda/

- MARS Authority Control: http://ac.bslw.com/community/blog/2009/09/more-rda-resources/