We had a very frustrating discussion about extending/using MARC to encode all the things we need to encode. This discussion was largely driven forth by the feature-driven development method that has been chosen, which favours incremental development of existing components over just doing stuff because you have experience.
Because we’re working with with the non-library consultants (yes, I know, I’m not library either, but bear with me), it is sometimes horribly clear that we have long-winded discussions where we’re talking past one-another because we’re putting different contexts into the words we use. Because we’re used to having sloppy definitions in libraries, we don’t notice that something is very skew-whiff before it is far too late.
We were looking at implementing the “Work” concept in Koha, not in the sense of FRBRising Koha, but in the sense of simply adding a concept of Work to link together the records in the database. In order to do this, three hypotheses were provided:
- Add a Work authority, basically the standard title and putting this in a local field
- Add a work record and link other records to this
- Mess with Koha’s table structure to support Works
In a sense, (1) and (2) are facets of the same thing: mess about with cataloguing practice a bit in order to do a simple thing. The problem with this approach are obvious — you’re creating local practice based on an understanding that the fields/records you’re manipulating are unfamiliar things in a very familiar background.
In (1), the new authority introduces something to the catalogue that in essence already exists and will be familiar to most librarians — moving it someplace else in the system and using it as a key; which is a problem as it’s really not actionable — it’s a string — and you’re going to have to mess about with several UI levels in order to get it to make any sense (rather than say return a hit list in search — if that’s your aim, fair enough).
In (2), you’re introducing a new use of the record, which will not be familiar to most —it might be recognisable to those who have used cataloguing practice along the lines of BIBSYS, where multivolume content has a record of its own and then a linked record for each volume. This requires regulation of cataloguing practice that is slightly more coherent, but you’re still doing something odd, but at least you have an entrypoint that you can populate with data about the Work and leave the records to represent manifestations. You’ll want to fix the UI so that there are fewer clicks to get what you want.
The benefits of both approaches are that you in many ways keep circulation, cataloguing and search systems largely intact, even if you’re using them in novel ways. The problems of MARC’s stringiness as implemented in Koha are not resolved; the data is simply not actionable unless you’re willing to take a leap of faith.
In (3), you’re admitting that records are never going to be FRBR entities and that you need to work a bit harder; this seems to have been done before. There is a lot to take in here, a completely new view on the library system…which begs the question, why base it on Koha at all if the benefits — as seen in the cases above — peter out almost immediately? You’re forking an open-source project to achieve a small win — adding a new, unfamiliar structure to the heart of the application.
What was obvious in our discussion was that several understandings of Work were at play. Also, there were different interpretations of what we were looking at in the system — a record could be a record, or a manifestation; the role of the item, and so forth. What becomes clear is that we were revisiting ideas that we abandoned long ago and struggled to remember the exact details of why, which caused much frustration.
As a thought experiment, it may have been a good idea, but the fact of the matter is that that chapter is dead. Why is it dead, you might ask, because we’re trying to do something more than bodge Work concepts on top of the existing system, we’re trying to incorporate non-library resources into our data without manual data entry; we’re trying to create distributed systems that use typed data rather than monoliths that encode everything as strings.
In the end, while I’m sure this sounds like the MARC must die mantra, you’ll remember that I’m not a follower of that doctrine – I say let MARC do what it does, but give it neither succour nor actively kill it. Until we have a better solution, Koha — and MARC — have a place in our architecture, but not one that has much to do with Works.