Music subject headings

Wow, the blog has been lonely lately, hasn't it? It's almost as if there are too many things floating around in my head that I can't get any of them fully formed enough to even write about here.

One of those many floating thoughts has been subject headings for music. Many traditional schemes, like LCSH, make a distinction between headings used for works about music, and headings used for music itself. For example, "Symphonies" is used for music scores and recordings of symphonies. But "Symphony" is assigned to texts about symphonies.

Obviously at first glance the distinction between the two forms is subtle. Even if a user realized the potential for this distinction being made (!), it would be difficult for that user to determine which form to use in which case. In my library catalog, a subject browse on "symphonies" lists first an entry for 5407 matches, then second, "see related headings for: symphonies." Clicking on the latter yields a screen saying "Search topics related to the subject SYMPHONIES," but no way to actually do that. This is probably because the authority record for symphonies has no 550s specifying any related headings. Geez. Both because the system shows this anyways and because there are no related headings. [Yet another NOTE: the mechanism for specifying a heading is broader or narrower than another heading in the MARC authority format is ridiculously complicated. No wonder the relationships between LCSH headings are so poor.] This same screen is also where one would view the scope note for the heading "symphonies":

Here are entered symphonies for orchestra. Symphonies for other mediums of performance are entered under this heading followed by the medium, e.g. Symphonies (Band); Symphonies (Chamber orchestra). Works about the symphony are entered under Symphony.

OK. So to find out if "symphonies" is what I'm looking for, I need to click "see related headings for: symphonies"? Riiiiight. Sure, my catalog could handle this better. Not many do.

This distinction isn't always so obvious to specialists, either. I've been reading up on the topic for a project and I'm struck by how rarely it's made explicit. A huge majority of writings simply assume they're talking about one, the other, or both, but never say so. Many others indicate they're discussing one or the other but provide examples of both. I myself recently forgot the distinction at a critical juncture. :-)

I'm wondering if this distinction between headings for works about music and works of music is still needed in modern systems. [NOTE: I don't consider any of the MARC catalogs I'm familiar with to be "modern systems"!] We certainly now have mechanisms to make this distinction in ways other than a subject string. Most of me says this is an outdated mechanism. But in a huge library catalog covering both types of materials, the distinction does need to be made in some way. I'm still pondering over exactly which way that should be.

Structure standards and content standards

It's funny how related things seem to come in spurts in our lives. Or maybe it's just that once we notice something once, it's easier to notice again. In my standard metadata spiel, I, like many others, distinguish between structure standards that tell you what "fields" (for lack of a better term) to record, and content standards that tell you how to structure values in those fields. The latter can be either rules for structuring content or actual lists of permissible entries. It's an extremely useful distinction. Yet I've been noticing recently that it's frequently misunderstood, or that the distinction is implicit in a conversation rather than explicit.

One place this trend caught my eye recently was in a blog post by Christopher Harris on using LII's RSS feed to generate MARC records, and subsequent comments and posts by several people, including Karen Schneider of LII. Most of the ensuing discussion was about keeping the two data sources in sync, which of course is important to plan for. But I noted a conspicuous absence of content standards in the discussion. MARC records, of course, do not have to adhere to AACR2 practices. In fact, there are millions of non-AACR2 records (mostly created pre-AACR2 and never upgraded for practical reasons) in our catalogs. But today if one is creating a MARC record, it would be prudent to either use AACR2 or have a compelling argument against it. Yet neither of those options appeared in this discussion. Reading between the lines, I suspect the transformation should be reasonably straightforward, but one shouldn't have to read between the lines to know.

I suppose what I'm really saying here is that when talking about these sorts of activities, we need to completely define the problem to be solved before a solution can be determined. And that includes dealing with content standards in addition to structure standards. Explicitly. Knowing which standards (or lack of them) are in use in the source data and which are expected in the target schema. Planning for moving between them. This is an extremely interesting topic, and I personally would love to see more discussion about it.

Oh, and, for the record, I'm with Karen that one would want to be careful about putting lots of records for things like LII content into our MARC catalogs. My vision (imperfectly focused, unfortunately!) is that because the format (and the content standard that is normally used with it) doesn't describe this type of material well, and the systems in which we store and deliver our MARC records don't provide the sort of retrieval we might desire for these materials, our users would be better served by a layer on top of the catalog that also provides retrieval on other information sources better suited to describing these materials. This higher-level system would provide some basic searching but most importantly lead a user down into specific information sources that best meet his needs. We have lots of technologies and bits of applications that might be used for this purpose. I wonder what will emerge.

So what's up with RDF?

Kevin Clarke posted on his blog last week some thoughts on the recent ALA conference and a session on metadata interoperability. A discussion has ensued from this about RDF, with commentary by Leigh Dodds and a follow-up post by Kevin. I've learned a great deal from this exchange. I've always felt that I was missing something with RDF, that I needed a discussion on a much more practical level than those I'd been exposed to in order to understand what it could do for me better than the tools I already use. I've heard smart people I like and respect make comments like those by Kevin, Bill Moen, Dorothea Salo, and Roy Tennant quoted in these blog postings, and felt a bit of comfort that I wasn't the only one who felt left out. But it's not enough to have company in the "huh?" camp - I want to understand. I want to be able to make a reasoned argument against RDF, or embrace it for tasks it does better (in my world) than other things. Yet I've never felt like I can do either of those things. For now, I'll follow discussions such as this one in order to slowly absorb all the angles.

And all of this banter reminds me I need to learn RelaxNG and finally figure out what the deal is with topic maps. Anybody have a few extra hours in their day they're willing to send my way? :-)

Addition of dates to existing name headings

The Library of Congress Cataloging Policy and Support Office recently announced a review and request for comments on a potential change of policy regarding addition of dates to existing personal name headings. Currently, dates are only added in certain situations, and once a heading is established, dates are never added to it after the fact. Personal name headings are frequently created while an individual is alive, leading to headings such as (from the CPSO proposal):

100 1# $a Bernstein, Leonard, $d 1918-

This heading then was not changed when Bernstein died in 1990. The CPSO proposal notes that libraries, including LC, receive frequent comments and complaints from users regarding the "out of date" nature of headings of this sort.

In discussion of this policy on the AUTOCAT listserv, the question arose as to whether name authority files served to simply generate unique headings for an person, or if they served a wider biographical function. Certainly historically the former is true. But many, including the CPSO, are recognizing that increasingly we may be well served by delving into the latter. We have an opportunity here to become more useful and relevant to the wider information community. To take that opportunity might seem to be a no-brainer.

However, the current cataloging infrastructure makes the implementation of this change challenging, to say the least. As authority data is replicated in local catalogs and the shared environment, and most integrated library systems store actual heading strings in bibliographic records rather than pointers to authority records, changing a heading would then require notifying all libraries that a change has been made, propagating that change from one library to the rest, then continuting to propagate that change in every local system to all affected bibliographic records. Clearly this mechanism is anachronistic in today's networked world, where relational databases are so entrenched as to be considered almost quaint. I fully understand the practical implications of the CPSO implementing this policy. Yet I believe that it is the right thing to do. We as librarians simply must have a vision for what we're trying to accomplish, and work tirelessly towards that goal. While we must keep the practical considerations in mind, we can't let them dictate all of our other decisions. Let's set the policy to do the right thing, and insist on systems that support our goals.