The following change should be made to the MARC21 details in the staff and OPAC: 245 Display complete title and statement of responsibility at the beginning of the record (brief/full display) Display corresponding subfields a, b, c, k, n, p, s Suppress the display of subfield h [GMD] in the title Examples: Franz Kafka : the office writings / edited by Stanley Corngold, Jack Greenberg, and Benno Wagner ; translations by Eric Patton with Ruth Hein. Kafka on the shore / Haruki Murakami ; translated from the Japanese by Philip Gabriel. The hunger games / directed by Gary Ross ; screenplay by Gary Ross and Suzanne Collins and Billy Ray ; produced by Nina Jacobson, Jon Kilik ; a Lionsgate presentation ; a Color Force/Lionsgate production ; a Gary Ross film.
[07:36] <cait> nengard: not sure about hiding h in 245 [07:37] <cait> we use that quite a lot and it helps identifying electronic resources in the result list
Hi, I am working on the XSLT and would like to know how users feel about displaying subfield h separated from the title. Perhaps next to the Medium label, rather then suppressing it. Example below: Concerto for orchestra ; Music for strings, percussion & celesta [sound recording] / Béla Bartók. Author(s): Bartók, Béla. Additional author(s): Bernstein, Leonard; Bartók, Béla; New York Philharmonic [prf]. Would become: Concerto for orchestra ; Music for strings, percussion & celesta / Béla Bartók. Author(s): Bartók, Béla. Additional author(s): Bernstein, Leonard; Bartók, Béla; New York Philharmonic [prf]. Format: sound recording Thanks.
That label should be: Medium: sound recording
Created attachment 34464 [details] [review] Bug 13381 [ENH] 245 field enhancements
Hi Winona, thx for working on this :) My impression is that with RDA a lot more persons/authors can be added to a record, so I'd prefer the medium to be a bit more prominent - especially in the result list. I am not sure how to achieve that best. Not a lot of people are following the bug list or are added cc here - maybe try emailing the Koha main list to lead more people here?
This is certainly an interesting one. As LOC notes, the AACR2 GMD is replaced by the 336, 337, and 338 in RDA. As a result, I'm not sure about putting the 245$h into its own "Medium" field, as the 337 already represents "Media type". However, I don't think it would be a good idea to put the GMD into the "Media type" field if a 337 isn't available. If a record has a GMD, I think librarians would expect to see it in the title. I suppose a patron might expect to see it in a Medium field... but I think having Medium/Media would be confusing, especially if a record accidentally has a 245$h and a 337... I don't know. The "funny" thing about MARC is that we could also be determining medium from the 007 or the leader or a combination... In a way, there are too many options and none of them are consistently helpful to end users :S. I don't like the idea of cluttering a screen with all the different format options, but re-using labels can also be confusing. Of course, at the end of the day, we use custom XSLTs for everyone, so I don't have too much of a vested interest in this one, except apart from not wanting to overly customize our own versions. -- As a side note, why do we want to add the statement of responsibility back into the top of the record? Is that a RDA requirement? It looks awful... while it might be something librarians like, I imagine patrons wouldn't like it too much.
(In reply to David Cook from comment #6) > This is certainly an interesting one. As LOC notes, the AACR2 GMD is > replaced by the 336, 337, and 338 in RDA. > > As a result, I'm not sure about putting the 245$h into its own "Medium" > field, as the 337 already represents "Media type". However, I don't think it > would be a good idea to put the GMD into the "Media type" field if a 337 > isn't available. > > If a record has a GMD, I think librarians would expect to see it in the > title. I suppose a patron might expect to see it in a Medium field... but I > think having Medium/Media would be confusing, especially if a record > accidentally has a 245$h and a 337... My thought here is that no library can afford to re catalog their collection so their old records will still have the GMD and we should show that. So I'm thinking an IF statement. Show the 337 next to Media type if it's there but if it's not then show the GMD. > > As a side note, why do we want to add the statement of responsibility back > into the top of the record? Is that a RDA requirement? It looks awful... > while it might be something librarians like, I imagine patrons wouldn't like > it too much. I agree - the author should be where it was - no reason to move it up.
Okay. I think a reasonable approach would be to leave off subfield c, and add a test if a record accidentally has a 245$h and a 337 and only show one. -Winona
Just for clarification, there is currently no "Media type" in the record. We want to add a test to check for 337, if no 337, show 245$h? Thank you. -Winona
(In reply to Winona Salesky from comment #9) > Just for clarification, there is currently no "Media type" in the record. We > want to add a test to check for 337, if no 337, show 245$h? > > Thank you. > -Winona I'm not sure I understand. Do you mean that the XSLT doesn't currently show the 337?
(In reply to Winona Salesky from comment #9) > Just for clarification, there is currently no "Media type" in the record. We > want to add a test to check for 337, if no 337, show 245$h? > > Thank you. > -Winona The logic sounds right to me
Comment received via email: --------- Can the suppression of the 245h be an optional choice? Even though it is not being used in RDA records, some people like to see it if is there. In AACR2 records, without the 336, 337, 338 fields it may be harder for patrons to tell what format the item is if the h subfield is suppressed.
Maybe it would work to wrap $h in a <span> with a class? easy to hide then if you don't want to see it in the title :)
Created attachment 34996 [details] [review] Bug 13381 [2] - RDA: 245 field changes in XSLT
Created attachment 34997 [details] [review] Bug 13381 - RDA: 245 field changes in XSLT
Statement of Responsibility: I am a cataloger and I do like the full statement of responsibility, ie the whole 245 field, to display at the top of the record. I think it is in fact helpful to patrons, because it is written in plain language and so clearly indicates to a patron whether the record they've found matches their needs. It is fairly common in other systems and academic libraries to include the full statement, because it readily helps patrons understand what the record is a surrogate for, i.e. which book exactly the record really represents. Furthermore, sometimes the statement differs from what is included in 100s and 700s, because it is up to the cataloger's taste and judgement to decide whether to make an access point for those folks listed in the statement. So, as a result, you could have important bibliographic information included in the statement, but no where else in the record, which is another reason I think many systems chose to display it. GMD/Medium: Because there will be a mix of legacy AACR2 and new RDA records in our catalogs, we can no longer *consistently* rely on the GMD as the indicator of medium. The good news is, there are other indicators in the record that are consistent across AACR2 and RDA records, like the material type that is pulled from MARC's fixed fields/leader and already populates a Type tag in the record; a new medium or format tag that pulled the GMD in would be duplicative of this in my opinion. The type selected for the items, as well as any call number prefixes that might be use for DVDs or Ebooks, as also consistent indicators, not to mention RDA's new 33x fields.
(In reply to rgravel from comment #16) > Statement of Responsibility: > I am a cataloger and I do like the full statement of responsibility, ie the > whole 245 field, to display at the top of the record. I think it is in fact > helpful to patrons, because it is written in plain language and so clearly > indicates to a patron whether the record they've found matches their needs. > It is fairly common in other systems and academic libraries to include the > full statement, because it readily helps patrons understand what the record > is a surrogate for, i.e. which book exactly the record really represents. > Hmm, fair enough. As a patron, I suppose I would prefer to see "Moby Dick / Herman Melville ; retold by Kathy Burke." rather than just "Moby Dick". As you say, it's a more accurate surrogate that way. Of course, if you have a lengthy statement of responsibility, the detail page is going to get awfully crowded as the title/statement of responsibility area is currently in a h1 element with a font size of about 140%. It's not so bad in the search results where the title/statement of responsibility is in an a element with about 104% font size. I suppose as a patron, (technical services) librarian, and developer, I'd like the display to be as useful as possible while also being usable/aesthetically pleasing. Maybe changing the font size for the h1 to 120% instead of 140% will allow for an easier to read heading, when more text is displayed. > Furthermore, sometimes the statement differs from what is included in 100s > and 700s, because it is up to the cataloger's taste and judgement to decide > whether to make an access point for those folks listed in the statement. So, > as a result, you could have important bibliographic information included in > the statement, but no where else in the record, which is another reason I > think many systems chose to display it. > Very true, especially in the case of AACR2 records where the "rule of three" was encouraged. That said, if I recall correctly, cataloguers can choose to snip the statement of responsibility as well if it's too long... but then that sort of negates my earlier point about being concerned about overly long statements of responsibility ;). > GMD/Medium: > Because there will be a mix of legacy AACR2 and new RDA records in our > catalogs, we can no longer *consistently* rely on the GMD as the indicator > of medium. The good news is, there are other indicators in the record that > are consistent across AACR2 and RDA records, like the material type that is > pulled from MARC's fixed fields/leader and already populates a Type tag in > the record; a new medium or format tag that pulled the GMD in would be > duplicative of this in my opinion. The type selected for the items, as well > as any call number prefixes that might be use for DVDs or Ebooks, as also > consistent indicators, not to mention RDA's new 33x fields. Unfortunately, most of the records I encounter don't have any data or correct data in the fixed fields/leader when it comes to the material type. I work mainly in special libraries where knowledge of library cataloguing standards, which can be readily found in public and academic libraries, is much more rare. On one hand, this can be incentive to clean-up old records and re-train staff to catalogue more "properly". On the other hand, no one in special libraries has time or money for that. In theory, I'd like to rely on the leader and the fixed fields, but in practice I find that cataloguers just aren't consistent enough. That's why I think libraries introduced the RDA 33x fields. All that data was already there, but now there is an easier (albeit also error-prone) way of writing it out. But yeah... 33x fields, leader/fixed fields, item type, GMD, call number prefixes... there isn't a whole lot of consistency or reliability. In all honesty, I've been thinking about the possibility of introducing a Koha-specific "record type". It seems that this sort of thing is pretty common in other systems like Summon and EDS. It would be indexed, so you could search it specifically or you could use it as a facet. It would display in the search results and on the detail page, so that patrons could easily see what sort of record the library deems it to be. The advantage of a record type over an item type is that item type is currently mixed up between items and bib records via the 942$c. It would be a high-level record type - completely unrelated to MARC - which would be based on improving discoverability. Why should we be bound to MARC? Ebsco and Serial Solutions ignore it/enhance it, and people love their systems and laud them for "discovery". (Of course, adding a Koha-specific "record type" would make bulk importing records more difficult without a predefined mapping to use something in MARC to map to the Koha-specific "record type") -- In summary, I'm sold on the statement of responsibility. Let's do it up. As for the Medium stuff... I still don't know the best solution.
I am ok with displaying the statement of responsibility, but would suggest wrapping it in a <span> with a nice class so libraries can decide to hide it easily and that way get back to the old display - and also use a similar technique for the $h. --- About the "material type" information: If I understood correctly. 245$h is going to go away and the coded fields LDR/007/008 as well. So we will need to put some thought into how we want to display material type information in future. The existing code for the material type is a bit messy - for example the display logic for the result page differs from the detail page. I think cleaning that up would be a good first step. For example we can put the logic in a template that will be used on both pages. Then we could add support of 336-338 and display this information instead whenever they exist. We also have to keep in mind that the new fields are repeatable. Suggestion: Make only changes to the title on this bug and move the bigger task of displaying good material type information into a separate bug.
(In reply to Katrin Fischer from comment #18) > Suggestion: Make only changes to the title on this bug and move the bigger > task of displaying good material type information into a separate bug. +1
Marking as ASSIGNED as current patch doesn't seem to do what I think everyone has agreed. My understanding at the end of of this is: The following change should be made to the MARC21 details in the staff and OPAC: 245 Display complete title and statement of responsibility at the beginning of the record (brief/full display) Subfield c (statement of responsibility) and subfield h (medium) should be displayed, but wrapped in a <span> with a class to make them easily selectable/editable for styling/hiding.
Hi All, I am finishing up on this bug. It seems to me that there is agreement on the statement of responsibility being included within a <span>. However, my understanding is that issue with subfield h is more complicated and should be moved to a a new bug, in which case, for this bug, I will simply add a span so it can be suppressed and the more complex logic can be worked out in a future bug. Hope that works for everyone. -Winona
Created attachment 36783 [details] [review] Bug 13381 - RDA: 245 field changes in XSLT
Created attachment 37067 [details] [review] Updates for #13381 This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client
Created attachment 37068 [details] [review] Updates display of 245 field Updates for #13381 This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client
Created attachment 37069 [details] [review] Updates display of 245 field Updates for #13381 This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client
Created attachment 37070 [details] [review] Bug 13381 - RDA: 245 field changes in XSLT This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client
Created attachment 37228 [details] [review] [SIGNED OFF] Bug 13381 - RDA: 245 field changes in XSLT This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Created attachment 37982 [details] [review] [PASSED QA] Bug 13381 - RDA: 245 field changes in XSLT This patch updates the display of the title and statement of responsibility in the XSLT display in the staff and OPAC. Display includes subfields a,b,c,h,k,n,p,s Subfield c is wrapped in a span class=title_resp_stmt for easy suppression via css. Subfield h is wrapped in a span class=title_medium for easy suppression via css. To test: * Search the opac * Click the title * Make sure the fields display properly * Repeat for a few more titles * Repeat in the Staff Client Signed-off-by: Nick Clemens <nick@quecheelibrary.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Pâtch pushed to master. Thanks Winona!
Great! Thanks, -Winona (In reply to Tomás Cohen Arazi from comment #29) > Pâtch pushed to master. > > Thanks Winona!
Thank you all for this very useful enhancement! It would be great if the 'full' 245 (ie a, b, c, k, n, p, s subfields) could also be displayed in Item search results and Serial subscription results (right now only 245a is displayed under the title columns)!
Hi Theodoros, technically the display works differently there - not using XSLT. Can you please file separate reports for those pages?
Sure thing Katrin! (In case anyone in the future needs the link, the new enhancement request is found here: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14911)
I suppose it's way too late for this so someday I'll make a different bug but... I think the following: <xsl:for-each select="marc:subfield[contains('bchknps', @code)]"> Should actually be: <xsl:for-each select="marc:subfield[contains('hbcknps', @code)]"> If you look at the LoC website (http://www.loc.gov/marc/bibliographic/bd245.html), you'll see that $h is always between $a and $b. -- Ahh... interesting... in the "CONTENT DESIGNATOR HISTORY", you'll see an explanation for this: "Prior to 1994, AACR2 cataloging rules required that the medium designator be recorded following other title information and all the title in works lacking a collective title. In Pre-1994 records, subfield $h generally follows subfield $b and even subfield $c in some cases." However, in post-1994 records, that does not appear to be the case. If anyone has access to the AACR2*, they could verify this. *Have to love closed standards in libraries. Terry Reese has a good post about this: http://blog.reeset.net/archives/1100
The order in the for-each does not determine the order of the output. Subfields are output in the order they appear in the marc record. They are in alphabetical order in the for-each, purely for convenience sake. -Winona (In reply to David Cook from comment #34) > I suppose it's way too late for this so someday I'll make a different bug > but... > > I think the following: > > <xsl:for-each select="marc:subfield[contains('bchknps', @code)]"> > > Should actually be: > > <xsl:for-each select="marc:subfield[contains('hbcknps', @code)]"> > > If you look at the LoC website > (http://www.loc.gov/marc/bibliographic/bd245.html), you'll see that $h is > always between $a and $b. > > -- > > Ahh... interesting... in the "CONTENT DESIGNATOR HISTORY", you'll see an > explanation for this: > > "Prior to 1994, AACR2 cataloging rules required that the medium designator > be recorded following other title information and all the title in works > lacking a collective title. In Pre-1994 records, subfield $h generally > follows subfield $b and even subfield $c in some cases." > > However, in post-1994 records, that does not appear to be the case. If > anyone has access to the AACR2*, they could verify this. > > *Have to love closed standards in libraries. Terry Reese has a good post > about this: http://blog.reeset.net/archives/1100
It seems that the change in the xslt to put span around subfields c and h has removed the space that was generated between the subfields. In koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl there is an: <xsl:text> </xsl:text> at line 125 in the otherwise clause that spaces out the subfields. The two that were singled out do not have this. Adding them back in within the <span> achieves the normal, desired spacing.
Hi Ian, can you please file this as a separate bug report linked to this one?
(In reply to Winona Salesky from comment #35) > The order in the for-each does not determine the order of the output. > Subfields are output in the order they appear in the marc record. They are > in alphabetical order in the for-each, purely for convenience sake. > > -Winona > Right you are. I must have been thinking of "subfieldSelect" which does rely on the order of the string of codes. My bad!
(In reply to Ian Bays from comment #36) > It seems that the change in the xslt to put span around subfields c and h > has removed the space that was generated between the subfields. > In koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl there > is an: > <xsl:text> </xsl:text> > at line 125 in the otherwise clause that spaces out the subfields. The two > that were singled out do not have this. Adding them back in within the > <span> achieves the normal, desired spacing. I also have observed this... I suppose I can open a bug for it once I finish a few other tasks...
(In reply to Katrin Fischer from comment #37) > Hi Ian, can you please file this as a separate bug report linked to this one? Ian and Katrin: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16352