Bug 22820 - Display 830 series information when there is no 490 tag (MARC21)
Summary: Display 830 series information when there is no 490 tag (MARC21)
Status: RESOLVED DUPLICATE of bug 13600
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Liz Rea
QA Contact: Testopia
URL:
Keywords:
: 12991 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-05-01 14:07 UTC by Joy Nelson
Modified: 2023-07-15 21:32 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joy Nelson 2019-05-01 14:07:36 UTC
Currently, the 830 tag will display only when the 490 tag is present and indicator 1=1.  It is possible to have a valid 830 tag without a corresponding 490 tag.  We need to include logic in the stylesheet to display the 830 when no 490 is found.
Comment 1 Liz Rea 2019-05-07 16:05:42 UTC
Hi Joy,

Do you want this in just the OPAC or in both the OPAC and the Staff interface?

Cheers,
Liz
Comment 2 Liz Rea 2019-05-07 16:07:11 UTC
Oh, and also - results and details views both? Or just details?

Liz
Comment 3 Joy Nelson 2019-05-07 16:12:34 UTC
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
Comment 4 Katrin Fischer 2019-05-07 17:25:34 UTC
I am wondering, is this only the case for 830 or the other 8xx fields too that can appear in combination with 490? (800, 810, 811...)
Comment 5 Hannah Olsen 2019-05-07 17:36:29 UTC
The 800 has the same issue, for sure.
Comment 6 Liz Rea 2019-05-08 14:28:48 UTC
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
Comment 7 Hannah Olsen 2019-05-08 18:39:22 UTC
Sure! 

800 only example: https://duncanville.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=16910 This book was not an official traced series until book 8 or so, and there was no series statement on the books. Now that there finally is an official series tracing, we've switched to that from our in-house one. But because one transcribes the 490, there is no 490. Most of our other examples are similar.

I had a hard time finding an 830 only example, but here's one. https://duncanville.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=138322 

490/800 example: https://duncanville.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=142808 

490/830 example: https://duncanville.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=125716

490 alone example. The series info is displayed in the item details. https://duncanville.bywatersolutions.com/cgi-bin/koha/opac-detail.pl?biblionumber=149541

We don't have 810s/811s.
Comment 8 Liz Rea 2019-05-08 18:59:19 UTC
Lovely, thank you!
Comment 9 David Cook 2019-07-09 03:01:28 UTC
I'm looking at series at the moment as well, and thinking that 800/810/811/830 shouldn't be dependent on the 490. 

The current way we do it is problematic anyway. The 490 is a repeatable field, but we're testing if there is any 490 with a first indicator of 1. That doesn't really make sense.
Comment 10 Katrin Fischer 2019-07-09 05:56:19 UTC
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
Comment 11 Katrin Fischer 2019-07-09 05:59:07 UTC
(In reply to David Cook from comment #9)
> I'm looking at series at the moment as well, and thinking that
> 800/810/811/830 shouldn't be dependent on the 490. 
> 
> The current way we do it is problematic anyway. The 490 is a repeatable
> field, but we're testing if there is any 490 with a first indicator of 1.
> That doesn't really make sense.

I guess we could turn the logic... still show 490 dependent on indicator, but always show the 8xx?
Comment 12 David Cook 2019-07-09 08:09:55 UTC
(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...)
Comment 13 Katrin Fischer 2019-07-09 09:43:08 UTC
Just a quick note on $0 vs. $9:

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

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. 

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.

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.
Comment 14 David Cook 2019-07-10 00:56:30 UTC
(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.
Comment 15 David Cook 2019-07-10 00:56:56 UTC
(In reply to Katrin Fischer from comment #13)
> It's been like this for a long time and this just recently popped up, so I
> hope the 490 logic is agreeable.

That reminds me of another issue I found which I still need to report...
Comment 16 Hannah Olsen 2019-07-12 15:26:34 UTC
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).
Comment 17 Phil Ringnalda 2023-07-05 23:44:08 UTC

*** This bug has been marked as a duplicate of bug 13600 ***
Comment 18 Katrin Fischer 2023-07-15 21:32:18 UTC
*** Bug 12991 has been marked as a duplicate of this bug. ***