Bug 13382

Summary: RDA: 700/710/711 display in XSLT
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: MARC Bibliographic data supportAssignee: Winona Salesky <wsalesky>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: amber, amy, danielle, dcook, gwilliams, jesse, katrin.fischer, mtj, nick, nicole, rgravel, tomascohen, triciab, wsalesky
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14917
Change sponsored?: Sponsored Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 10344    
Attachments: Bug 13382: RDA 700s
Screenshot with empty contained works field
BUG 13382: RDA 700s
MARC record with contained works
RDA 700s display in XSLT
Bug 13382 - RDA: 700/710/711 display in XSLT
Smaple record to see all fields
Bug 13382 - RDA: 700/710/711 display in XSLT
Bug 13382 - RDA: 700/710/711 display in XSLT
Bug 13382 - RDA: 700/710/711 display in XSLT
[SIGNED OFF] Bug 13382 - RDA: 700/710/711 display in XSLT
[PASSED QA] Bug 13382 - RDA: 700/710/711 display in XSLT

Description Nicole C. Engard 2014-12-03 13:28:10 UTC
The following change should be made to the MARC21 details in the staff and OPAC:

Display 700, 710 and 711’s as Contributor(s) (full display)

Display corresponding subfields a, b, c, d, e, f, g, h, i, k, l, m, n, o, p, r, s, t, u, x

Display corresponding subfield e with term(s) in brackets; if there is more than one subfield e, list all terms within the brackets

Use vertical bar to separate multiple listings

Example:

Contributor(s): Gabriel, Philip, 1953­

Contributor(s): Schindler, S. D. [illustrator]

Contributor(s): Nolan, Christopher, 1970­ [film producer, screenwriter, director]

Contributor(s): Bernstein, Leonard, 1918­1990. | Beethoven, Ludwig van, 1770­1827. Symphonies, no. 3, op. 55, E♭ major. | Juilliard American Opera Center. Chorus.

Contributor(s): Director of photography, Tom Stern ; production designer, Philip Messina ; edited by Stephen Mirrione, Juliette Welfling ; costume designer, Judianna Makovsky ; music by James Newton Howard.
Comment 1 Nicole C. Engard 2014-12-03 13:31:59 UTC
Display all 700, 710 and 711’s with a subfield i as Related Works (full
display)

Related Works: Television adaptation of (work): Kerman, Piper. Orange is the new black.
Comment 2 Nick Clemens 2014-12-04 22:50:31 UTC
Any of these fields marked with second indicator 2 represent works that are contained by the title so maybe:

Display all 700, 710 and 711’s with a second indicator 2 as Contained Works (full
display)

Contained Works: Adams, Douglas. Hitchikers guide to the galaxy | Adams, Douglas. The restaurant at the end of the universe ...
Comment 3 rgravel 2014-12-05 14:24:58 UTC
Please note that the last example in the contributor(s) description does not apply.

I support Nick's addition; it would be great to capture those analytical entries, as well as the added entries and relationships documented in these fields: 

700/710/711 x_ - Contributor(s)
700/710/711 x_ $i - Related Works
700/710/711 x2 - Contained Works
Comment 4 Katrin Fischer 2014-12-08 21:20:58 UTC
Be careful, if there is an $e to display, you will want to ignore $4 in that case.

I am not sure about using | as a separator, it looks quite uncommon.
Comment 5 rgravel 2014-12-09 19:27:02 UTC
It should be a rare case that both an $e term and a $4 code are present in one field, since PCC guidelines instruct us not to use both. However, if a similar best practice is not observed internationally, then we should certainly amend the change to specify the $4 should be ignored in favor of the $e.
Comment 6 Katrin Fischer 2014-12-09 19:34:14 UTC
I know that currently for records in our union catalog both are used simultanously - so it would be an issue for our libraries.
Comment 7 Nicole C. Engard 2014-12-14 22:50:32 UTC
What separator would be best if not | ?
Comment 8 Winona Salesky 2014-12-15 15:29:52 UTC
Any thoughts on where in the record display you would like to see the additional 700 information (Related works for 700$i and Contained works 700@ind2=2). Perhaps following the "Other Title" display?

