Associative index model

The paper “An associative index model for the results list based on Vannevar Bush’s selection concept” by Charles Cole, Charles-Antoine Julien and John E. Leide of McGill University, Montreal, which appears in the latest issue of Information Research, contends that algorithmically created methods of refining results lists in online catalogs are not well suited to meet the users’ information needs. The authors draw on Vannevar Bush (whose seminal text, “As we may think” (1945), is available here) and Charles Cutter to develop an associative index model.

Based on an understanding of cognitive processes during a search, the model establishes a second collocation set, triggered by the user’s associative thinking while perusing the first, system-derived results list. This second set is considered to better match the user’s actual information need. In my view it is only an externalization and formalization of thought processes at work in a more or less conscious way, including epistemological questions like, how do we look for information, how do we formulate a query, i.e. use natural language to reflect our information need, how do we process and organize the findings, how is association involved in search and selection.

Some questions remain open, for instance, why didn’t the authors revert to the FRBR user tasks instead of creating their own with slightly different meanings, or how would relevance feedback relate to their approach. I wonder what role topic maps could play in an associative retrieval tool - enabling users to identify subjects in their own words, i.e. from their thought associations, feeding improvements suggested by users back. A dynamic system getting “smarter” through user input which complements computational algorithms.

Interpreting MARC – article

The current issue of the Code4Lib Journal features an excellent article by Jason Thomale, “Interpreting MARC: Where’s the Bibliographic Data?”. The abstract:

The MARC data format was created early in the history of digital computers. In this article, the author entertains the notion that viewing MARC from a modern technological perspective leads to interpretive problems such as a confusion of “bibliographic data” with “catalog records.” He explores this idea through examining a specific MARC interpretation task that he undertook early in his career and then revisited nearly four years later. Revising the code that performed the task confronted him with his own misconceptions about MARC that were rooted in his worldview about what he thought “structured data” should be and helped him to place MARC in a more appropriate context.

I have to say that the project he writes about (ditigal music collection) is very complex, because music cataloging has special rules on top of the regular ones. This doesn’t change the assessment of the MARC data structure, though, which has “as much in common with a textual markup language (such as SGML or HTML) as it does with what we might consider to be ‘structured data.’”

It’s a worthwhile read for both catalogers and programmers: it illustrates the programmer’s perspective looking at and working with MARC data and it provides insights into what made MARC the way it is and into possibilities of dealing effectively with the quirks that exist.

Data, not records

Despite recent efforts by libraries to release metadata as linked data, library records are still perceived as monolithic entities by many librarians. In order to open library data up to the web and to other communities, though, records should be seen as collections of chunks of data that can be separated / parsed out and modeled. Granted, the way we catalog at the moment makes us hold on to the idea of a “record” because this is how current systems represent metadata to us both on the back- and front-end. However with a bit of abstraction we can see that a library record is essentially nothing but a set of pieces of data.

In some (unfortunately not all) online catalogs, records have permalinks / identifiers so that they can be referred to on the web, but what about the single elements that constitute a library record, i.e. the MARC fields? MARC does not have a great deal of granularity, many pieces of information are crammed into one field and the specific meaning often lies in indicators and subfields. This discussion on LibraryThing about the “Physical Description” field highlights the fact that MARC data is not really machine-understandable and useful for parsing.

Looking beyond the awkward representation of metadata in MARC, we can think of it as pieces of data assembled for describing a resource. The RDA vocabularies could be one step towards modeling the elements of library data as separate entities, providing URI identifiers (potential PSIs?) [1]. So basically we are (slowly) moving towards identity management that is not only understood by humans but also by machines, enabling interoperability, sharing and merging.

From a topic maps point of view, one consequence of breaking library records up into pieces of data is that it facilitates the integration of data from heterogeneous sources, making subject identification richer. You can map between different formats, like MARC, Dublin Core, ONIX etc. What in MARC we call “author” has a different subject indicator in other models, in Dublin Core it is dc:creator, for example (see “Understanding subjects and subject proxies” by Patrick Durusau). Each chunk of information can become a topic of its own. And linking elements of the classic “record” with information from Freebase or DBpedia is one possibility of weaving a richer web of knowledge (aka linked data). Not to mention the possibilities of mapping, identifying and linking subject headings…

Cataloging huge amounts of 19th century material, I often wonder: what if users had a link to the year of publication (e.g. from Wikipedia) that could provide some background information about what happened that year and could assist them in understanding the historical situation and the context a book fits into? Same for place of publication – which state was Sarajevo part of in 1894?

Let me recommend two publications by Karen Coyle that expand on the notion of metadata supplanting traditional “records”: the article “Metadata mix and match” (not for purists ) and “Understanding the Semantic Web: Bibliographic Data and Metadata”, especially ch. 2, summarized on the Panlibus blog. Libraries have rich and valuable data to offer; in order for that data to be exposed, sharable and reusable on the web or in other information frameworks, the “record” has to be broken up into its parts, which allows for modeling and subject identification.

[1] According to the XML Topic Maps specification, a published subject indicator is “any resource that has been published in order to provide a positive, unambiguous indication of the identity of a subject for the purpose of facilitating topic map interchange and mergeability.”

Cataloging in the age of discovery systems

Discovery tools with search engine functionality are increasingly being introduced to replace traditional library OPACs. What does this mean for those creating or managing metadata, the catalogers? The role of catalogers gets more important, because however nifty the frond-end is, the underlying data has to be accurate to be useful and to enable findability, and this is even more true now than it was in the days of the OPAC. Catalogers thus have greater responsibility towards the user. Fill in fields correctly or not at all, but not carelessly – data has to be as reliable as possible for machine processing and for the display generated from it. Fields that seem insignificant today may be essential for tomorrow’s technology. We don’t create metadata just for current systems or tools, we also want it to be usable in the future that may yield possibilities we can’t yet foresee.

Discovery systems uncover mistakes or blind spots in the data which in OPACs no one would really have noticed. MARC (or in Germany and Austria MAB) fields that have thus far not been used for display in OPACs now become more visible and actually influence findability to a considerable degree. Some key elements merit special attention. For example, certain facets for browsing are determined by the content of fixed fields (media type, language, country of publication…). If these fields are filled in incorrectly or not at all, search quality suffers and users might be led in wrong directions. The same is true for media type icons. Classification faceting pretends to be meaningful –  but can the user be sure that all records in the system have subject headings? I know for a fact that in the cataloging network I’m working in, many records don’t, and these are lost to this particular facet.

Any discovery tool is only as good as the metadata, and the metadata is, in the current cataloging workflow, only as good as the skills of those handling it. Catalogers should be involved in the implementation process of a discovery tool, and awareness has to be raised about what consequences their work has on users’ search and discovery experience. Some cataloging guidelines might have to be adapted in order for the metadata to be fully exploitable in this new environment. This should happen early to keep the amount of metadata to be manipulated later as small as possible.