TPAC RDA 264 Publisher info Display & Index

[Lisa Hill]

For consideration for 2.4 for the TPAC- though this would probably help folks on the JS PAC for indexing in the publishers index-
260 ‡b is included now- but now we need to include
264 ‡b_1
264 ‡b_2
264 ‡b_3

For the publisher name to be displayed we need the:
260 ‡b and if nothing in the 260 ‡b please display the
264 ‡b_1

For the publisher date please include
Display
260 ‡c to include
If nothing above then…
264 ‡c_1
and
264 ‡c_4 if present.

I have attached a file with screen shots that make this easier to decipher.
Thanks
lisa

[Ben Shum (bshum)]

Discussion regarding display in TPAC for 264 per new RDA standard has sprouted a couple times in cataloger list and IRC. I've been trying to work on a solution for 2.4 as well.

Adding link from an IRC discussion to this post regarding meanings of specific indicator flags in relation with 264: http://<email address hidden>/msg07137.html

The big thing I wanted to see sorted out is expected behavior in the event of either multiple 264 tags with varying indicator flags or mixed with prior 260 tags in the same record. Do we only iterate and look for the first entry of a given bib for either 260 or 264 when showing pub data? Do we consider what if the first tag found only has the date, but the next tags also contain place of publication and publisher too?

As is, TPAC in master checks and displays the first 260 and corresponding subfields a, b, and c to show a full publication statement. So we should probably maintain that, but add expected behavior for 264, I guess.

[Dan Wells (dbw2)]

I'm not familiar with this use of underscore notation for the subfields. Just to be clear for those of us following along, when you type:

264 ‡b_2

this represents a field 264, subfield b, and the field's *second indicator* is 2?

Thanks,
Dan

[Lisa Hill (lhill)]

Yes the underscore means indicator so in that case it is the second indicator

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Dan Wells
Sent: Friday, October 26, 2012 4:51 AM
To: Lisa Hill
Subject: [Bug 1071505] Re: TPAC RDA 264 Publisher info Display & Index

I'm not familiar with this use of underscore notation for the subfields.
Just to be clear for those of us following along, when you type:

264 ‡b_2

this represents a field 264, subfield b, and the field's *second
indicator* is 2?

Thanks,
Dan

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1071505

Title:
  TPAC RDA 264 Publisher info Display & Index

Status in Evergreen - Open ILS:
  Confirmed

Bug description:
  For consideration for 2.4 for the TPAC- though this would probably help folks on the JS PAC for indexing in the publishers index-
  260 ‡b is included now- but now we need to include
  264 ‡b_1
  264 ‡b_2
  264 ‡b_3

  For the publisher name to be displayed we need the:
  260 ‡b and if nothing in the 260 ‡b please display the
  264 ‡b_1

  For the publisher date please include
  Display
  260 ‡c to include
  If nothing above then…
  264 ‡c_1
  and
  264 ‡c_4 if present.

  I have attached a file with screen shots that make this easier to decipher.
  Thanks
  lisa

To manage notifications about this bug go to:
https://bugs.launchpad.net/evergreen/+bug/1071505/+subscriptions

[Lisa Hill (lhill)]

Hi Ben-

KCLS will be using either the 260 OR the 264. I can't say that ALL libraries will be doing that. It is up to the individual library. However, from the discussion on the list it sounds as if some libraries will be using a service to get their records that have they publisher data in the 260 into the 264.

For the publisher name I think it would be best to only display the first set of values- for example

260 ‡a[Frome, Somerset, England] : ‡bChicken House ; ‡aNew York : ‡bScholastic, ‡cc2007.
This item display would just show Chicken House.

The user could still see EVERYTHING when they click on the MARC record.

"As is, TPAC in master checks and displays the first 260 and corresponding subfields a, b, and c to show a full publication statement. So we should probably maintain that, but add expected behavior for 264, I guess."

That is what I think we should do- I am not sure if libraries will have a 260 and a 264- the last time we had something this life changing to the MARC was 1978- but what I am seeing from *all* the library lists right now is that most folks will have either a 260 or a 264 but likely not both- of course this could change...

[Ben Shum (bshum)]

For further explanation on what I originally meant by "As in, TPAC in master checks and displays the first 260 and corresponding subfields a, b, and c to show a full publication statement.":

I was referring to the changes to bib record details introduced with bug 1049980. It was included as part of the 2.3.0 release and is the current method of displaying publication information. Basically, the 260 a/b/c fields are now retrieved and displayed as a single field entry rather than separately pubdate, place of publication, etc. Because the line is fully combined now, I was concerned with making sure that the new indicator style for 264 gets respected and that we'd need to come up with a way of presenting the information appropriately if a 264 with ind2 set for only copyright was the first entry but a later 264 might contain other other publisher information of value. Or we'd plan to just ignore all subsequent 260/264 entries and subfields and only show whatever was contained in the first listed entry regardless of whether there was more information contained in subfields of other 260/264 entries further in the record.

