Of strings and Freudian slips

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:

  1. “Using an entity based model adds more strings to our bow”
  2. “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.

Advertisements
Posted in Uncategorized
3 comments on “Of strings and Freudian slips
  1. This is indeed a quite radical departure from traditional cataloguing… In the example of your video, does it mean we are taking from granted that the English edition of the book does not exist yet, which is why we need to add it? Would the cataloger be alerted if such a manifestation of the work existed already? Also, is the data entered by the cataloger fed back to the original linked data source, so that it can benefit someone else?

    • brinxmat says:

      Thanks for watching!

      Indeed, we took the non-existence of the English edition for granted — I’m not sure how the interaction designer has imagined the “you’re attempting to re-catalogue something that already exists” experience and it’s a good point. We’ve actually changed quite a lot of the workflow in the last month…I’ll ask the interaction designer what the precise response to this question should be…

      To answer your third question, the master data for work and manifestation is linked data; the manifestation data in Koha is synchronised from this. Koha is master for item data only. Koha data also has an RDF representation, which we use when generating the patron view.

    • brinxmat says:

      So, it seems that the problem of existing manifestations is solved by dint of workflow — the acquisitions workflow weeds this out. But, following discussion prompted by your question, we’re looking at adding a simple look-up in the database to check pre-existing manifestations so that the cataloguer is notified. The data is all there, so there is no issue doing this — so why not?

      I’ll post a new video soon that shows the current iteration of the cataloguing interface — we all agreed that the video from two months ago seems very old.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s