A reasonable display for series data in MARC?

So I know plenty of catalogers read my blog  (or used to).  Appreciate any feedback or advice you have on this.

Basically, I’m trying to figure out how to actually do a useful user-friendly display of  ‘series’ information from MARC records.

My assumptions

So we have 440, 490, and 8xx.  There’s a distinction between “transcribed” series, and controlled (aka “traced” or “access point”).  I know that the controlled data is meant to be used for collocation.  I am assuming that the “transcribed” data is better for user display though.  Is this right?   (I’ll refer to these two concepts as “displayable” and “controlled”).

So if we’ve got a 440, then that is both displayable and controlled.

But current practice going forward is not to use 440, but instead to use a 490 for displayable, and a 8xx for controlled.

So what should the interface do?

So thinking about an individual record display. I can’t just list all 440, 490, and 8xx fields under “Series”, because in the case of 490/8xx, that’ll lead to me displaying the same series twice. Once in transcribed form, and once in controlled form. This is confusing and doesn’t make sense.

So what I’m thinking is that for a 490/8xx pair, I actually display the 490 on the screen — it’s the value meant for user-display.  But it’s clickable, and when you click on it, the search that will be executed is actually on the corresonding 8xx, because that’s the field meant for collocation.

This is assuming there is a corresponding 8xx. If there’s not, it’s somewhat simpler. We display the 490, and either it’s not click-searchable at all, or if it is, it searches an uncontrolled series index of all 490s, it doesn’t actually try to collocate on a controlled field, cause we don’t have one.

Does this make sense?  Am I missing something?

But the problem

But there’s still a problem here. A record can theoretically belong to multiple series.  Meaning it could have multiple 490s.  Each of which may or may not have a controlled 8xx corresponding to it.

As far as I can tell, there’s no way to tell which 8xx goes with which 490. Especially since a 490 may or may not have a corresponding 8xx.

This might not effect very many records, that have multiple series, but it still annoys me to have a known ‘bug’, a known case where things won’t work right at all.  I’m not really sure what the heck my code should do if there are multiple 490s.  Am I missing something?

By the way

This is one good example of how it’s somehow difficult or even impossible to get meaningful information out of our AACR2/MARC, despite some people’s belief to the contrary that it’s always simple and straightforward.

So… what the heck should be done with this 440/490/8xx stew?

