Hydra and IIF

Owned by Bill Branan
Jun 16, 2017
5 min read

Image Interface Interoperability Format

Introductions

  • Andrew Woods - DuraSpace
  • Richard Green, Hull
  • Mark Bussey - DCE
  • Longshou Situ - UCSD
  • Brian Maddy - DCE
  • Tom Kramer - Stanford
  • Michael
  • Stuart Snydman - Stanford
  • Jon Stroop - Princeton
  • William Ying - Artstor
  • Russell Schelby - OSU

Notes

  • MB - Lots of different activities around images, IIIF is giving a strong way to talk between machines, being intentional could converge into best practices, reference implementations, quick results out of the box.
  • TK - Hydra IIIF compliant natively? Image server wrestling; dJakota was good earlier, perhaps something could be better
  • MB - set of tiers of image servers - lighter needs: gem, heavy use - here’s some ideas
  • JS - concern about tightly integrated solutions, performance has been needed dedicated hardware, separate equipment (not out of fedora)
  • JS - How to get images into an IIIF image server (and stay in sync) (has ideas)
  • TK - Another facet: descriptive data, could be a standard gem to express metadata as IIIF
  • Images ++ Metadata is ok in scope, need descriptive & technical metadata
  • WY - have proprietary image repo. SharedShelf: has public domain component, 100,000 images: want to share outside—migrating to IIIF compliance. display image with all available metadata. ShareShell is a turnkey project, but could be sit underneath hydra (instead of Fedora) If become Hydra body, would definitely be IIIF compliant.
  • TK - lots of folks need a complex metadata data entry
  • MB - DIL possible convergence
  • MB - who is consumer of Mirador (scholars workspace, image comparison) (like Luna, without discovery) is JS, multiple repos - compound image viewer (art history)(exhibits)
  • TK - what are other needs?
  • MB - Hydramata - multipage content, new work on DIL to bring up current state: could use conventions, number of folks want gallery view (backlight does not have, should move to Blacklight 5 group) Image wall (native open sea dragon - cool iris, tile sequence, proprietary, tile source collections0) BM had demonstrated
  • MB - might tie into GIS work (came up in their session)
  • TK - was a thread from John Hopkins about deep zooms and page turners that were mobile friendly (open sea dragon +?) which JS libraries are being used?
  • MB - if we are capturing cataloging images, how can we make them IIIF compliant? Would reduce the amount of knowledge
  • BM - looking into spec, made small change to server response: hacky but good. Conflicting ID’s would need namespaced
  • JS - Three things: IIIF editor, writer of lorus: whatever you put in, includes path: has to resolve (abstracted out). Princeton has namespace needs (geo images one place, collection images another) Spec doesn’t require path, just URI. We need to resolve question of solution to get content into IIIF server. Hydra recommendation or IIIF recommendation. Level II server: Put call should be standard.
  • MB - We could write a Hydra convention, parallel call for and insert image. Create Hydra module that could be shown as proof of concept.
  • JS - don’t need restful service when it is in hydra, just when it is distributed
  • TK - regardless of conditions - we should have defined way? JS - Yes, but as optional feature MB - similar to
  • JS - externally managed data streams - almost all the way to managed URI
  • WY - but now we might have versioning, would just be latest
  • TK - Hydra context: users have converged: would be attractive, but not universal. Is this IIIF us or Hydra us?
  • MB - propose Hydra-us first as first step
  • JS - craft a proposed specificatoin for Copenhagan
  • TK - Is there a standard interface for uploading information (youtube, amazon, flickr etc) MB: variety of use cases for uploading (e.g. via browser)
  • TK - End User generated content (e.g. flickr) vs. server ingest (encapsulated by hydra, not public)
  • RG - if encapsulate image server and upload, need to post image and/or metadata MB: right now it is custom hydra code, each on their own
  • TK - what is the information that needs to be contained JS: should be a put (to not mint an ID) with just image as payload. JS: spec exists as HTTP
  • JS - IIIF url in config file, all done
  • MB - include versioned file in preservation instance (not IIIF server)
  • JS - IIIF has no way to pull master file
  • TK - constrain spec scope to presentation layer
  • JS - it is all encoding, each version is a separate file (not guaranteed). No notion of master
  • RG - Hydra POV, is not necessary
  • JS - Is there two copies? MB: Yes~ IIIF server is only about derivatives, not concerned with master, repository has canonical
  • TK - how to get metadata to IIIF server? JS - IIIF server generates them on the fly (no concept of descriptive metadata)
  • TK - do we want/need to include descriptive metadata into transfer spec? (for common usage) MB: descriptive metadata should be out of scope. TK - difference in reference models
  • MB - recommend a proposed standard - is still good work if it is a Hydra standard if not adopted by
  • TK - where does RIFF fit in? MB: is another piece of stack, one line install, is easy if not best in class. Is mostly IIIF compliant (in output, can’t take Jpeg2 as source, uses image magik)
  • TK - what is roadmap for lorus - simpler J2K? JS - people are using it, still write in python, have to parse j2 stream, easy to do in Python, no framework. Roadmap is to come as close to IIIF spec as possible, maybe a bit ahead. Getting easier to deploy every day. Easy to plug in a resolver that always works with hydra. Currently uses file server path.
  • MB - Fedora 4 projection similarities?
  • JS - Metadata API, F4 railsX is not going to be a thing. Could there be a way to build common metadata as IIIF-compliant metadata (persistent hierarchy) (railsX vs Stuctural Metadata) MB: propose parking lot. UCSD has possibly solved (has not fedora, interesting image collections, e.g. brain slices) might be able to come up with a metadata convention to handle all cases? JS - standardization would reduce need for model changes TK - it is all just a graph in fedora. Store in json or emit in json. AW: trivial to emit in F4. JS - does that need to have each layer to be an object in Fedora?
  • MB - tool to create a json string (though might have mapped objects already)
  • JS - no more mets files All: wha? JS: metadata structure for file objects - relationship between files (or implicit in files) does it need modeling? maybe. Fedora 4 will likely unlock different methods
  • AW - as long as you get to the json at the end…
  • MB - Model-agnostic json, but some will want manual, some will want a tool, some will want to use their model.
  • TK - IIIF compliant is not model agnostic
  • JS - Drag-and-Drop structural metadata to create manifest, stays with object, saved as… json, xml, ???, doesn’t want to overload technical metadata
  • Tool that lets you organize items to output a IIIF Manifest from existing model.
  • TK - Where does the code sit? JS - tool directly creating json, AW work can be repurposed?
  • MB - want to reiterate that it is not mandatory method for generating method

Action Items

  • Be more explicit about consistent interface layer between Hydra and the Persistence/Preservation layer (fedora, shared shelf, DIM, PearTree)
  • JS will create a draft spec for Copenhagen meeting - MB will review
  • Confirm Gallery View in Blacklight 5 request - MB & TC 
  • Someone should do a workshop on Open Sea Dragon