Another question about the contained work display:
How should s field be treated with a indicator 2 = 2 and a subfield i? Output twice? Once as Related Work, once as Contained Work? Just once as Contained Work?
  <datafield tag="700" ind1="1" ind2="2">
    <subfield code="i">Television adaptation of (work):</subfield>
    <subfield code="a">Kerman, Piper.</subfield>
    <subfield code="t">Orange is the new black.</subfield>
  </datafield>
Comment 9 David Cook 2014-12-16 23:12:35 UTC
(In reply to Nicole C. Engard from comment #0)
> The following change should be made to the MARC21 details in the staff and
> OPAC:
> 
> Display 700, 710 and 711’s as Contributor(s) (full display)
> 
> Display corresponding subfields a, b, c, d, e, f, g, h, i, k, l, m, n, o, p,
> r, s, t, u, x
> 
> Display corresponding subfield e with term(s) in brackets; if there is more
> than one subfield e, list all terms within the brackets
> 
> Use vertical bar to separate multiple listings
> 

Out of curiosity, where do these recommendations come from? 

I agree with Katrin that the vertical bar doesn't appear very attractive or common, but don't necessarily have a better option.
Comment 10 Nick Clemens 2014-12-16 23:23:18 UTC
 >Any thoughts on where in the record display you would like to see the
 >additional 700 information (Related works for 700$i and Contained works
 >700@ind2=2). Perhaps following the "Other Title" display?

I would support that, getting it out of the 'Additional authors' section is really what I would like to see

 >How should s field be treated with a indicator 2 = 2 and a subfield i?

I would say the presence of an $i would trump the second indicator

 >I agree with Katrin that the vertical bar doesn't appear very attractive or
 >common, but don't necessarily have a better option.

What about the use of a double hyphen -- ?  This is what is used in the 505 field to separate contents and seems to work visually
Comment 11 rgravel 2015-01-06 17:25:15 UTC
David, these suggested changes arose out of a project a colleague and I did at Marlboro College. We looked at how records are currently displaying, thought of ways to improve the display, particularly with an eye toward incorporating some RDA concepts like showing relationships, and asked ByWater whether the updates were possible. We then spoke with Nicole and she had the great idea of bridging the work we were doing with the larger Koha community, and so these bugs were created to flush out our ideas and get feedback. 

Regarding the vertical bar, we thought that might be a good choice for separating contributor listings because it parallels what is used to separate multiple subject headings and it provides a very clear visual clue that there are multiple, distinct bibliographic data points. We also suggested this solution for the 246 listings (see Bug 13386).  A semi-colon is currently used to separate all the 700s lumped into the "By" field and varying titles under "Other Title," which I think makes reading and interpreting the record more challenging since it doesn't break up the bits very well visually. 

To address Winona's questions: 
1) I would also support having the "Related Works" and "Contained Works" display after "Other Title."
2) If I understand this correctly, then I don't think there is a conflict, since a second indicator of 2 means it is a *contained work* and the appearance of a subfield $i means it is a *related work.* So, in the example you provided where there is a subfield $i, I would not code the second indicator as 2 to begin with, because the book is not contained in the DVD, but is rather a separate work related to the DVD; it cannot be both contained and related. But maybe others see this differently?
Comment 12 Amber Hunt 2015-01-07 14:28:28 UTC

> What about the use of a double hyphen -- ?  This is what is used in the 505
> field to separate contents and seems to work visually

