I wrote this back in December 2021, but work's been busy and I only found time to edit it this week. I know I'm a hermit, but I'm sending love out to everyone who's been my friend in library metadata and systems work in the last few years.
I'm back in a software testing role at my library for now. One of the things I need to do is use an app that has an option to tweak things using JavaScript, so I've been studying that when I get a spare moment.
What I've learned is a marvellous lesson for cataloguers, who work with MARC records. I've tried to keep this simple so it's accessible for newbies, and library staff who are new to MARC.
If you don't know what MARC is, it's a metadata standard that was designed based on the layout of card catalogues. It is still maintained to this day, but a lot of the structure and theory remains the same as it was in the late 1960s. In MARC a field is divided into subfields that are separated by punctuation.
For example:
245 01 $a This is the title : $b subtitle / $c this is the author name.
Note the : colon, / slash, and full stop at the end.
Some of this punctuation serves a practical purpose in the software that shows the catalogue records to the public. But much of it is aesthetic, and the rules are a matter of style or grammar rather than the system's needs.
For example, whether or not a 300 field ends in a full stop depends not on the needs of the system, but whether or not that particular library sees "CM" as a symbol or as an abbreviation for the word centimetre.
JavaScript is a programming language. It's used for a lot of things.
The standard in JavaScript when making a list of key-value pairs, is to separate each item in the list with a comma. In a lot of code, the list is spaced out with each pair on a new line, especially in tutorials.
const coffee = { crockery: "mug", bean: "Ethiopan", milk: "soy" };
You are not meant to put a comma at the end of the final line. It is not necessary, because the comma is only needed to separate the items from each other.
But, lots of people do put the comma at the end of the line. In fact, when I asked developers that I know they all admitted they always use a comma. Why?
const coffee = { crockery: "mug", bean: "Ethiopan", milk: "soy", };
It's simple! It's easier to remember.
If you train yourself to add a comma at the end of each pair in a list, you begin typing it automatically. You do not need to pay attention or make a decision. You always put it there. And that means that that you add in extra commas where it doesn't matter, but you never miss a comma when you need one.
You add commas consistently, and it's easy to edit, change, and re-arrange code if you don't need to worry about adding and removing commas each time you re-order something.
And if you miss a comma in the middle of a list, it does cause problems. Big ones, at times.
When I was a cataloguer many people lived and died by the full stop at the end of the 300 field. Is it an abbreviation or a full word? Different librarians have different opinions. People spend energy training in this, checking it, and correcting it to their local standard when copy-cataloguing. In a cataloguing team I worked in, if we made an error with this full stop we would fail the quality sample, and it would make our team's performance look bad in annual reports!
Just like JavaScript commas at the end don't matter too much, in fact, a lot of librarians apply the full stop always, or never, or kind of sort of guess at it. And most catalogue systems cope just fine with or without the full stop these days (to my knowledge, I don't have access to most of them as a cataloguer, I've only seen them from the outside.)
I do recommend if your workplace is very particular about MARC punctuation, that you follow your standards. But if you're ever in a place to influence those standards, I think it's a great idea to question how MARC fields with conditional punctuation rules display in your catalogue, and whether making some punctuation rules consistent can improve your cataloguing quality overall. Not just because it's easier for the cataloguer, but because it can improve accuracy and consistency in your data. And anything that is consistent becomes much easier to write scripts, automation, and templates for. Consistency makes your data easier to handle in bulk processing
There's something else that I learned from asking a bunch of people in my team about JavaScript. Most developers are used to seeing other people's code. Everyone has their own style, and in keeping with the most basic principle of cooperative cataloguing, if it isn't wrong, don't fix it. The happiest people use the same punctuation every time in their own code. But they also cope just fine when somebody else follows the standard and leaves that last comma out.
I think that as cataloguers, we're so used to holding ourselves to very rigid standards that our stress levels rise when we come across records that are "wrong". But in many cases the punctuation doesn't have a negative impact on library users, and you don't have to worry so much about what other people have done, as long as you can copy it and it will work okay in your system. In fact, if you have your own consistent local rule you could simply run a rule to correct for somebody else's practise when you bring the records into your own system.
I always like to remind myself of cooperative cataloguing principles. They contain a similar wisdom. If it's not wrong, don't fix it. I don't need to judge how other librarians have catalogued a work. All I need to do is make sure that it will be able to store properly in my database, show up in my catalogue, and get along with my other records.
I hope that thought helps to make cataloguing more relaxed for you. Even though library metadata is unique and we use it differently, we're not alone in our data entry problems. And sometimes a reality check can refocus us on what matters the most.
Spending our energy making sure that the high quality catalogue data we record is improving access.
No comments:
Post a Comment