Given that 260 and 264 are repeatable entries, I cautioned myself to plan for potential cataloging issues in existing and future records rather than building in changes to TPAC based on a pristine scenario of exactly one 264 or 260 per record with all the right subfields a/b/c. But then again, I'm not a cataloger.

[Ben Shum (bshum)]

I think the direction I was thinking to move towards is having different 264 based on the indicator 2 flag show up with different labels in TPAC if found.

So if a 264 ind2 of 4 shows the copyright date only, I'd want that to be an entry in the record details labeled "copyright: " while an 264 ind2 of 1 would be "publisher info: " (or similar). And same treatment for the other ind2 types.

[Ben Shum (bshum)]

First attempt, based on getting us moving in the right direction. The change I've made in my working branch for master will look for either a 260 or 264 (ind2 = 1) for publication statement information. Whichever appears first in the record will be displayed.

Working branch: user/bshum/RDA-264-pubinfo

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/RDA-264-pubinfo

[Ben Shum (bshum)]

So it seems display in TPAC is easy, but we also have to find where pubdate gets indexed for search purposes and also perhaps how it's generated for use in acquisitions. And adjust those to also potentially use 264 as a source of information.

[Jason Stephenson (jstephenson)]

Not to belittle this bug report, but we (at MVLC) would like to see a coherent effort made to bring Evergreen up to RDA standards. This means that we'd prefer not to have a hundred separate bugs opened for each piece of RDA upgrade and integration. (As the Chief Bug Wrangler, I'd prefer not to have 100s more bugs to work through, so I'm doubly interested in a coherent approach to RDA.)

To that end, we have purchased access to the RDA online documentation and updates. We intend to have our developers go over the documentation with our catalogers to determine all the changes necessitated by RDA.

We also intend to share this with the community as a Launchpad blueprint and by other means before any work is begun.

That said, I'm not altering the status of this bug. It provides a starting point for RDA changes and the work already done by Ben Shum could be of a great help in determining where RDA changes will need to be made in Evergreen.

[Dan Scott (denials)]

It would be great to have an overall view in a Launchpad blueprint, but I would also celebrate one hundred separate bugs, each with a specific change, explanation, and test cases to ensue that nothing AACR2-based breaks and that everything RDA-based works. (One can easily link to bugs from a wiki page, mailing list, or whatever other document encapsulates all of the changes one thinks are needed to bring Evergreen up to RDA standards, and it would enable the community to track the progress of implementing the agreed-upon changes).

I would also be very sad if MVLC's promise to "determine all the changes necessitated by RDA" meant that any other efforts to understand and interpret RDA in the context of its applicability to Evergreen stalled, and would encourage the community to discuss this in the open (say, on the relatively unused Evergreen cataloguing mailing list, if people are shy about posting on -general). It would be great to have someone lead this effort on behalf of the community, particularly given the closed nature of the RDA docs that prevent many of us from participating.

[Jason Stephenson (jstephenson)]

To address Dan's second point, I didn't even think to mention that we don't mean to stifle anyone else's efforts. We welcome everyone's participation in the effort. I didn't think of it, 'cause from our point of view it goes without saying. We've been very open about everything we've done in Evergreen up to this point and we intend to continue to operate that way.

By posting my comment when and where I did, it was a first call to say, "What do you think of this?" I just kind of assumed that's how it would be taken because that was the spirit in which it was offered. So, yeah, we're offering to lead this development effort with the participation of anyone in the community who is interested.

Part of this is also to get some developer discussion going on RDA. What I've heard about RDA so far has been in dribs and drabs from library staff, and most of that has been negative. We (tsbere and myself) feel that if anything is going to get done in a big way to get Evergreen ready for RDA by "the deadline," then some Evergreen developers need to get access to the documentation and starting doing the planning and the developing. In the spirit of scratching your own itch, we decided to purchase access to the documentation and get the ball rolling.

I agree that there should be communication on the matter with the community. I don't think we're at the stage where we can post blueprints or go to the -dev or -general lists and solicit feedback, so I just wanted to update this bug as a head's up to developers that this is what we're hoping to accomplish with RDA real soon, now.

[Dan Scott (denials)]

Thanks for clarifying, Jason! I was just concerned when I read "our developers will meet with our cataloguers" as it sounded like a fait accompli; your clarification makes a ton of sense. Thanks!

[Sarah Childs (sarahc)]

264 stuff

I was importing an RDA record via Z39.50 just now and noticed the publisher didn't display in the summary list. So it struck me that anyplace that publisher is an option in the column picker, it will need to look for the a 264 when there is no 260. Off-hand, that includes Z39.50, Item Status, record & copy buckets, view holds, and probably others--acq, I'm betting. The import queue in Vandelay also displays publisher.

And as to indexing pubdate for searching, an unscientific test of the Evergreen Indiana (2.2.2) staff client seems to indicate the search is based on the fixed fields and not the 260, so we're probably set with that. We're no using acq at the library where I work at this point, so I haven't looked into that.

