improve MFHD 856 field display to use $3 $y and $z properly

[gibsonjc]

WHE - In VuFind 3, display of holdings for e-journals is problematic, in my view. Currently the setting for display of the link in the holdings area is taken from the $z of the 856 rather than $3 or $y. This seems to contradict what is recommended in the "Final Report of the Cataloging Electronic Resources/Electronic Resources Display In the OPAC Task Force” document. In our case, as an example, this then makes an incomprehensible link text of “Available to Wheaton College users only”.

[gibsonjc]

Example: https://vufind3.carli.illinois.edu/vf-whe/Record/WHEdb.865814

856 40 $3 Project Muse $u http://sfx.carli.illinois.edu/sfxwhe/sfx_local?genre=journal&sid=Voyager:WHE&sfx.ignore_date_threshold=1&svc.fulltext=yes&issn=1527-1897&rft.object_portfolio_id=110978628679529 $z Available to Wheaton College users only

[gibsonjc]

WRH -

1. VuFind 3 is incorrectly using MARC field 856, subfield z as the display text for records containing a URL in the 856 field. Subfield z is for any public notes (such as access restrictions or subscription information). The correct subfield to use for masking the URL in the OPAC display is subfield y (“ǂy Link text. The link text that is used for display in place of the URI in subfield ǂu”-- from OCLC Bibformats documentation).

2. VuFind 3 isn’t displaying 856 subfield y at all, which has negative implications for users, since it is used to contain directional information (such as “Click here to access this resource”).

3. VuFind 3 isn’t displaying 856 subfield 3 properly, which is … complex. Sometimes it should display, sometimes it shouldn’t, depending on its positioning within the 856 field. Right now I don’t think it is displaying at all. See https://www.oclc.org/bibformats/en/controlsubfields.html#subfield3 ["Subfield ǂ3 contains an indication of the part of the described material to which the field applies. Subfield ǂ3 appears at the beginning of the field in cases where it is intended for display, otherwise it appears with other control subfields grouped at the end of the field."]

In the past at Harper College, subfield 3 has been used incorrectly (I’m actively working on fixing this in our local catalog), but this did not have much of an impact because the Classic catalog and the previous version of VuFind used subfield 3 as a URL mask (incorrectly, but maybe it was a CARLI-wide decision?). Regardless, if VuFind 3 goes live as is, every single one of our (incorrectly encoded) proxy URLs will be displayed to all. Not ideal.

Example: https://vufind3.carli.illinois.edu/vf-wrh/Record/WRHdb.319902 vs. https://vufind.carli.illinois.edu/vf-wrh/Record/wrh_319902

[gibsonjc]

