Putting Gallery images into the IIIF server

[baskaufs]

At the same time that Gallery images are getting put into Commons, I'd like to simultaneously upload them to the AWS bucket that allows them to be served from our IIIF server. There are still several things that need to be worked out about that:

• [x] I need to review my AWS notes to remember how to use the command line syntax to do the uploading.
• [x] We need to figure out a hierarchical directory system within the bucket so that the URLs make sense on a project-by-project basis and that the files for the gallery can be organized within the gallery directory in a way that makes them locatable.
• [x] At the same time the images are uploaded to the bucket, we need a script that generates a minimal IIIF manifest for viewing the image.
• [x] We need to figure out what publicly accessible AWS bucket is going to hold the manifests and structure them in a parallel manner to the URL pattern used for the images in the IIIF server. When the manifests are generated, they need to be placed in the appropriate folder in that bucket.

[baskaufs]

See email thread including Cliff's 2021-11-02 message, which includes a link to a sample manifest and discussion about mapping a public bucket to a CNAME record for a subdomain or subpath of library.vanderbilt.edu

From: Anderson, Clifford <clifford.anderson@Vanderbilt.Edu>
Date: Tuesday, November 2, 2021 at 9:24 AM
To: Baskauf, Steven James <steve.baskauf@Vanderbilt.Edu>
Cc: Wesolek, Andrew Joseph <andrew.j.wesolek@vanderbilt.edu>, Caton, Mary Anne <mary.a.caton@vanderbilt.edu>
Subject: Re: IIIF manifests
Hi Steve,

Yes, that’s a good idea to create a subdomain for these links. I guess that you’ll need to connect with Dale and team about that possibility. We can still keep the manifests themselves on S3 for easy editing and reference by just pointing the CNAME to it. Thanks also for the reference manifest, very helpful!

Clfif

From: Baskauf, Steven James <steve.baskauf@Vanderbilt.Edu>
Date: Tuesday, November 2, 2021 at 9:21 AM
To: Anderson, Clifford <clifford.anderson@Vanderbilt.Edu>
Cc: Wesolek, Andrew Joseph <andrew.j.wesolek@vanderbilt.edu>, Caton, Mary Anne <mary.a.caton@vanderbilt.edu>
Subject: Re: IIIF manifests
Hi Cliff,

It might be a good idea to map it to someplace in the library subdomain, particularly if we end up putting links to the manifests in Wikidata. That way if we change our minds about where to keep the manifests, we could just change the CNAME record and not break the link.

BTW, you were asking about an example manifest. This isn't exactly what you were asking about, but here is one from the National Gallery of Art:

https://www.nga.gov/api/v1/iiif/presentation/manifest.json?cultObj:id=151064

It's a very simple manifest and would be very easy to just generate the JSON with Python from metadata we already have. You can see how it's linked at https://www.wikidata.org/wiki/Q76552832 under the IIIF manifest property P6108. I have the IIIF viewer gadget installed, so an imbedded Mirador viewer shows the image with Zoom capabilities:
...
Hi Steve,

Glad that you can proceed with uploading these high-resolution images. That’s great! I don’t think we have a good solution for manifests, at least not yet. You’re right that Winona plans to build some kind of utility into the Srophe application, but it would likely be tied directly its purpose and not easily made generic. So, for now, my recommendation is to create a S3 bucket that’s readable (but not writable) from the web for the purpose. I think that’s also what Dan Genkins is doing for the SSDA project.

[baskaufs]

IIIF server upload capability complete: https://github.com/HeardLibrary/linked-data/commit/67525c87c82ac91b093c994845d4cc84213564d6

e.g. https://iiif.library.vanderbilt.edu/iiif/3/gallery%2F1984%2F1984.031.tif/full/1000,/0/default.jpg

[baskaufs]

Created an s3 bucket called iiif-library-manifests in us-east-1.

Setting up the s3 bucket required the following settings:

1. The "Block all public access" setting had to be turned off. 2. The Bucket policy had to be set to the following:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicAccess",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::iiif-library-manifests/*"
        }
    ]
}

3. The Cross-origin resource sharing (CORS) configuration had to be set to:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

At first, I was setting a Content-type header of application/ld+json as suggested by the spec, but application/json and no specified header seemed to also work fine. Since I'm not sure that a media type can be specified when files are uploaded by script, I'll probably just forget about trying to set a Content-type header.

Example: https://iiif-library-manifests.s3.amazonaws.com/gallery/1973/1973.005.tif.json

Used in the Wikidata item. The IIIF manifest viewer plugin may need to be enabled to see it rendered.

[baskaufs]

Upload of manifest added to script in https://github.com/HeardLibrary/linked-data/commit/b8acfc6674b4323ecb3add51a29b2f31a8dba02c

However, the streaming upload seems to override the explicitly stated Content-Type:

So may have to save as temporary file, then upload. The problem is that if people try to look at the manifest, they are prompted to download instead of seeing it in their browser.

[baskaufs]

fixed Content-Type problem in https://github.com/HeardLibrary/linked-data/commit/cbb4a93f5c1f43e98f9ecff82bbb832002ffa15a

[baskaufs]

For reference, the notes on generating tiled pyramidal TIFFs are in Steve's issue tracker https://github.com/baskaufs/projects/issues/95