New version in Google doc
https://docs.google.com/document/d/1l7tjSrn7CDeYWp_Z_Id3BAIhWktwReXvkqhzPhu-sp0/edit#
{ | |
"@context": "http://iiif.io/api/presentation/4/context.json", | |
"id": "https://example.org/iiif/3d/manifest", | |
"type": "Manifest", | |
"label": { "en": [ "I am 3D" ] }, | |
"behavior": [ "some", "new", "behaviors", "probably" ], | |
"items": [ | |
{ |
{ | |
"@context": "http://iiif.io/api/presentation/4/context.json", | |
"id": "https://example.org/iiif/3d/manifest", | |
"type": "Manifest", | |
"label": { "en": [ "I am 3D" ] }, | |
// all your favourite IIIF props are exactly the same | |
"behavior": [ "some", "new", "behaviors", "probably" ], | |
New version in Google doc
https://docs.google.com/document/d/1l7tjSrn7CDeYWp_Z_Id3BAIhWktwReXvkqhzPhu-sp0/edit#
What are we doing here?
Combo of text from the Google doc and text from the process recipe/index.md
https://docs.google.com/document/d/1DEwDTU_PGV_1mXYJlAOtADxwfnqfov2gRO7NbMfl0t8/edit https://preview.iiif.io/cookbook/master/recipe/
(the answer to this might be completely different for DDS on AWS - e.g., a massive location-resolving key-value store.)
Given a relative file path in a METS file (e.g., a JP2 or ALTO file), the DDS needs to resolve the S3 location of that file.
The simple way to do this is load the storage manifest, find the entry corresponding to the path in METS, and deduce the S3 URI. But that would be very inefficient.
So the DDS caches a StorageMap for each storage manifest, which is this object, serialised:
[Serializable]
title Sorty, Presley and Omeka | |
participant User | |
participant Sorty | |
participant Presley | |
participant Omeka | |
note over User, Sorty | |
Sorty instance is configured with module for selecting | |
appropiate source manifests for the project. In IDA case, | |
a module that pulls in the list of prepared reels. | |
end note |
As an editor, you have been given the task of making the slideshow seen here:
https://www.vam.ac.uk/articles/gilbert-mosaics
The materials you have been given to work with are a list of IIIF Image API endpoints. The thumbnails below are not to be used, they are just to be able to see which image is which. The only data to use is the Image Service URL.
It's a better test of the tools if you type at least some of the text by hand, creating links and styling where appropriate. However, there is quite a lot of text, so you could also copy and paste bits from the manifest directly. However, you should treat this text as if it were in a document given to you by a content editor.
Many Wellcome works are printed books with illustrations, figures, tables and so on that are identified by OCR during digitisation.
Many of those will have text nearby, that is likely to be a caption that describes the image.
The IIIF representation offers a quick way of getting pixels for the region of the page occupied by the image, and could be a way of finding nearby text.
Example:
I hereby claim:
To claim this, I am signing this object:
Update, March 2019
Many of the discussions below have been synthesised into this slide deck: https://docs.google.com/presentation/d/1zAmXDlfvuwlQtp9uVgFLS7RVcfNqTcyEJybnNdQ2TgY
The links below are more comprehensive and are kept here for posterity. The other document worth considering is this:
Universal Viewer design principles
(in progress) Inspired by discussions at UVCON; an attempt to set out some guiding principles for the UV; comments sought!