16 thoughts on “A reasonable display for series data in MARC?

  1. I’d ignore the 490 altogether. If 440 present, display and link to that. If 830 is present, display and link to that. If both, display and link to both. Don’t worry about the transcribed form; it is not likely to be more displayable than either the 440 or the 830.

  2. I think ideally for display you’d do something like what IMDB does

    _Laurence Fishburne_ (as Larry Fishburne)

    to link the authorized and transcribed forms in a display.

    For certain types of series (works of composers come to mind), the transcribed form is more likely to be known to users than the authorized form.

    Theoretically, you can link MARC fields with $8 – Field Link and Sequence Number (http://www.loc.gov/marc/bibliographic/ecbdcntf.html), but only at the field level and I have never seen a system that made these easy to enter nor one that did anything with them once entered. IMO, lack of pratical, easy way to connect information within a single record is a significant drawback of the MARC format.

  3. I forgot to say 490 can also go with 800/810/811. Look for an 800 with a title of “works” for an example of where users won’t recognize their series.

  4. Matt’s advice works, although one wonders what the 490 is doing there at all if we aren’t going to be displaying it to the user! But maybe it’s there for other catalogers to make sure the understand what decisions were made why.

    Kelley’s advice makes sense, but Kelley, you avoided my main problem! What if there are more than one 490 on a page? How do I know which 8xx goes with which 490? There seems to be no way to do it. Leaving me to follow Matt’s advice instead, I think?

    But Kelley provided a good example of when just displaying an 8xx instead of a 490 won’t work. So… I’m still left without any idea of something I can actually do to do this right?

  5. Hi Jonathan, Interesting conversation. If there are multiple 490 1# fields, then the corresponding 830 fields will normally follow the order of the 490s. So, you could write the code to display the first 830 for the first 490 1#, the second 830 for the second 490 1#, and so on.

    800/810/811 are much less common in bib. records, but you still have to account for them. I’m pretty sure 800/810/811 will appear before the 830 fields, so you would have to write that exception into your code also. (This gets a little tricky. I guess you could display all the 4XX fields and not worry about displaying the 8XX fields as another option.)

    No matter which way you go, I’d also display 490 0# because even though they weren’t traced, they still might be of interest to users as an access point. I’ve seen series that originally were not traced by LC, but then years later they started tracing them.

    (Other catalogers, if I’m wrong about the order of multiple series fields, please correct me!)

  6. Well, a 490 with first indicator 0 is a series (or something that looks like a series) that isn’t being put under authority control. You see this more in older records. Newer records tend to use a quoted note. 490 with first indicator 1 is *supposed* to have a corresponding 8xx field. If it doesn’t, it’s a mistake.

    Normally, I’d think the the number of 490 1# fields and the number of 8xx fields should match. The likeliest reason for not matching is probably lack of a 490. Series in 8xx have to be justified somewhere in the descriptive part of the record, but it doesn’t have to be 490. It could be a note field, for example.

    The answer to your question of how to link them is to make someone go back and add all the linking subfields and then figure how to do something with linking subfields. I don’t think there is any other answer, although Chris is right that the order generally matches. This is what I think of as the Humpty Dumpty problem–you might have all the pieces, but you can’t put them back together again. At least not without manual review. :-(

  7. Thanks, that helps Kelley. I think it is possible to do something that will work in 99% of cases, although it’s a bit of a pain in the ass, requires a more complicated decision tree than you might think. (Obviously requiring someone to add linking fields to all existing records is not feasible. Although if someone complains about a particular one displaying improperly, it might be feasible to go and add those to that one. Although taking account of linking fields requires yet ANOTHER branch of the decision tree.)

    I’m totally going to keep this example on file next time there’s an argument (such as on NGC4Lib recently) about how really it’s perfectly straightforward to get whatever data you want out of MARC.

    It seems to me that the manner of recording series was devised by people who never considered how you might want to deal with it it in an interactive interface! Other than just displaying it exactly the same way you would in a card catalog. Which is what most of our existing interfaces do, which is why they’re so bad.

  8. Well, I’ll add a extra fillip — you will get a 490 that can be linked to multiple 8XX’s. It’s usually a case of a subseries where the main series is numbered. Which is one of the reasons why I think focusing on the 8XX is better than worrying about the 490, except for the 490 0 cases, because for those there won’t be an 8XX. And since LC is no longer doing series authority work, untraced series statements like that will be not only found in older records but in plenty of newer ones.

    And no, they were NOT thinking about interactive interfaces. You are dealing with the legacy of paper card catalogs.

  9. Man oh man. So what are people actually doing with these fields in displays?

    How the heck should they be displayed? I honestly can’t figure it out.

    I guess most existing OPACs are just displaying all the 490s, 440s, and 8xx’s in one big list, even if that means displaying the same series twice in a list? (Once in transcribed form and once in controlled form?)

    I can’t figure out anything to do but that, that will actually be reliable and not miss information.

  10. My library will need to deal with this issue sometime in the near future as well (I don’t think our series display and configuration has been touched since we switched to SirsiDynix Symphony), but it’s a problem I’ve been avoiding so far because, as has been noted, it’s complicated. I’m thinking that probably the easiest “fix” for us will be to display 440 or 8XX in the default display – if someone wants to actually see the transcribed title, they’d have to manually change the display so that they could view everything. At any rate, 490 would still be keyword searchable, even if it’s not displayed in the default display.

    It’s bothered me as well that 490 isn’t linked in some way to its corresponding 8XX – it feels like it should be, but there’s no way to do that.

  11. For what it’s worth, when I prepared a printed catalog using MARC records, I ended up listing all the series tags in the index, eliminating only exact duplicates (thus, if the 490 and 8xx were exactly identical, I only displayed one, otherwise I displayed both). I had hoped to do better, but the series data was terribly irregular, and the collector wanted the catalog done as soon as possible, with as little expense (i.e. time spent, of course) as possible.

    Anyway, the point I wanted to make was that 490s and 8xx’s sometimes were completely different. I can’t think of an example off the top of my head, but there were a few records where I noticed that a patron would almost certainly look under the 490 (rather than the 8xx), and others where the 490 seemed irrelevant, because the patron would be more likely to look under the 8xx.

    Not that this will help you resolve the problem, but I thought I’d share a bit of anecdotal evidence.

  12. It turns out here’s how my legacy OPAC does it: Show all 440’s. Show all 8xx series titles. Show 490’s only if they marked not traced.

    This definitely avoids showing the same series title twice (once in transcribed form and once in controlled form). By just not showing the transcribed form at all if a controlled form is present.

    I’m guessing no OPACs do any better, because I can’t think of anything better to do. So we’re back with Matthew Beacon’s suggestion in the very first comment: Simply don’t show 490’s if they are marked as traced.

    The key piece of information is that even though you can’t know which 8xx goes with which 490, you can know that a 490 has some 8xx, by it’s first indicator being 1.

    (I’m right there, right?)

    It might be a dis-service to the user not to show them the transcribed series at all, but there’s just no way I can figure out to do it without just adding confusion.

  13. Melissa: I think there IS a way to do that using the $6 linking field. But I don’t think anyone EVER does it, and it is a mechanism which is kind of tricky and subject to error, especially when you’re dealing with merging and ‘overlaying’ records, it’ll often mess up any $6’s you get unless you manually attend to them.

    So there’s sort of kind of a way to do it, but it’s not a very good way, and nobody uses it.

  14. Well, if you really, really want to do this, I suppose you could

    1. Display all 490 0 fields (I forgot about the LC series thing since I hardly ever see LC records with what I do; whether you see these in your local catalog depends on whether your cataloging dept. is making an effort to control them or not)

    2. Remove initial articles from 490 1 first $a, as well as everything following a slash. Compare this with anything in 830 $a or 800/810/811 $t before any parentheses and if one of the 8xx subfields matches or mostly matches the 490 1, suppress it. Otherwise display it.

    I think there might still be a few glitches with this, but it would be clear for things with only one 490 1/8xx pair and probably clear enough for other things. Probably not practical, though.

    Also, the linking subfield you want is $8 not $6 (the latter is for linking two fields with the same tag, one of which is Romanized and one of which is in a non-Roman script; this is actually used fairly commonly and not too hard to do in Connexion). Looking at it again, I’m not sure you could use $8 either as it apparently requires a field link type and I’m not sure what would apply to a 490 1/8xx link, although you might be able to shoehorn it into x – general sequencing. I can’t say I’ve ever seen $8 used in the wild, though. Does anyone use this?

  15. I don’t really think I’ve seen the $8 used in any current records. Maybe in some older ones? And I just looked in my catalog interface and $8 doesn’t come up as a possibility, but $6 does. Although $8 is definitely available in the MARC Standards. But reading what it does doesn’t really make it clear to me how it would like a 490 to an appropriate 830.

    I would stick with offering visuals of 440, 8XX, and the 490 untraced. If the cataloging is done correctly, that will cover all series instances and not overlap.

    If you really want an explanation of the purpose of the 490/830 combo, let me know. There is a reason for it.

Leave a Reply

Fill in your details below or click an icon to log in:

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 )

Connecting to %s