Granularity and Relational

While clearing out old lists of post inspirations, I ran across a post on Commonplace.net that still gets my brain going:

At my place of work, my desk is in close proximity to our two catalogers.  The conversations that ensue about cataloging standards, MARC, and such are often interesting, and occasionally stray into realms so esoteric that it becomes a challenge to keep up with the thread of conversation.

My rare contribution usually boils down to “I am an agnostic as to what standards are used, but the basic storage and retrieval of cataloging information should be as granular and relational as can be achieved.”

By granular, I mean that information should be divided into small, well-defined chunks.  When an author is listed as “Smith, John, 1947-” I cringe a little.  Dividing the author’s first and last (and middle) names into separate fields makes a world of sense, especially when you encounter authors with multiple middle or last names (or both).  Instead, MARC relegates the name into one string.  This also creates problems with cultural differences in how given and family names are presented.

Another problem is that this information exists separately in each bibliographic record.  If our data storage systems were to store author/creator information in a relational manner, we could have one record for “Smith, John, 1947-“.  This would make it much easier in the unfortunate circumstance that the author becomes “Smith, John, 1947-2010”.

Most library software uses granular and relational database methods for the storage of circulation and acquisitions information.  It is our bibliographic information that is stuck in an inefficient rut.

The strongest argument I can think of for changing this is that is is very easy to create scripts and use software to put together small pieces of information to create an easy-to-understand string; it is much, much harder to take that string and break it into well-defined and usable chunks in order to use the information in new ways.

The future of data is not so much everyone using the same specific standards, but using standards that can be compared and used in ways that are compatible.  We can easily build MARC records from a granular relational database; cataloging need not change how it views and edits records (not much, at least), but the current methods are holding libraries back.

This entry was posted in Cataloging, ILS, Libraries, Software and tagged , , , , , , , , . Bookmark the permalink.

One Response to Granularity and Relational

  1. Maurizio Zani says:

    Librarians’ use of term “granularity” is very interesting. You define granular: “information should be divided into small, well-defined chunks”. It’ok, but it isn’t sufficient.
    Marc records are very granular, but aren’t enough relational. The challenge for librarians is to create “relational granularity”. Every chunk of information must be connected to the network of others chunks or to a knowledge system (ontologies or thesauri).
    For me is very useful the definition of granularity in Harrod’s librarians’ glossary and reference book: Granularity. The level of detail expressed in a search term and an information resource that influences the relevance of retrieved data to the end user. The end user can move along an information granularity spectrum, beginning with coarse granularity criteria (broad terms) that lead to large results, subsequently narrowing these to a finer granularity that reduces the size of the result set.
    The granularity don’t belong to data o to document. Relational granularity have to empower the user.
    Sorry, my english is very bad, i hope you understand my words. I wrote some pages about the term granularity, but in italian, http://digitalia.sbn.it/upload/documenti/digitalia20062_ZANI.pdf.

Comments are closed.