The vertical bar (|) is used to separate subject headings and I think works quite nicely.
Comment 13 David Cook 2015-01-08 00:18:04 UTC
(In reply to Amber Hunt from comment #12)
> 
> > What about the use of a double hyphen -- ?  This is what is used in the 505
> > field to separate contents and seems to work visually
> 
> The vertical bar (|) is used to separate subject headings and I think works
> quite nicely.

I'm going to continue my Marlboro support today, and agree that the vertical bar/pipe (|) is probably the way to go. While notes uses "--", other parts of the detail page use the "|", so I think it's the way to go. Consistency as much as possible would probably be good.

I'm not a huge fan of the word "Contributor(s)", but I think it's probably good enough. If my librarians don't like it, I'm happy to change it on a case-by-case basis.

--

In summary, I think I'm in full support of the changes that Nicole has suggested.
Comment 14 Katrin Fischer 2015-01-08 09:28:28 UTC
> I am not sure about using | as a separator, it looks quite uncommon.

Still not sure, but not opposed :) Maybe if we would put it in a span with a class <span class="separator>|</span> - so that changing it to whatever is really easy later and also the color can be changed etc.
Comment 15 David Cook 2015-01-09 01:57:03 UTC
(In reply to Katrin Fischer from comment #14)
> > I am not sure about using | as a separator, it looks quite uncommon.
> 
> Still not sure, but not opposed :) Maybe if we would put it in a span with a
> class <span class="separator>|</span> - so that changing it to whatever is
> really easy later and also the color can be changed etc.

Good idea, Katrin!
Comment 16 Winona Salesky 2015-01-09 14:51:25 UTC
This sounds like a good resolution. 
Thanks!
-Winona
Comment 17 Nicole C. Engard 2015-01-29 20:26:39 UTC Comment hidden (obsolete)
Comment 18 Nick Clemens 2015-01-31 19:20:49 UTC
This wasn't marked 'Needs signoff' but I tested the patch just to see.  Only issue I saw on first glance through was that a 710 with second indicator two and presence of subfield i triggered an empty 'Contained works:' line.

The info in the field itself was correctly listed as "Related work"

When I deleted the 710 the empty entry dissappeared

Attaching a screenshot for "Orange is the new black" to illustrate
Comment 19 Nick Clemens 2015-01-31 19:21:46 UTC
Created attachment 35647 [details]
Screenshot with empty contained works field
Comment 20 Nicole C. Engard 2015-02-09 17:46:01 UTC Comment hidden (obsolete)
Comment 21 Nick Clemens 2015-02-21 15:06:34 UTC
The only issue I see is that when displaying at a 'Contained Work' the last character of the field preceding the relator terms is clipped.  

When displaying contributors all looks fine.
Comment 22 Winona Salesky 2015-02-23 15:12:54 UTC
(In reply to Nick Clemens from comment #21)
> The only issue I see is that when displaying at a 'Contained Work' the last
> character of the field preceding the relator terms is clipped.  
> 
> When displaying contributors all looks fine.

Thanks for catching that. I will make sure it gets fixed. 
-Winona
Comment 23 Winona Salesky 2015-03-04 14:21:12 UTC
Nick, 
Do you have a test record that has the issue with the chopped string? I have not turned this bug up with my test records.

Thanks for the help.
-Winona

(In reply to Nick Clemens from comment #21)
> The only issue I see is that when displaying at a 'Contained Work' the last
> character of the field preceding the relator terms is clipped.  
> 
> When displaying contributors all looks fine.
Comment 24 Nick Clemens 2015-03-04 23:39:37 UTC
Created attachment 36515 [details]
MARC record with contained works

When displaying the contained works with this patch the last character is chopped.  Presumably this is to remove punctuation, but for an incorrectly punctuated field or field ending in ')' this could be problematic. 

In the attached record the first 700 contained work is badly punctuated and the word orchestra is trimmed, for others a comma is trimmed and replaced with a ';' separator.  When testing it seems to be any character in the last field displayed

AFAIK subject fields will trim a '.' on display, but not a ')' so maybe just ensure only certain punctuation is trimmed if possible

Probably contained works should be separated by the '|' character as other fields are for consistency throughout
Comment 25 Winona Salesky 2015-03-11 02:38:38 UTC Comment hidden (obsolete)
Comment 26 Winona Salesky 2015-03-20 18:33:57 UTC Comment hidden (obsolete)
Comment 27 Nick Clemens 2015-03-25 19:23:32 UTC
Trying to check everything this time around, here are the few things I see:

1 - For related or contained works subfields n & p are not displaying
2 - 710/711 with subfield i appear in Contributors and not Related Works
3 - 710/711 with subfield i and 2nd indicator 2 do not appear
Comment 28 Nick Clemens 2015-03-25 19:25:01 UTC
Created attachment 37245 [details]
Smaple record to see all fields

This is just a sample record I used to put data into all the fields touched by this bug, it is not properly formatted but is helpful for testing
Comment 29 Winona Salesky 2015-03-26 13:03:25 UTC
Anyway I can get that attachment as MARCXML?

(In reply to Nick Clemens from comment #28)
> Created attachment 37245 [details]
> Smaple record to see all fields
> 
> This is just a sample record I used to put data into all the fields touched
> by this bug, it is not properly formatted but is helpful for testing
Comment 30 Winona Salesky 2015-04-02 17:00:43 UTC Comment hidden (obsolete)
Comment 31 Winona Salesky 2015-04-02 17:03:03 UTC
Thanks Nick for catching all of those. This patch should address the following issues:

1 - For related or contained works subfields n & p are not displaying
2 - 710/711 with subfield i appear in Contributors and not Related Works
3 - 710/711 with subfield i and 2nd indicator 2 do not appear

-Winona


(In reply to Winona Salesky from comment #30)
> Created attachment 37448 [details] [review] [review]
> Bug 13382 - RDA: 700/710/711 display in XSLT
> 
> Test Plan:
> 1) Apply this patch
> 2) Ensure you are using the default XSLT setting for the staff and opac
> search results and record details
> 3) Find or create a record with MARC tags 700,710,711
> 4) Perform an opac search that would show the record in the search results.
> 5) Click title to review record.
> 6) Note the fields updates 700,710,711 to show subfields a, b, c, d, e, f,
> g, h, i, k, l, m, n, o, p, r, s, t, u, x. Multiple fields are separated by
> span class=separator |. Adds Related and Contained Works as new headings.
> 7) Repeat steps 4 - 6 for the staff interface
Comment 32 Nick Clemens 2015-04-08 21:15:01 UTC Comment hidden (obsolete)
Comment 33 rgravel 2015-04-16 15:03:29 UTC
With our systems librarian on leave, I'm not able to do a done of patch testing, but I wonder: Are multiple relator terms displaying with the patch, like in the below example? Thanks!

