https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Joy Nelson <joy@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |wizzyrea@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wizzyrea@gmail.com --- Comment #1 from Liz Rea <wizzyrea@gmail.com> --- Hi Joy, Do you want this in just the OPAC or in both the OPAC and the Staff interface? Cheers, Liz -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #3 from Joy Nelson <joy@bywatersolutions.com> --- Liz- I would like to see this on both OPAC and staff side For the results/display pages, can you make it behave in a similar way to the 490/830 combination? i.e. if the 830 appears when 490 ind1=1 on both, make the standalone 830 appear on both. If 830/490 appears only on details, make standalone show on 830, etc. Thanks joy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #5 from Hannah Olsen <holsen@duncanville.com> --- The 800 has the same issue, for sure. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Liz Rea <wizzyrea@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #6 from Liz Rea <wizzyrea@gmail.com> --- Hi Hannah, I'm glad that you are here, because I could really use some help - it would be absolutely awesome if you could provide a few records that show all the ways this could be used - with a traced series, without, with an 830/800/810/811. Anything record wise you can provide will help a lot. :) Thanks, Liz -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #8 from Liz Rea <wizzyrea@gmail.com> --- Lovely, thank you! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- The current logic follows this (if I am not completely mistaken), which is based on the data I was working with and how I understand the standard: If it's a traced series (1st indicator =1), there will be a 490 + 8xx couple of fields. In this case we display the information from 8xx. One main reason being that the $w subfield used to link to a traced series record is only present in 8xx. If the series is not traced (1st ind = 0), there is no corresponding 8xx, so we display the information in 490. If we changed this to display always 490 independent of the indicator (traced/untraced) a lot of information would show doubled up, once linked by phrase search and once by record control-number (if it exists like in our case). The solution would be to make sure if there is a corresponding 8xx for a 490 and make the decision based on that. One record can have multiple traced and untraced 490 entries in whatever sequence. I am really not sure how to make this work with XSLT means. Looking at the LOC page, $a don't have to match and there is even an example with one 490 and 2 corresponding 8xx. -- http://www.loc.gov/marc/bibliographic/bd490.html 0 - Series not traced No series added entry is desired for the series. 1 - Series traced When value 1 is used, the appropriate field 800-830 is included in the bibliographic record to provide the series added entry -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #10)

If we changed this to display always 490 independent of the indicator (traced/untraced) a lot of information would show doubled up, once linked by phrase search and once by record control-number (if it exists like in our case).

I looked at a few of public catalogues this morning (Library of Congress, National Library of Australia, and Vancouver Public Library) and they all showed both the 490 and 8xx records, although in all those cases they either had phrase searches for 490 and 8xx or just display 490 and phrase search for 8xx. If that's the common behaviour, maybe it's worth emulating it. (Although that brings to mind the saying "would you jump off a cliff if all your friends were doing it too?")

The solution would be to make sure if there is a corresponding 8xx for a 490 and make the decision based on that. One record can have multiple traced and untraced 490 entries in whatever sequence. I am really not sure how to make this work with XSLT means. Looking at the LOC page, $a don't have to match and there is even an example with one 490 and 2 corresponding 8xx.

490 and 8xx fields are both repeatable and I haven't seen any documented or real life examples of precise correspondence between them.

http://www.loc.gov/marc/bibliographic/bd490.html 0 - Series not traced No series added entry is desired for the series.

1 - Series traced When value 1 is used, the appropriate field 800-830 is included in the bibliographic record to provide the series added entry

I don't know why you would have a 8xx without a 490, but Joy mentioned that she has experience with that, and technically https://www.loc.gov/marc/bibliographic/bd830.html says "an 830 field is usually justified by a series statement (field 490) or a general note (field 400) relating to the series. For reproductions, it may be justified by a series statement in subfield $f of field 533 (Reproduction Note)." -- On a separate note, have we considered at all replacing the $9 with $0? It was only added to the MARC standard in 2007, so I suppose that's maybe too recent for most data to align with it. Plus, the $0 is repeatable, so not really useful for "linking" a bibliographic record to an authority record for search/indexing purposes. -- I've actually come to this bug report, because I've found issues with "se,phr", but that's another conversation for another day... (I've posted on the Zebra list about it though...) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #13)

Just a quick note on $0 vs. $9:

Linking between bibliographic and authorities => $0 ($9 Koha) Linking between bibliographic records => $w ($w Koha)

Except in Koha I think $9 and $w are non-repeatable (maybe not $w but certainly $9) whereas in the MARC spec $0 and $w are repeatable subfields.

Our data is converted to MARC from an internal format in the union catalog, so in some cases it's stricter MARC and more consistent than manually created MARC data I guess.

Wouldn't the opposite usually be true? Personally, I find translating other formats to MARC usually leads to looser MARC since other formats don't capture the same level of detail as MARC?

There is another note that says 8xx can appear with 500, so it probably depends on where you look at the standard documents. I think Joy's case is valid, but I really don't want to display both the 490 and 8xx in case they contain nearly the same information. I know I'd have to change it for our libraries... but it would be much nicer to find some common ground.

Wouldn't the common ground be how other systems than Koha show the 490 and 8xx? Kind of an industry level common ground. That said, I think this is one of those issues where every library does things differently and handles their legacy data differently, so it's hard to be all things to all people. Many of my libraries don't even use authorities, so it won't matter to them, and libraries that do use authorities and don't like the default can use a custom XSLT if necessary.

The linking of 490 and corresponding 8xx is indeed problematic to impossible - at least I haven't found a solution apart from the currently implemented. But I think it shoudl be possible to allow for the use case Joy pointed out.

- Always display 8xx - Keep logic for 490 - display when Ind.1=0 (not traced)

It's been like this for a long time and this just recently popped up, so I hope the 490 logic is agreeable.

That sounds reasonable. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 --- Comment #16 from Hannah Olsen <holsen@duncanville.com> --- The issue we had was 600+ items (primarily audiobooks) without series statements on the items themselves to transcribe into the 490. However, the series existed and are traced, so the 8xx were present in the records. But Koha would not display the 8xx fields because there was no 490. The fix needed is displaying the 8xx even when there is no 490, as Katrin described. I can see displaying the 8xx instead of a 490 1, and the 490 0 displays. Many ILSes do display both all the time, but one could argue that goes against the MARC concept (assuming that both 490 and 8xx are indexed for searching, which they are in Koha). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |DUPLICATE --- Comment #17 from Phil Ringnalda <phil@chetcolibrary.org> --- *** This bug has been marked as a duplicate of bug 13600 *** -- You are receiving this mail because: You are watching all bug changes.