Discuss Identifying Manual 856 links in Voyager Records

[martinlovell]

There are links that go to DCS in voyager records that were manually added.

When we are adding links to Holding marc records with the DCS->Voyager linking via MC, we need to identify existing links to DCS so that we know whether they need to be replaced. We don't want to replace 856 links which don't go to DCS or point to other oids.

The links are typically: http://hdl.handle.net/10079/digcoll/#### https://brbl-dl.library.yale.edu ....

From @mikeapp: To dereference the handle we can request it and get the HTTP 302 Location header for the URL.

[martinlovell]

I'm working on a URL Redirect follower: https://github.com/yalelibrary/metadata-cloud/blob/voyager_link_integration/src/main/java/edu/yale/library/metadata/utils/UrlRedirectResolver.java It works for the links I've tried.

[sshetenhelm]

@martinlovell

To confirm, these are being taken out of the bib record and put into the holding record, correct?

To confirm, we want to identify all possible bib link prefixes and/or subfields from 856 to replace current handmade DCS links with automatic links.

Will this be an automatic process via Metadata Cloud? Or will Tech Services need to do something their end to delete links from the 856 bib once they’ve been identified?

[sshetenhelm]

1. Ones already in holding to be replaced that were put in manually
2. What we can identify automatically, can be removed automatically, and if there are things we can't identify, Tech services would need to remove.

[martinlovell]

We discussed this briefly in MetaDigits.

Since MC will not edit the Bib's marc and many manual links are in the Bib (especially for brbl), there may be duplicates links in QS when we add the 856 links to the holding. The URLs would be different, since the manual links are often handles or links to the old brbl dl, but they would redirect to the same DCS page. (The URLS being different will make it hard for QS to remove the duplicates.)

The group suggested that we provide reports to access services of bib_id/holding_id pairs for holdings to which 856 links have been added. They can use that report to remove the duplicate links from the bib's marc.

It would be possible for metadata cloud to examine the Bib's Marc and try to identify which 856 links should be removed as part of the report, but that may not be necessary.

[sshetenhelm]

We got this report from Eva and Youn of 856 links:

digital_collections_856_bib.xlsx

I don't think it has old handle links though so I may need to go back and ask for that.

[martinlovell]

I remembered one way we could help with this that Robert Klingenberger mentioned. We can provide someone with a list of Holding IDs of records our system links to DCS. (Maybe a daily list). Then someone could look up the bibs for those records and remove the manual links in the bibs so we wouldn't have a duplicate in the bib and holding. We already provide the ability to download the holding marc records we updated based on a timespan in metadata cloud, which could be used for this purpose. If a list of holding ids is better, we could add that functionality.

* from cataloging or tech services maybe?

[sshetenhelm]

In discussion re: this with Eva.

[sshetenhelm]

Alison emailed Eva on Tuesday with reporting from Martin; waiting for response from Eva.

[sshetenhelm]

Emailed Eva again today to see if she has an update for us.

[sshetenhelm]

Received some files to review from Tech Services.

[sshetenhelm]

We are working on a new list of removals in order to retain links to non-reassociated objects and call number searchers.

[sshetenhelm]

Sent new list to Youn. Once (a) changed records in TEST are restored to previous version and (b) removal happens again with new list, we will test and review automatic link creation again in Test.

[sshetenhelm]

Youn will restore the previously edited records and load the newly edited records by January 5. I will touch base in the New Year.

[DraxIndustries79]

Test after #2690 moves along

[sshetenhelm]

The tests from 2690 look good. @alisonclemens , when you are back in office, could you please double-check some random records just for quality control?

[sshetenhelm]

Feature appears to work as expected! Collaborating with colleagues across YUL for release date.