It should be possible to put dereferencable URIs in $0 of authorized fields

[Jane Sandberg]

We are currently putting dereferencable URIs in $9 of our 1xx, 6xx, 7xx, 8xx fields. Eventually, however, we'd ideally like this to live in $0, which is currently being used for the local id of the relevant authority record.

If we were to run the authority linking scripts with our URIs in $0, they would be totally clobbered by the $0s that link to our local authorities.

If you'd like some background on Linked Open Data and why we want these in $0, this video gives a pretty good overview: https://www.youtube.com/watch?v=uju4wT9uBIA

Having URLs in our records will help with the third requirement mentioned in the video, referring to things using their Uniform Resource Identifiers. Here's an example of what kind of information our catalogs might eventually make available to other computers; notice all the URLs that allow computers to make those connections easily:
http://bibframe.org/resources/sample-bl/bibframe.n3

A few libraries (mostly in the academic realm, such as George Washington University and Stanford) have started adding these to their
$0 records; I see it as a good way of heading off future work.

[Dan Scott (denials)]

So, as you've noted, it is possible to put dereferencable URIs in the $0 subfield of fields in bibliographic records.

As you have also noted, if you run authority linking scripts, then the $0 will point instead to the local authority records.

So right now you have to choose either to use local authority control for your bibs, or to link directly to external authority records from your bibs.

The design thinking many years ago (and we were thinking of linked open data way back then) was that the local authority records were where any dereferencable URIs should live, and that at bibliographic record display time the link to the authority record could be displayed, which would in turn serve up the links to the dereferencable URIs.

So, no quibbles from me in what our end goal is, but hopefully the original design thoughts are helpful for alternate implementations of getting to that end goal. We could follow through with the original bib record -> auth record -> external URI layer of indirection, or we could make the authority linking scripts more aware of multiple $0 subfields and URIs. Lots of possibilities.

For what it's worth, we do support URIs that link to related or the same works in subfield $2 for fields like 024 and link out automatically via http://schema.org/exampleOfWork (for Worldcat Work URIs) or http://schema.org/sameAs links for other 024 URIs, for 020 fields, and for OCLC numbers in 035 (see what https://laurentian.concat.ca/eg/opac/record/739015 serves up for example). This logic is implemented around line 150 of Open-ILS/src/templates/opac/parts/misc_util.tt2

[Galen Charlton (gmc)]

On Sun, May 8, 2016 at 2:23 PM, Dan Scott <email address hidden> wrote:
> So, no quibbles from me in what our end goal is, but hopefully the
> original design thoughts are helpful for alternate implementations of
> getting to that end goal. We could follow through with the original bib
> record -> auth record -> external URI layer of indirection, or we could
> make the authority linking scripts more aware of multiple $0 subfields
> and URIs. Lots of possibilities.

There's a PCC task group [1] (that I've participated on) that's
working on a proposal to formally endorse putting URIs in $0
authority-controlled fields (as well as linking fields) in bib
records. I think that a discussion paper about will be released in
June.

Evergreen's handling of $0 seems flexible enough to accommodate both
direct and indirect assertions that a URI for a concept is associated
with a bib record... provided that the bib-auth linking script is
changed so that it distinguishes between $0 that Evergreen "owns" for
internal linkages and $0 that contain external identifiers, which can
include URIs.

[1] https://www.loc.gov/aba/pcc/documents/URIs-MARC-taskgroup.docx

[Mike Rylander (mrylander)]

Since URIs require a scheme, and the scheme does not allow parens[1], and because we use parens at the front of the content for our linking purposes, the shortest path seems to be to allow both to exist and ignore the ones we don't understand. To wit, I propose the following branch as a starting point:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp_1575908-do_not_kill_sf_0_uris

[1] https://tools.ietf.org/html/rfc3986#section-3.1

[Galen Charlton (gmc)]

Noting, by the way, that the PCC task group had considered requiring $0(uri)http://example.org..., but fortunately decided *not* to require "(uri)".

[Mike Rylander (mrylander)]

I /think/ we'd still have been OK since the scheme has to start with a alpha character, but it's certainly simpler to have our own prefix. /me reads the PCC doc...

[Jane Sandberg (sandbergja)]

FWIW, the U.S. National Library of Medicine now has actionable URIs in 650$0, 651$0, and 655$0 throughout its catalog: https://www.nlm.nih.gov/pubs/techbull/ma17/ma17_adding_uris_mesh_2_nlm_catalog.html