In response to a long-running thread on RDA-L.
It turns out form/format/media/content/carrier are really complicated to understand.
It turns out that most people’s internal mental models for these things in fact aren’t internally consistent at all (even librarians). Which is kind of why AACR2/MARC turned into the mess it is around this stuff. All those slashes in “form/format/content/carrier” are there because the naive mental model isn’t even clear about what the different distinct qualities/aspects/axes are we’re considering, it’s a big overlapping muddle.
Which is fine if all you want to do is display exactly what’s entered in the record, but a huge challenge if you want software to take action based on form/format/content/carrier, including action like localized display labels or filters.
So RDA (and Karen Coyle’s efforts) try to make an internally consistent taxonomy for these qualities (content type; media type; carrier type), that can be actionable by software, including mapping to display labels that make sense for a given collection/user group at a given point in history.
A lot of work actually went into the taxonomy used by RDA. I think there was even a report by a working group, that did lots of analysis and evaluation of prior work, but I can’t find it now (was it FRBR-related?). If we could find it, it might shed some light on things for people trying to figure out what’s going on.
Which doesn’t mean what they came up with is perfect, but probably means you can’t easily do better without a LOT more work.
Still, what’s there is confusing. If there is an ‘impedence mismatch’ between what’s in RDA instructions and what ends up in MARC, as I think Karen is suggesting, that certainly makes it even more confusing.
The rationalization of taxonomies for these qualities is potentially one of the biggest benefits that RDA can bring — but it’s also one of the most confusing, and misunderstood. The work that Thomas Brenndorfer and Karen Coyle have done to understand and explain it is invaluable.
But this is potentially something the JSC should prioritize, and actually fund (or find a grant for) someone (Karen or Thomas?) to work on improving the situation of. It’s a big enough issue that it might take some concerted and funded effort to fix, and it’s got large impact on the ultimate success of RDA.
Efforts that might help
Here are things that I think can make RDA’s approach to these issues more understandable; more likely to be implemented; and implementations more likely to be successful:
1) Provide a good overview explanation of what the point and principles of RDA’s content/carrier/form vocabularies are. Provide a link to the research paper that established them (if I’m not misremmebering the existence of such a paper), and a summary of it. Provide some examples of things that we’d want software to do but were infeasible under the AACR2/MARC muddle, justifying the rationalization of the vocabularies that RDA does.
2) Make small tweaks to the RDA vocabularies, if deemed neccesary based on the actual experience of trying to work with them post publication of RDA. Doing a complete overhaul (for instance changing the taxonomic categories) is not going to be feasible on any reasonable timeline, but small tweaks based on experience since publication may be called for. (Either for errors in the original, or just things we’ve learned by experimentation since publication).
3) Analyze the serialization of the content/carrier/form vocabularies in MARC, make recommendation to MARBI for improvements on what’s already there. Again, MARC21 has been changed to accomodate these — but the changes may not have been quite right or sufficient, there may be additional tweaks that are now needed based on further analysis/experience. Lessen the ‘impedence mismatch’, so you don’t need to translate from RDA to MARC when entering in MARC; make sure no important information is lost.
(In particular, i worry that when there are multiple 336/337/338 sets in MARC currently, there is no good way to tell which 336 goes with which 337 goes with which 338. This is a huge loss of information, which reduces the actual benefit of this rationalized encoding while still leaving a large cost-of-switch!)
(I also worry that the liberal allowance for free-text entry for content-type/media-type/carrier-type will ALSO limit the benefit of this switch while still leaving a large cost-of-switch. The point of rationalizing these vocabularies is to allow software actionability, but you don’t get that with arbitrary non-controlled free text entries.)
4) Provide a recommended basic starting algorithm for translation from RDA’s content-type/media-type/carrier-type to user-display strings, that, as a base level starting point, is more-or-less consistent with AACR2. This is a non-trivial thing to figure out for oneself. If RDA can provide a basic suggested algorithm, this will make it more likely for people (such as ILS vendors) to implement appropriately, and make it easier for everyone understand what’s going on with the content-type/media-type/carrier-type vocabularies, their intent. It should be clear that this algorithm is not a requirement or even a standard, it’s just one starting point RDA provides to ease implementation.