[Ben Shum (bshum)]

Rebased to latest master and then added a new commit to attempt dealing with the lack of fleshing for 264 bibs in the reporter tables/views.

There's still more to investigate before we're done but here's a link to what I have in mind so far: working/user/bshum/RDA-264-pubinfo

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/RDA-264-pubinfo

[Jason Stephenson (jstephenson)]

Don't pay any attention to my ramblings above. I wasn't thinking straight. I think multiple bugs for each new RDA feature is the way to go.

[Dan Wells (dbw2)]

I'll take incremental improvement whenever I can. Ben, I've gone ahead and pushed the first commit of your branch to master, as it is a definite improvement.

For the second commit (the reporter stuff), I notice you are not checking the second indicator like you did in the TPAC. Is this an intentional difference?

At some point we will need to decide how to handle the non-publisher 264s, but since we call the data "publisher" in various places, I think it makes sense to limit to the true "publisher" 264s (i.e. second indicator '1') for the first round of changes, then add display/indexes for the less common 264 variants later on as needs dictate.

[Ben Shum (bshum)]

Per our discussion in IRC, I've started a new branch to address reporter values taking into account the second indicator flag now.

See: working/user/bshum/RDA-264-reporter

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/RDA-264-reporter

[Ben Shum (bshum)]

Adding pullrequest tag to grab the second half for the reporter piece to complete the work on this bug.

[Jason Stephenson (jstephenson)]

So, this is in two branches, Ben?

[Ben Shum (bshum)]

Correct, the one that needs merging is user/bshum/RDA-264-reporter. Dan pulled the other commit into master already.

[Dan Wells (dbw2)]

New view worked, upgrade file worked; pushed to master (aka 2.4). Thanks, Ben!

[Ben Shum (bshum)]

Adding targets for 2.2 and 2.3 to work on backporting fixes appropriately. New records are showing up with RDA tags and we need to keep 2.2 and 2.3 capable of working with them while we still support them.

[Ben Shum (bshum)]

Backport branches have now been added to the working repository. Assigning the bugs to the 2.2 and 2.3 release maintainers for review and merging before the next maintenance releases.

For 2.2: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/RDA-264-rel_2_2

For 2.3: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/RDA-264-rel_2_3

[Lebbeous Fogle-Weekley (lebbeous)]

Thanks Ben and everyone!

So I was testing this ,but couldn't provoke anything new to display on a test rel_2_3 system.

I added a new 264 with ind2=1 and a subfield $a. I got rid of the existing 260 in the record. I went from seeing the contents of the 260 where "Publisher" appears on the record detail page to seeing nothing at all instead of the 264. I'm probably missing something. Are there are other steps I'm missing that I would need in order to test this more fully?

Thanks

Lebbeous

[Ben Shum (bshum)]

Hmm, tested this against a 2.3 system and replacing 260 with a 264 ind2=1 and subfields a, b, and c displays the combined content just fine. Could be the ind2 or maybe not having the other subfields did something weird.

Logically those sound like the right steps otherwise...

[Bill Erickson (berick)]

I am seeing the 264 data with the patch applied. I followed Ben's steps of just tweaking an existing 260 field.

[Lebbeous Fogle-Weekley (lebbeous)]

Right, I see it behaving as you guys say now in rel_2_3. Of course the 264 needs $a $b and $c. So merging that.

For rel_2_2, which I'm testing separately since Ben asked and since the tpac code is pretty different, I'm not seeing this work yet, but I'm fiddling with it.

[Lebbeous Fogle-Weekley (lebbeous)]

Ok. I see what's happening. More expectations-confusion on my part. Basically I was imagining that bug 1049980 had been backported to rel_2_2.

Doing that because it ought to be.

[Lebbeous Fogle-Weekley (lebbeous)]

And this all works nicely. The backport branches probably would have needed no special attention, and the same code for master would have worked here had bug 1049980 been backported. I think it would be best if we can avoid delaying backports relative to the merge-to-master operation except in special cases where there's really a good reason to treat the older branches differently.

[AlexK (alex-kent)]

I’ve done some testing of the display of the 264 field in 2.3.7 and found that the 264 only displays if there is a second indicator of 1. This should display regardless of the indicators (someone correct me if I'm wrong here).

I looked at 5 records and found that the ones with a second indicator of 0 did not display in the catalog. If I changed it in MARC Editor to a second indicator of 1, the 264’s would display just fine. I also tried changing the second indicator to a 2 and the 264 did not display.

For the record “Emergency Management, Human Resources, and Continuity of Operations Plans…”
The 264 second indicator was 0. It did not display in the catalog. Changed it to 1, it did display.

I also tried deleting the second indicator of 0 so they were both blank, and the 264 did not display.
Then I changed the second indicator to 2, and it did not display.

The 264 only displayed if the second indicator was set to 1, and there was no first indicator.