Contributor(s): Nolan, Christopher, 1970­ [film producer, screenwriter, director]
Comment 34 Winona Salesky 2015-04-17 14:03:05 UTC
Yes, they are. Although, now that I am looking back through the code, I only handle multiple $e, if there are multiple $4 it only displays 1. Should I change that, or is that unlikely to be an issue?

-Winona


(In reply to rgravel from comment #33)
> With our systems librarian on leave, I'm not able to do a done of patch
> testing, but I wonder: Are multiple relator terms displaying with the patch,
> like in the below example? Thanks!
> 
> Contributor(s): Nolan, Christopher, 1970­ [film producer, screenwriter,
> director]
Comment 35 rgravel 2015-04-17 15:34:58 UTC
Great, thank you for that confirmation. 

Katrin, for example, may have a better answer for you on the multiple $4's, since her consortium uses the relator codes. If multiple $e's are used, then presumably multiple $4's have been used. 

(In reply to Winona Salesky from comment #34)
> Yes, they are. Although, now that I am looking back through the code, I only
> handle multiple $e, if there are multiple $4 it only displays 1. Should I
> change that, or is that unlikely to be an issue?
> 
> -Winona
Comment 36 Katrin Fischer 2015-04-17 15:36:39 UTC
I think they would match up - I can and find out beginning next week.
Comment 37 Katrin Fischer 2015-04-21 08:33:52 UTC
I have checked with my coworkers, there will be mulitple $e and multiple $e, appearing in pairs, where the sequence in the field matters.
Comment 38 Winona Salesky 2015-04-21 13:40:39 UTC
Okay, I will need to add that for the multiple $e. Will try to get to it tonight.
Thanks,
-Winona

(In reply to Katrin Fischer from comment #37)
> I have checked with my coworkers, there will be mulitple $e and multiple $e,
> appearing in pairs, where the sequence in the field matters.
Comment 39 Katrin Fischer 2015-04-21 21:03:45 UTC
With the other patches pushed, this one does no longer apply. Please fix your patch and switch back to 'signef off' again!
Comment 40 Winona Salesky 2015-04-22 01:57:42 UTC
Thanks I will do that. 
However, I think this bug and 13383, introduce some contradictory logic. I will push this one first, once it gets signed off and is pushed to master I will rework #13383 so they play nicely together. 

-Winona



(In reply to Katrin Fischer from comment #39)
> With the other patches pushed, this one does no longer apply. Please fix
> your patch and switch back to 'signef off' again!
Comment 41 Winona Salesky 2015-04-22 02:51:45 UTC Comment hidden (obsolete)
Comment 42 Nick Clemens 2015-04-24 20:42:33 UTC Comment hidden (obsolete)
Comment 43 Kyle M Hall 2015-06-04 10:49:21 UTC
Created attachment 39843 [details] [review]
[PASSED QA] Bug 13382 - RDA: 700/710/711 display in XSLT

Test Plan:
1) Apply this patch
2) Ensure you are using the default XSLT setting for the staff and opac record details
3) Find or create a record with MARC tags 700,710,711
4) Perform an opac search that would show the record in the search results.
5) Click title to review record.
6) Note the fields updates 700,710,711 to show subfields a, b, c, d, e, f, g, h, i, k, l, m, n, o, p, r, s, t, u, x. Multiple fields are separated by span class=separator |. Adds Related and Contained Works as new headings.
7) Repeat steps 4 - 6 for the staff interface

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 44 Tomás Cohen Arazi 2015-06-04 13:19:44 UTC
Patch pushed to master.

