3. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Without Standards We Have Silos
Application A
Server A
Application B
Server B
Application C
Server C
Application D
Server D
4. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Technology Becomes Interchangeable
Application A
Server D
Application B
Server C Server B
Application C
Server A
Application D
5. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Resources Become Shareable
Application A
Server D
Application B
Server C Server B
Application C
Server A
Application D
7. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Syntax
(Just Enough) Technical Metadata
The Image
Server Capabilities
http(s)://{server}{/prefix}/{id}/info.json
http(s)://{server}{/prefix}/{id}/{region}/{size}/{rotation}/{quality}.{fmt}
http://iiif.io/api/image/2/level2.json
8. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Syntax
• Full Size, Whole Image
• 400 Wide, Whole Image
• 400 Wide, Region
• 400 Wide, Region, Rotated
• 400 Wide, Region, Rotated, Grayscale
• Thumbnail, as a PNG
11. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Implementations
Servers Clients
djatoka
digilibCONTENTdm
OpenSeadragon
IIPMooViewer
OpenLayers
Leaflet-IIIF
12. @jpstroop
Sharing Images of Global Cultural Heritage, NGA, 5 May 2015
Thank You!
http://iiif.io/api/image/2.0/
Jon Stroop
Princeton University Library
jpstroop@gmail.com
@jpstroop
Notes de l'éditeur
As you've heard already IIIF has published two API specifications:
The Image API: for getting at images and relevant metadata
The PresentationAPI: images with relevant descriptive properties, in the context of related content included text transcriptions, annotation, and other related images.
What is the Problem that the Image API tries to solve?
The problem is that we're all locked into our image delivery systems, and because of this, we can't share our content or choose different tools.
Let me explain.
Without standards we can only have closed systems, servers clients that understand a particular, unique protocol.
The Image API makes technologies interchangeable, giving us choices between different technologies in the different roles within our application stack
This allows us to choose:
Best of breed tech (server and client)
Servers that play well in existing environment/infrastructure
Clients that are most suitable to your resources and/or users
Finally, if it isn’t obvious, this also means we can share resources, as clients can speak to multiple servers; this is the heart of the IIIF vision.
[Bring up spec briefly: http://iiif.io/api/image/2.0/ ]
We’re not going to work through this line by line; I’m going to give you an overview by means of a demo.
We worked very hard to determine what the most useful information, parameters services are.
There have been other attempts at this in the past, but the results were generally too complicated, too server-specific, or included a lot of detail or superfluous syntax that UI designers didn't want to have to know.
We ultimately decided that the server needed three broad categories of service:
The image
Technical metadata
A way to express the server's capabilities (what can this server do?)
The first two services are defined as syntaxes for that software and humans can build. Server capabilities are published on the IIIF website and can be linked to, as I'll demonstrate in a few minutes
For the image service, we ultimately decided that region, size, rotation, quality, and format are in scope, but that things like color management and format-specific details like compression are out. I’ll illustrate these in a demo momentarily
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
These URIs demonstrate just a few of the ways in which the Image API allows you to manipulate images
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
* Actual image is 5204 x 7200; this is scaled to fit the slid
* This is smaller than 400 wide, to fit the slide
We don't expect humans to do this, but this gives you a nice, clean, reusable (cacheable) URI
* You can't tell it's a png, but trust me….
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
## Go to live demo, during which, be careful to point out:
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
For the technical metadata service, all elements should be machine-extractable, and there should be just enough to drive a rich client, e.g. qualities available, image size, tile size, and in case the server doesn’t support arbitrary sizes, what sizes are available.
## Go to live demo, during which, be careful to point out:
While one can carefully craft URIs (as I'll do while demonstrating), it is generally expected and intended that URIs will be built using rich web-clients, some of which we’ll demonstrate a bit later on.
That said, having a tidy persistent URL for citations, annotations, web exhibitions, emailing, and other means of sharing can be quite useful, and they make web caches more efficient
Implementations
As you've heard already IIIF has published two API specifications:
The Image API: for getting at images and relevant metadata
The PresentationAPI: images with relevant descriptive properties, in the context of related content included text transcriptions, annotation, and other related images.