IIIF Manifest URIs in MARC21

leanderseige commented 3 years ago

Recipe Name

Use case

Store links to IIIF manifests in MARC21.

Suggestion:

Field: 856 Subfield u: URI of the IIIF Manifest Subfield q: Content-Type of HTTP Response Subfield y: IIIF-Manifest

Example:

856 |u https://iiif.ub.uni-leipzig.de/0000011942/manifest.json |q application/ld+json;profile="http://iiif.io/api/presentation/3/context.json" |y IIIF-Manifest

glenrobson commented 3 years ago

The cookbook group think this is a good recipe to have. We should encourage other recipes for other metadata formats.

On the proposal to use the 856 $u we do worry that this might conflict with a more human usable link to the viewer.

leanderseige commented 3 years ago

On the proposal to use the 856 $u we do worry that this might conflict with a more human usable link to the viewer.

I understand that. That's why I suggested to use Subfield $q to indicate what (mime)-type of data it is. (http://www.loc.gov/marc/bibliographic/bd856.html)

Nevertheless I would like to extend my first proposal:

1st indicator shoud be 4 -- or 7 with Subfield $2 set to "HTTPS"

2nd indicator should be 1

sfolsom commented 3 years ago

Because the goal of the 856 is meant to provide a link (and related information) to make sure the right type of client is used to render the content accessible to a human, I think it might be better to go with something like:

1st indicator 7 with $2 iiif

(So that the end user in a catalog isn't met with a bunch of json-ld in a browser, but instead the catalog knows a IIIF client is needed to view the content).

"iiif" would have to be a proposed addition to https://www.loc.gov/standards/valuelist/electronaccess.html

ahankinson commented 3 years ago

I think the $q would be able to provide information about display for humans / non-humans. A value of text/html could point to a IIIF viewer, while a value of application/ld+json;profile="http://iiif.io/api/presentation/3/context.json" would indicate the JSON-LD response (or indeed just application/ld+json).

It would be difficult to choose between $2iiif and $2http(s), if the first indicator was 7... I think that's intended more for the actual protocol.

We have a use-case of needing the JSON-LD response, and not a human-readable version. (Use of our own IIIF viewer with the library's supplied manifest).

sfolsom commented 3 years ago

Understood. I leaned toward $2 because it relies on a formally controlled list that signals a class of applications to access/render the content. The URI for the JSON-LD Manifest could still be used in the $u in this case.

$q is a traditionally lesser used subfield, and the definition say that it 'may' pull from a controlled list. That said, if there's is a consistent value adopted for $q, like the original example that signals a IIIF viewer is needed, we should be able to choose a viewer within or outside of our library catalog.

zimeon commented 3 years ago

timathom commented 2 years ago

On the proposal to use the 856 $u we do worry that this might conflict with a more human usable link to the viewer.

I understand that. That's why I suggested to use Subfield $q to indicate what (mime)-type of data it is. (http://www.loc.gov/marc/bibliographic/bd856.html)

Nevertheless I would like to extend my first proposal:

1st indicator shoud be 4 -- or 7 with Subfield $2 set to "HTTPS"

2nd indicator should be 1

Should the 2nd indicator be 1 ("Version of resource")? That coding would indicate that the JSON-LD document was itself a version of the digitized object. A value of 2 ("Related resource") seems more accurate.

Is a hyperlink to the manifest meant to be displayed in the browser? Subfield $y is link text, so that suggests it will be displayed (in which case a non-hyphenated form might be more readable). If the intent is instead to provide a coded indication of the content, then $3 would probably be more appropriate.

mikeapp commented 2 years ago

I see there's a subfield $7 ("Access status"). It would be helpful to signal to aggregators that either the manifest or its images are likely to be restricted from public access.

mikeapp commented 1 month ago

Here is where Yale ended up.

856 for IIIF manifest (Suppressed from public view) 
Indicator 1 = 4  
Indicator 2 = 1  
Subfield q = application/ld+json;profile="http://iiif.io/api/presentation/3/context.json"  
Subfield u = {IIIF MANIFEST LINK}  
Subfield 7 =   
0 if DCS Access = Public;   
1 if DCS Access = Yale Community Only   
Subfield x = (if helpful for the synch process, could use this field to add technical metadata, such as the last synch datetime)

IIIF / cookbook-recipes