Natahn Talman, UCin: no pt / using IA on some instances; want to get it into
Rob, Stanford: 3 different pt’s; Mirador2, IIIF
Steven Ng, Temple: don’t have pt; experimenting with seadragon and loris
Jeremy M, MPub: looking for a post-DLXS publishing platform; fully encoding text
Princeton: handful of pt’s; kill them all slowly; IA
Jess Keck, Stanford: embark how to embed digital objects around sites; pull in a pt environment into an application (embed vs. destination)
Chris Powell: pt’s
Tom Cramer, Stanford: would really like Hydra to be native IIIF compatible and can swap pt’s
Justin Coyne, DCE: pt for Case / TEI + 1/2image; AngularJS; wrote RIIIF
Randal Foy, IU: home-grown pt’s; out of METS, walking TEI; what happens in Hydra
John Dun, IU: specialized pt part of variations musical library (score + music specific annotation tools); integration with annotation (replace variations with avalon)
Betsy Colman: built pt’s
Scott Smith, USCB: how might pt be incorporated in Hydra
USCB? : looking into pt
Neal Stewart, : used IAs
Peter Binkly, : legacy project with pt
Richard Green, Hull: 5 UK universities, share a common need for a pt; Hull has taken IA and done a proof of concept against Hydra but it’s dirty. Not really looking for a heavyweight pt, just want to work with JPEGs
Brian Madey, DCE:
Dan Brubraker-Horst, ND: IA pt
Evan English, BPL: rolled out a pt in hydra, blacklight component based on WDL viewer
Robin Ruggaber, UVA: move to IIIF compliant pt
What about the back-end? Special structures that you’ve needed to build into Fedora / back-end to support the pt? Want to build a hydra environment that doesn’t care about the presentation
Justin Coyne: TEIp5 for Case - text + images simultaneously; is that that the common use case?
IU has this, using XTF
DLXS does this
HathiTrust via METS
Richard Green: Durham have OCRed text with images; Hull envisions something more robust than its current proof-of-concept--- json data stream with item data (image sizes, etc): easy with IA if the data all maps up
Evan: each image is its own object in fedora; rel-ext has two relationships (has-preceeding-page and is-preceeding-page-of) -- generate an array of PIDS in sequenced objects and fed to viewer javascript
IIIF has two APIS --- for getting at pixels, and one JSON based about order of images to populate a gallery, pt, etc.
Document driving presentation vs. each page knowing its context and then being able to tell where to go prev/next
images are related to parent via rel-ext
pre-serialize the rel-ext and embedded in HTML as js
TEI parsed in Ruby -> compound model -> easy to map between filename and datastream node; made it into JSON this page has this image and this text
Are there people ooking for a lightweight reader that only works with JPEGs, vs. being driven from a separate server (IIIF)
RIIIF is a middle-ground because you can just mount this gem - fetches the image out of fedora, resizes, keeps the cached copy around
IIIF presentation API is trying to solve is the middle format that drives the browser, define that abstraction layer for plug-n-play
IIIF2 going to have impact? (No, not at this level of discussion.)
Why are we building so many pt’s?
lots of people are using IA
HathiTrust needing something more modular
UVA needed to wrap more rights data
Any grounds for us to be looking into a gem that becomes a standard way to handle this in Hydra?
Mirador could be a base (does tiling), extensible
sprint to build annotation into openseadragon
Harvard Project to use Mirador 2 as a pt
driving force for ux: 2-page book, turning pages; don’t just want sequential images; the skeumorphism is important
is there a pattern to feed one of these ready made front-ends from hydra? how do you define the structure?
people wanting bookreaders probably have metadata with structure
ability to embed content in other environments, e.g. take something out of a hydra repo and embed it somewhere else where you get analytics/access/etc.