Great job Winona!
Comment 45 Katrin Fischer 2015-06-06 17:46:12 UTC
This patch causes several problems:

1) Repeated 7xx are not correctly displayed. Example with 3 700:
Contributor(s): Wiesflecker, HermannNovotny, Alexander [ed.]Pickl, Othmar [ed.] |
Missing separators and spaces between names.
2) There is always a pipe appearing at the end of the "Contributors".
3) Also, the little icon to the authority record is broken by this patch.

Please fix asap.
Comment 46 Winona Salesky 2015-06-07 01:35:32 UTC
I have a patch for this. What is the correct way to add it? I can not change the status to needs sign off, Should I add a new bug, and submit the patch that way, or is there a way to amend a patch that has been pushed to master? 

Thanks for the help! 
-Winona



(In reply to Katrin Fischer from comment #45)
> This patch causes several problems:
> 
> 1) Repeated 7xx are not correctly displayed. Example with 3 700:
> Contributor(s): Wiesflecker, HermannNovotny, Alexander [ed.]Pickl, Othmar
> [ed.] |
> Missing separators and spaces between names.
> 2) There is always a pipe appearing at the end of the "Contributors".
> 3) Also, the little icon to the authority record is broken by this patch.
> 
> Please fix asap.
Comment 47 Katrin Fischer 2015-06-07 01:43:06 UTC
Hi Winona, I think best to add a new bug and link it to this one - that way there will be no confusion about the status.
Comment 48 Katrin Fischer 2015-06-07 01:43:20 UTC
And thx for the quick reply :)
Comment 49 Winona Salesky 2015-06-08 01:37:12 UTC
Sorry for the delay, had some git bz issues this morning. See new patch:
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14359

(In reply to Katrin Fischer from comment #48)
> And thx for the quick reply :)
Comment 50 Jonathan Druart 2015-10-01 09:53:08 UTC
*** Bug 14359 has been marked as a duplicate of this bug. ***
Comment 51 Danielle Elder 2016-04-14 15:30:59 UTC
Hello, the subfields are out of order.

Marc is: 

  700 1# - ADDED ENTRY--PERSONAL NAME

  a Personal name Caspary, Vera,

  d Dates associated with a name 1899-1987.

  t Title of a work Laura.

Displays as such:

   700, a,t,d

from catalog Normal View:

   Caspary, Vera, Laura 1899-1987. 

Can the subfields be ordered alphabetically?
Comment 52 Danielle Elder 2016-04-14 15:38:17 UTC
Hello, the subfields are out of order.

Marc is: 

  700 1# - ADDED ENTRY--PERSONAL NAME

  a Personal name Caspary, Vera,

  d Dates associated with a name 1899-1987.

  t Title of a work Laura.

