The other day I attended a NETSL program called AACR2 and RDA: Key Differences, presented by Steven Arakawa from Yale University. It was a wonderful presentation. Steven had a session on theory followed by a hands on session. Steven integrated in addition to everything else how RDA is evolving. One aspect of RDA that Steven highlighted and that hasn’t changed much since its inception is that RDA was designed to adaptable, flexible, among other things, especially in regards to format, encoding, and digital environments.
I have been thinking about RDA for digital collections for some time. These catchy phrase words of adaptability, flexibility or currency as found in the scope and purpose of RDA are indeed quite intriguing because it leads one to believe that RDA can be used for any type of project involving data content standards.
Indeed, I think that RDA can be used as a data content standard. But is it appropriate to use RDA for most types of digital collections?
In terms of digital collections that I work with, I wouldn’t be inclined to use RDA. Let’s take the example of dates. Brackets can be used with dates. A good example is when a publication date is being inferred based on a copyright date, then you would add brackets to the publication date. If you want to include the copyright date, you would write “copyright” before the date or use the copyright symbol before the date. This is a good way of communicating special cases about a date in a succinct way. So, why wouldn’t this appeal to all types of digital collections? Not everyone on the project might understand the use of brackets. Your users might not understand the use of brackets. But more importantly, your date becomes an uncontrolled textual string. Of course there are ways to change these date strings to date/time formats such as ISO8601. But why incorporate this extra step into our workflow. Why not do this from the beginning and use the system to help with consistency and accuracy of date data. For example, instead of using brackets, have a drop down menu where the submitter selects the type of date as “inferred” or “questionable” and then inputs a date using a calendar widget that is automatically transformed into a standard date format. Another example is using the copyright symbol or spelling out copyright before a copyright date. Why not let the system display this textual information on the fly, perhaps even in different languages if necessary. Given these two examples, it seems that there is an overreliance on adding textual context that might be better handled automatically. Handling such contextual information automatically might also help with consistency. All dates would be in a standard format and type of date would be stored separately. I wonder if this consistency would also help with migration down the road or even when people needed to qualify dates differently or add to the qualifications.
But what about relationships? RDA is supposed to be great with relationships since it based on relational databases. What if your digital collection uses a platform that is not a relational database? The perfect example is Fedora. Fedora uses Fedora digital objects which contain data streams. Two of the data streams are RELS-INT and RELS-EXT. Depending on the programming available, you can create a number of unique, complex, and interesting relationships between various levels of Fedora Digital Objects. Is this more efficient than RDA’s suite of relationships? I would argue that it is more efficient. First the Fedora relationships are not tied to one particular philosophy, namely FRBR. Just this in and of itself, means that Fedora can be conceptualized according to FRBR or anything else that comes along now or in the future. Perhaps that’s why Fedora has stayed strong as an option for digital initiatives platform. Flexibility is built into it.
But what about the “core” elements that have been determined as core to have access to a resource? Metadata can be gathered in a number of ways. In most digital repositories, the sheer amount of data about resources is staggering. And the descriptive metadata are but a part of that metadata. What is interesting about descriptive metadata is that in general this is created by a person. Such things as titles, descriptions, or subjects can be automated but with problems of accuracy and relevancy. Indeed, it might not be necessary to add a large number of descriptive metadata fields for users to search and discovery a resource. Perhaps this goes to the debate on quality versus quality. But there are 15 core elements in RDA. Depending on your repository and your users, 15 core elements might be overkill, especially if the rest of your metadata (technical, administrative, structural, rights) are rich and enable users to search and discover resources.
This is not to say that RDA should be thrown out with its bath water. Quite the contrary, RDA has some very important instructions for data content. However, it is important to understand what functions your metadata needs to serve and then decide if RDA can meet the needs of some of those functions. And it is definitely worth considering.