TRN - Our 856 $y display text is not displayed in electronic resource records (e.g. https://vufind3.carli.illinois.edu/vf-trn/Record/TRNdb.103509). While this is technically functional, I would expect some confusion—especially from students—about the links because the proxy prefix formulation is unfamiliar to them.

[gibsonjc]

Specification for the display of 856 subfield y, z, and 3 data in the Holdings tab of the VuFind 3 record page: (same as that used in VuFind 0.6)

The linking text should be taken from the $y. In the absence of the $y, use the $3. In the absence of the $y or $3, use the $u.

The target of the hyperlink is always the URL in the 856 $u.

After the linking text, insert a space and display the text of the 856 $z (which is free text note field).

Examples:

https://vufind3.carli.illinois.edu/vf-trn/Record/TRNdb.103509 856 40 ‡u http://libproxy.trnty.edu/login/?url=http://sk.sagepub.com/reference/careerdevelopment ‡y Available to Trinity students, faculty, and staff.

https://vufind3.carli.illinois.edu/vf-whe/Record/WHEdb.865814 856 40‡3 Project Muse ‡u http://sfx.carli.illinois.edu/sfxwhe/sfx_local?genre=journal&sid=Voyager:WHE&sfx.ignore_date_threshold=1&svc.fulltext=yes&issn=1527-1897&rft.object_portfolio_id=110978628679529 ‡z Available to Wheaton College users only

https://vufind3.carli.illinois.edu/vf-niu/Record/NIUdb.1567202 856 40 |u https://www.ulib.niu.edu:9443/login?url=http://site.ebrary.com/lib/niluniv/Doc?id=10052605 |z Electronic book; Access restricted to NIU Libraries

[gibsonjc]

RSH - Field 856 $3 is not enabled so that only a link shows up in holdings of full record description. Does show up in brief as link “Internet Archives” – can it appears as it does in VuFind 0.6? Title examples: Yearbook collection, St. Luke's Hospital School of Nursing (Chicago, Ill.) St. Luke's news The pulse (publication 1894) Note that in this record the $z takes precedent over $3 which specify yearbook date. Makes no sense to have two links that indicate “Access available at Internet Archives”

[ameyer24]

NPU - Was about to submit this same issue - glad it is on your radar!

[gibsonjc]

ISU - major concern that Milner Library has before making a switch to VuFind3. Electronic Resources online access link displaying standard text (Available on ISU campus or via ISU ULID) rather than database name (Project Muse). Example: https://vufind.carli.illinois.edu/vf-isu/Record/isu_1873686

[cedelis]

In devel and test.

[tschwitz]

Some testing in WRH and ISU on vufind3-test...

On holdings display within records, all text from $3, $y, and $z are contained in the hyperlink. When subfield y is present, the search results screen includes a link to the URL, using the subfield y text. When subfield y is present, the holdings display includes a holding block for "Internet" that only includes a link using the subfield y text.

In one case so far, an 856 with subfields $3 and $z leads to the display of the link on the results screen, and the Internet holding block, both using the subfield z text. I'm not seeing anything obvious that would suggest the $z should behave like the $y (unless maybe this is the same text WRH uses for SFX links).

Examples below; I'm leaving out the actual URLs for brevity.

Example 1: CARLI EBL Book. (https://vufind3-test.carli.illinois.edu/vf-wrh/Record/EBL.1442118) 856 40 $u URL $y Connect to eBook $z (Available to people from CARLI member institutions)

Example 2: ISU Kanopy streaming media. (https://vufind3-test.carli.illinois.edu/vf-isu/Record/ISUdb.1791887) 856 40 $Kanopy $u URL $z Available on ISU campus or via ISU ULID

Example 3: WRH Alexander Street streaming media (https://vufind3-test.carli.illinois.edu/vf-wrh/Record/WRHdb.364314) 856 40 $3 Alexander Street Press, Dental Education in Video $u URL $z Access restricted to subscribers.

Example 4: WRH Films on Demand streaming media (https://vufind3-test.carli.illinois.edu/vf-wrh/Record/WRHdb.391146) 856 40 $u URL $y Click to view video $z Part of the Films on Demand collection.

Example 5: ISU Project Muse e-journal (https://vufind3-test.carli.illinois.edu/vf-isu/Record/ISUdb.1873686)

ISU - major concern that Milner Library has before making a switch to VuFind3. Electronic Resources online access link displaying standard text (Available on ISU campus or via ISU ULID) rather than database name (Project Muse). Example: https://vufind.carli.illinois.edu/vf-isu/Record/isu_1873686

856 40 $3 Project MUSE $u URL $z Available on ISU campus or via ISU ULID

[tschwitz]

Separating this example out, because there are several urls in one MFHD. It's less than optimal cataloging, but also could result in unintended consequences.

ISU bib 1812646, Overdrive streaming media title 856 40 $3 Overdrive $u URL $z Available to University High School students and faculty 856 4 $3 Excerpt $u URL for mp3 excerpt 856 4 $3 Excerpt $u URL for epub excerpt 856 4_ $3 Image $u URL for cover image

What we get in the result is a merge of the $3 and $u from the last listed 856, but the $z from the first listed 856. It looks a little bit like the record is being parsed from the end to the beginning.

[gibsonjc]

@tschwitz The "Internet" labeled section in the Holdings tab (above the MFHDs) is driven by the Bib 856, not the MFHD 856. (That's why ISU doesn't have them in your examples since they still do that 596 thing with URLs in their Bibs.) I think that so far Chris has only done work on the MFHD 856 display. I'm not sure yet if we'll need a new Issue for the Bib displays and/or if some of this may be part of Issue #152 where I already noted a side effect from turning on the display of "Open URLs" there to get the SFX links is that we also get Bib 856 links under "Internet".

When subfield y is present, the search results screen includes a link to the URL, using the subfield y text. When subfield y is present, the holdings display includes a holding block for "Internet" that only includes a link using the subfield y text. In one case so far, an 856 with subfields $3 and $z leads to the display of the link on the results screen, and the Internet holding block, both using the subfield z text. I'm not seeing anything obvious that would suggest the $z should behave like the $y (unless maybe this is the same text WRH uses for SFX links).

[gibsonjc]

@cedelis Here is a summary of MFHD 856 displays after commit 38e9540:

What's working right:

• $u by itself displays as the hyperlink.
• $y by itself displays as the hyperlink.
• $3 by itself displays as the hyperlink.

What needs more work:

• $z is always incorrectly displaying as part of the link; it should always be plain text:

  • $u and $z present are displaying as a single long hyperlink. Only $u should be the hyperlink.
  • $y and $z present are displaying as a single long hyperlink. Only $y should be the hyperlink.
  • $3 and $z present are displaying as a single long hyperlink. Only $3 should be the hyperlink.
  • When $3 $y $z are all present, $y is being displayed instead of the $3, which is correct, but the $y and the $z are displaying as a single long hyperlink. Only the $y should be the hyperlink.

• When $3 and $y are present but without $z, the $3 is incorrectly displaying as the hyperlink. The $y should display as the hyperlink instead of $3.

• Ted discovered above that the presentation of multiple 856s in a single MFHD is not working well. It's only displaying one link, and the subfields used are not all from the same 856 field. It needs to display each 856 field separately with respective subfields. Should this be a new Issue?

I created an example record with eight MFHDs, each containing one of the possible MFHD 856 $u $3 $y $z combinations at: https://vufind3-devel.carli.illinois.edu/vf-whe/Record/WHEdb.316400

(Side note: In this example, I do NOT understand why it is grouping seven of these together and showing one alone making them look like two MFHDs (one with seven one with one). I also do NOT understand why if I add an ninth MFHD, the display of these changes yet again (eight are together and one is alone, but it is a different one!). This needs a new Issue but I'm having trouble wrapping my head around it right now.)

[cedelis]

@gibsonjc

OK, I believe I have fixed the grouping issue (of why the 8 MFHDs weren't showing up together, instead of being split into 7 and 1).

Also, I think I have fixed the free text issue (856$z field). I simply misinterpreted the spec on that one.

[gibsonjc]

@cedelis Almost on the MFHD 856 displays! First and third filled-in bullets are fixed now but the middle one remains:

• When $3 and $y are present but without $z, the $3 is incorrectly displaying as the hyperlink. The $y should display as the hyperlink, not the $3. Right now the $3 is displaying.

As for the grouping problem, I've created Issue #246 so please see questions there!

[cedelis]

@gibsonjc

For example: https://vufind3-devel.carli.illinois.edu/vf-whe/Record/WHEdb.316400

Can you verify that the MFHD ID of 972261 is encoded properly?

The reason I ask is because the PHP library File_MARC may have a bug in it (or perhaps I'm using it incorrectly).

Because, for MFHD 972261, it appears that subfield 'u' actually contains within it the following text (as part of the 'u' subfield value):

$y Subfield y (has 3 u y)

I've put in a debug statement that prints out each 856 subfield along with its value:

subfield::::>3<:::: value::::>Subfield 3 (has 3 u y)<:::: subfield::::>u<:::: value::::>Subfield u $y Subfield y (has 3 u y)<::::

Here's the debug code I'm using:

    if ($fields = $record->getFields('856')) {
        $sfValues = array();
        foreach ($fields as $field) {
            if ($subfields = $field->getSubfields()) {
                foreach ($subfields as $code => $subfield) {
                    if (!strstr('y3uz', $code)) {
                        continue;
                    }
                    $sfValues[$code] = $subfield->getData();

$debug .= 'subfield::::>' . $code . '<:::: value::::>' . $sfValues[$code] . "<::::\n"; } } // ...snip... }

Also, here's an object dump of the MFHD record that gets passed into this function (the RECORD_SEGMENT is the field I use as input into the File_MARC object):

array ( 'ITEM_BARCODE' => NULL, 'ITEM_ID' => NULL, 'RECORD_SEGMENT' => '00251cx a22000974 450000100070000000400070000700500170001400800330003185200240006485600650008897226131640020170731140343.01707314u 8 1001uu 09011288 bbejrnlhINTERNETt1403Subfield 3 (has 3 u y)uSubfield u $y Subfield y (has 3 u y)', 'ITEM_ENUM' => NULL, 'ON_RESERVE' => 'N', 'ITEM_SEQUENCE_NUMBER' => '0', 'STATUS' => 'No information available', 'LOCATION' => 'E-Journals', 'CALLNUMBER' => 'INTERNET', 'BIB_ID' => '316400', 'MFHD_ID' => '972261', 'DUEDATE' => NULL, 'TEMP_LOCATION' => '0', 'PERM_LOCATION' => '0', 'SORT_SEQ' => NULL, ),

[gibsonjc]

@cedelis You're absolutely right, this was a stupid typo on my part. My apologies for wasting your time. This is ready for prod!

[nmswanson]

I believe 5 of 8 scenarios for single 856 40 displays are broken or not displaying as expected; please view the attached chart 856 Bib_MFHD display.xlsx for details and examples. This may affect both bib and MFHD 856 displays, or just bib 856s depending.

Also, please note, the logic noted above for 856 u3yz and u3y was written differently than what we did in VF 0.6. Here's what we did In VF 0.6: -When u3yz, 3 and y display hyperlinked and z as text. -When u3y, display 3 and y hyperlinked, separated by a space.