NCSU Libraries
IIIF Implementation
Jason Ronallo
Head of Digital Library Initiatives
NCSU Libraries
- I'm Jason Ronallo the Head of Digital Library Initiatives
- These are the folks who make up DLI
SCAMS
Special Collections Asset Management System
Manages descriptive metadata.
- stores metadata in MySQL
- indexes data into Solr
- developed this app for maybe 6 years now
SAL
- Blacklight application.
- Public interface.
- Uses SCAMS MySQL database
- Uses SCAMS Solr index for search
Image Server: Djatoka
- Using Djatoka for several years
- Developed Djatoka Ruby gem. Stanford added a IIIF shim
- Problems
- instability
- poor quality
- odd URLs
- difficult to explain
- less reuse than hoped
- We weren't using the Stanford shim.
- This was the one piece of our infrastructure where I had to worry about going down.
Why another image server?
Caching
- Caches to the file system in a transparent way.
Profiles
Common URLs across various applications we manage:
- /full/300,/0/default.jpg
- /full/!200,200/0/default.jpg
- /square/300,/0/default.jpg
Only clear from the cache images that do not match these patterns.
UV: /full/90,/0/default.jpg
Keep this because it is small and used to help UV load faster:
iiif/nubian-message-1996-02-22_0001
├── full
│ └── 90,
│ └── 0
│ └── default.jpg
└── info.json
Static site generator
Just in time static site generator for
Simple cache expiration.
Improved cache maintainability.
Problems
- Headless VIP
- Horses Behind
- Various applications using the images
YKK add example images
would rather they know as little as possible about anything.
full image
square
!square
square!
square
YKK solution to the headless VIP
Makes caching easier
Top left (!square) would otherwise be:
/iiif/segIns_001/0,0,6099,6099/350,/0/default.jpg
square!
/iiif/segIns_001/0,2500,6099,6099/350,/0/default.jpg
Better Images!
OCR and Search Inside with Ocracoke
Rails application to create, index, and search text from page images.
Images are supplied for OCR via a IIIF image server.