I was involved in an internal meeting here in Oslo today, where I inexpertly presented the work we’ve been doing on cataloguing interfaces. I made a video of the same recently, which I hope shows the state of play from a week or two ago.
Two colleagues made two very different, but interesting “Freudian slips” today:
- “Using an entity based model adds more strings to our bow”
- “The publication — sorry — cataloguing interface…”
I wasn’t alone in finding these amusing; for me, they say something about cataloguing and it’s role in the coming system.
Adding strings isn’t what cataloguing should be about at all, but looking at the current crop of editors, you’d be lead to believe that it was. Lots of lovely fields massed up for us to fill with who-knows-what.
What we want is entity based cataloguing — when do we want it? After we’ve finished adding these strings.
Adding real strings to our bow, we’re creating interfaces that define a workflow that makes cataloguing about linking things together — discovering relationships and verifying the definition of these relationships.
This is the antithesis of MARC-based workflows, which revolve around long lists of fields to be populated with formatted strings. I was bemused to read that someone had referred to the use of MARCEdit as radical — it’s an escape route from tragic interfaces, but text-editor functionality is far from radical.
And it’s here that the second statement comes in — the workflow we’re in the process of defining is more akin to a publication interface in a CMS than cataloguing interfaces in traditional ILSes. The point of our cataloguing interface is to provide what is presented to the user. The cataloguing functionality is tightly bound to this task, making a radical departure from the task of producing portable MARC records, which is the apparent focus of MARC-oriented systems.
There is very little in our system that is geared towards house-holding or librarian tasks; what is there is there because the user needs it to do their job. Of course, some concessions need to be made and yet these are surprisingly few and far between. Much of what is done in MARC is pointless from a user’s point of view, and it turns out that it is also pointless from the library’s point of view.
Even with our scaled-back cataloguing, it’s possible to export valid MARC records (which we do, based on the linked data we actually use for data storage) and support the workflows for lending, ILL and statistics.
Yes, we use linked data, but the cataloguer would never know because it isn’t relevant to them — how the data is structured is irrelevant, what is important is that the data supports the functionality the user needs in an elegant way. I’d argue that a simple framework that makes it easy to consistently re-use data is elegant.
Compare that with MARC.