LITERARY MACHINES

digital libraries, archives, metadata, web preservation

Revamping IIIF.link

tags: digital libraries iiif tify content state

A few years ago, I had developed a small application that allowed you to "frame" a specific part of an IIIF image and share it on the web through simple, concise URLs. But the initial version was rudimentary and only supported IIIF 2, I've since revamped it using the latest release of the TIFY viewer.

TIFY is a lightweight IIIF viewer written with VueJS. Its standout feature is the automatic reflection of document navigation states (zoom, pan, page) in the URL itself. This unique capability enables users to bookmark and share URLs effortlessly. TIFY operates entirely client-side, eliminating the need for additional services.

However, I like short, simple (and possibly persistent) URLS, ideal for sharing in various documents and messages. Enter iiif.link, which facilitates remote saving of current states to generate short URLs with unique identifier, following this format:

https://iiif.link/id/{nanoid}

Examples:

This application operates without requiring user login, ensuring complete anonymity, and once a link is generated, it cannot be modified. The user interface remains minimalistic and will continue to do so. The server, a lightweight Go application, stores data in a SQLite database. Its source code is publicly available here https://github.com/atomotic/iiif.link

What's missing since the previous version which I'm still working on:

  • Opengraph metadata

    This feature provided a preview when sharing links on social networks and messaging platforms. Old example:

  • HTTP headers

    Some HTTP headers exposed the IIIF resources, such as the canvas, the image, the label, the manifest. While I'm unsure of its utility, it might serve as a simpler alternative for machine consumption compared to APIs.

    curl -I https://iiif.link/id/{id}
...
X-Iiif-Canvas: https://___
X-Iiif-Image: https://____/35,168,1703,788/,100/0/default.jpg
X-Iiif-Label: Document title
X-Iiif-Manifest: https://___/123/manifest.json
X-Iiif-Page: 11

But isn't there an IIIF standard for this?

Indeed, the Content State API 1.0 exists, although it's yet to be integrated into major viewers. However, I'm considering implementing an export feature in this format for greater interoperability.