Displays as such:

   700, a,t,d

from catalog Normal View:

   Caspary, Vera, Laura 1899-1987. 

Can the subfields be ordered alphabetically?
Comment 53 Katrin Fischer 2016-04-14 15:52:35 UTC
Hi Danielle, alphabetic order is not always correct with MARC21 - it should depend on the order you catalog them in.
Comment 54 Katrin Fischer 2016-04-14 15:53:19 UTC
Just saying... it's a lot trickier.
Comment 55 Danielle Elder 2016-04-14 15:57:05 UTC
Katrin, 

Do you mean the order of data input or the order of the tags in the editor? 

I tried data input order, and that didn't change anything.
Comment 56 Winona Salesky 2016-04-14 16:02:18 UTC
Output of subfields should follow the order they appear in the MARC record. If you are finding this is not the case perhaps you can share your record? (In MARCXML)
Comment 57 Katrin Fischer 2016-04-14 16:03:30 UTC
I think the problem is when we need additional formatting (wrap subfields in links, spans etc) and that makes it harder to keep the catalogued sequenence for output. - I am not sure how to solve that. My guess is that the $d is stuck at the end currently because I wrapped it into span for being able to hide the dates in the OPAC. *hidesherself*
Comment 58 Winona Salesky 2016-04-14 16:09:23 UTC
I don't see dates being treated any differently, no spans or classes? (In the master branch).
Comment 59 Katrin Fischer 2016-04-14 16:11:01 UTC
Hi Winona - take a look at the changes from bug 15100.
Comment 60 Winona Salesky 2016-04-14 16:16:06 UTC
Ahh, I see. Well, this could be handled more easily by using apply-templates rather then call-template. That would retain subfield order and allow different treatment where needed for subfields.
Comment 61 Patricia Brauer 2016-04-18 18:23:21 UTC
Comment 56 asked for an example. We have a title Women crime writers where several of the 700 fields have inverted the author's date subfield with the title field. See http://catalog.roundrocktexas.gov/cgi-bin/koha/opac-detail.pl?biblionumber=189060. Specifically: ex.1) Caspary, Vera, Laura 1899-1987. should be: Caspary, Vera, 1899-1987. Laura. -- ex.2) Hughes, Dorothy B. In a lonely place 1904-1993. should be: Hughes, Dorothy B.,1904-1993. In a lonely place. -- ex. 3) Holding, Elisabeth Sanxay, The blank wall 1889-1955. should be: Holding, Elisabeth Sanxay, 1889-1955. The blank wall. There are 3 more examples in this record alone.  Another example is Dancing home. See: http://catalog.roundrocktexas.gov/cgi-bin/koha/opac-search.pl?idx=ti&q=dancing+home. Darío, Rubén, A Margarita 1867-1916. should be Darío, Rubén, 1867-1916. A Margarita.
Comment 62 Winona Salesky 2016-04-18 20:51:37 UTC
It looks like the problem with the subfield order was introduced in bug #15100, not this bug. Perhaps, the comments should move to that thread? I think a better solution then the one in place would be to use xsl:apply templates to specify special handling for dates. This would retain subfield order and also allow for manipulation of specific subfields.
Comment 63 Katrin Fischer 2016-04-18 20:56:01 UTC
Winona, you are right, this bug didn't cause it. Best would be to file a new bug and link it 'depend on' with bug 15100 - because both this and the other bug have already been pushed. While causing the problem, I am not sure yet about how to fix it properly. It will probably take me a while - any help would be much appreciated.
Comment 64 Winona Salesky 2016-04-19 13:49:19 UTC
I will be happy to help.
Comment 65 Danielle Elder 2016-04-20 14:57:41 UTC
I did a quick search and didn't see a new bug created, do you want me to open one with the dependency on 15100?
Comment 66 Katrin Fischer 2016-04-20 16:48:01 UTC
yes please!
Comment 67 Jesse Maseto 2016-12-19 18:46:55 UTC
Right now the 700s displaying as "by [author's name]" in search results. Is there a way to leave off the "by" in some cases?