You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/presentation/4.0/index.md
+36-55Lines changed: 36 additions & 55 deletions
Original file line number
Diff line number
Diff line change
@@ -191,14 +191,10 @@ comment annotation about part of the previous example's Canvas using FragmentSel
191
191
```
192
192
193
193
194
-
## Presenting Content Resources
195
194
196
-
This section of the specification uses the use cases listed in the introduction to demonstrate the use of the IIIF Presentation API and introduce additional features.
195
+
## Image Content
197
196
198
-
199
-
### Images
200
-
201
-
#### Use Case 1: Artwork
197
+
### Use Case 1: Artwork
202
198
203
199
This example is a Manifest with one Canvas, with an image of an artwork "painted" onto the Canvas. It demonstrates the use of the common descriptive properties `label` for the title of the artwork, `metadata` for additional information to display to the user, `summary` for a brief description of the artwork, `rights` to assert a rights statement or license from a controlled vocabulary, `homepage` to link to the artwork's specific web page, `thumbnail` to provide a small image to stand for the Manifest, and `provider` to give information about the publisher of the Manifest.
Notice that the painting Annotation is a member of the `items` property of an Annotation Page. While in this case there is only one Annotation Page and one Annotation, the mechanism is needed for consistency when there are multiple Annotation Pages, and it allows for Annotation Pages in general to be separate resources on the web.
214
210
215
211
216
-
####Example 2: Book
212
+
### Example 2: Book
217
213
218
214
This example is a Manifest with multiple Canvases, each of which represents a page of a book. It demonstrates the use of the `behavior` property to indicate to a client that the object is _paged_: this helps a client generate the correct user experience. The `viewingDirection` property indicates that the book is read left-to-right. In this case, the property is redundant as `left-to-right` is the default value. The Manifest has a `rendering` property linking to a PDF representation; typically a client would offer this as a download or "view as" option. The `start` property is used to tell a client to initialize the view on a particular Canvas, useful if the digitized work contains a large amount of irrelevant front matter or blank pages. The `requiredStatement` is a message that a client MUST show to the user when presenting the Manifest.
219
215
@@ -224,9 +220,9 @@ requiredStatement, behavior, viewingDirection, (no Ranges), rendering - PDF vers
224
220
225
221
226
222
227
-
###Audio and Video
223
+
## Audio and Video
228
224
229
-
####Example: a 45 single with one Timeline per song/side
225
+
### Example: a 45 single with one Timeline per song/side
230
226
231
227
This example is a Manifest with two Timelines, each of which represent a temporal extent during which a song is played. As in most cases, the Timeline `duration` is the same length as that of Content Resource painted into it. This example is a recording digitized from a 45 RPM 7 inch single. It demonstrates the use of `format` for the audio files' content type, `language` (One song is in English and one is in German), `behavior` with value "autoPlay" that tells a client to automatically advance to the second Timeline after playing the first, `annotations` that link to Annotation Pages of annotations with the motivation `supplementing` that provide the lyrics (one example is given afterwards) - and an `accompanyingContainer` that carries a picture of the single's cover that is shown while the songs are playing.
This example is a Manifest with one Canvas that represents the temporal extent of the movie (the Canvas `duration`) and its aspect ratio (given by the `width` and `height` of the Canvas). The example demonstrates the use of a `Choice` annotation body to give two alternative versions of the movie, the `timeMode` property ..., and `placeholderContainer` that provides a poster image to show in place of the video file before the user initiates playback.
248
244
@@ -264,7 +260,7 @@ duration, behavior=autoplay, format, Choice of video 720p, 4K? (forward ref), ti
264
260
Sometimes, two different formats derived from the same source may have slightly different durations, perhaps a few milliseconds out. What to do...
265
261
266
262
267
-
###3D
263
+
## 3D
268
264
269
265
3D Content Resources are painted into Scenes.
270
266
@@ -273,7 +269,7 @@ Scenes have infinite height (y axis), width (x axis) and depth (z axis), where 0
273
269
The positive y axis points upwards, the positive x axis points to the right, and the positive z axis points forwards (a [right-handed cartesian coordinate system](https://en.wikipedia.org/wiki/Right-hand_rule)).
274
270
275
271
276
-
####Example: Static 3D Model of a Spacesuit
272
+
### Example: Static 3D Model of a Spacesuit
277
273
278
274
279
275
This example is a Manifest with a single Scene, with a single model of a space suit painted at the Scene's origin.
@@ -302,7 +298,7 @@ backgroundColor: #000
302
298
point selector for positioning
303
299
304
300
305
-
####Example: 3D Model of a Chessboard
301
+
### Example: 3D Model of a Chessboard
306
302
307
303
Chessboard is a Canvas with image
308
304
more than one model
@@ -318,7 +314,7 @@ interactionMode
318
314
319
315
320
316
321
-
####Merge the below into the examples or into model
317
+
### Merge the below into the examples or into model
322
318
323
319
This (no units for scale) allows arbitrarily scaled models to be used, including very small or very large, without needing to deal with very small or very large values. If there is a correspondence to a physical scale, then this can be asserted using the physical dimensions pattern(fwd-ref-to-phys-dims).
324
320
@@ -517,9 +513,9 @@ Todo add example
517
513
518
514
519
515
520
-
####Scene-Specific Resources
516
+
### Scene-Specific Resources
521
517
522
-
#####Camera
518
+
#### Camera
523
519
524
520
A Camera provides a view of a region of the Scene's space from a particular position within the Scene; the client constructs a viewport into the Scene and uses the view of one or more Cameras to render that region. The size and aspect ratio of the viewport is client and device dependent.
525
521
@@ -559,7 +555,7 @@ The first Camera defined and not hidden in a Scene is the default Camera used to
559
555
560
556
561
557
562
-
#####Light
558
+
#### Light
563
559
564
560
This specification defines four types of Light:
565
561
@@ -718,33 +714,20 @@ When a Scene is nested into another Scene, the `backgroundColor` of the Scene to
718
714
719
715
720
716
721
-
## Annotations and State
722
-
723
-
724
-
725
-
### Example: Multi-spectral Images with Comments
726
-
717
+
## Annotations
727
718
728
719
729
-
### Annotations
730
-
731
-
non-painting
732
-
733
-
Comments, tags, etc
734
720
735
-
transcripts (and back ref to OCR on images etc)
721
+
### Comment Annotations
736
722
737
723
738
-
#### Comment Annotations
739
724
725
+
### Choice of Alternative Resources
740
726
727
+
Example: Multi-spectral Images with Comments
741
728
742
-
#### Choice of Alternative Resources
743
729
744
-
Multispectral here
745
-
746
-
747
-
#### Embedded Content
730
+
### Embedded Content
748
731
749
732
e.g., painting TextualBody on Canvas
750
733
@@ -755,34 +738,34 @@ It is important to be able to position the textual body of an annotation within
755
738
756
739
757
740
758
-
####Non Rectangular Segments
741
+
### Non Rectangular Segments
759
742
760
743
SvgSelector - move to SpecificResource too ^^
761
744
762
745
763
-
####Style
746
+
### Style
764
747
765
748
Move to SpecificResource
766
749
767
750
768
-
####Rotation
751
+
### Rotation
769
752
770
753
771
-
####Hotspot Linking and Activation
754
+
### Hotspot Linking and Activation
772
755
773
756
Move to SpecificResource
774
757
775
758
776
759
777
760
778
-
####Annotation Page
761
+
### Annotation Page
779
762
780
763
"Overlapping elements with a larger z-index cover those with a smaller one."
781
764
link to https://developer.mozilla.org/en-US/docs/Web/CSS/z-index
A Content State is simply any valid IIIF Presentation Resource, or part of a Presentation resource. The following are all Content States that describe a "fragment" of IIIF:
874
855
@@ -982,14 +963,14 @@ Annotations with the motivation `contentState` are referred to as _content state
982
963
983
964
Content States are used for the following applications:
984
965
985
-
####Load a particular view of a resource or group of resources
966
+
### Load a particular view of a resource or group of resources
986
967
987
968
In this usage, an annotation with the motivation `contentState` is passed to a client to initialize it with a particular view of a resource. Almost all IIIF Clients initialize from the very simplest form of Content State - a Manifest URI. A more complex Content State might target a particular region of a particular canvas within a Manifest, as in the second example above. A client initialized from such a Content State would load the Manifest, show the particular Canvas, and perhaps zoom in on the target region.
988
969
989
970
The mechanisms for passing Content State into a client, and exporting a Content State from a client, are given in the Content State Protocol API 2.0 specification, which describes the scenarios in which a URI, or Content State not carried by an annotation, should be interpreted by a Client as a Content State.
990
971
991
972
992
-
####Load a particular view of some resource and modify it
973
+
### Load a particular view of some resource and modify it
993
974
994
975
In the previous usage, the fragment of IIIF carried by the annotation with the motivation `contentState` provides enough information for a Client to load a resource and show it. This fragment can also carry additional IIIF Presentation API resources not shown in the referred-to resource. For example, in the following example the Content State carries additional annotations not present in the original published Manifest. A client initializing from this Content State would show these additional annotations to the user:
995
976
@@ -1033,7 +1014,7 @@ TODO: what is the processing algorithm for applying incoming `hidden` ?
1033
1014
When a Content State annotation carries a Scene, a view might be initialized from a Content State that introduces an additional Camera that shows the user the point of interest.
1034
1015
1035
1016
1036
-
####Modify the Container in a particular context
1017
+
### Modify the Container in a particular context
1037
1018
1038
1019
The techniques in the previous example are also used within a published IIIF Manifest to modify the contents of a Container in the contexts of different annotations on that Container. This technique allows IIIF to be used for _storytelling_ and other narrative applications beyond simply conveying a static Digital Object into a viewer and leaving subsequent interactions entirely in the control of the user. The `scope` property indicates to the client that the Content State provides valuable context for displaying some aspect of a Scene or other Container. In the case of a commenting annotation, this means that the Content State should be loaded when the commenting annotation is selected or otherwise highlighted.
1039
1020
@@ -1201,19 +1182,19 @@ Use of `scope` is permitted in annotations on any Container type, not just Scene
1201
1182
1202
1183
1203
1184
1204
-
####The `sequence` behavior
1185
+
### The `sequence` behavior
1205
1186
1206
1187
// Is this right? Language...
1207
1188
1208
1189
While all AnnotationPage `items` are inherently ordered, an Annotation Page with the behavior `sequence` is explicitly a narrative, and clients should prevent (dissuade) users from jumping about. The presence of `sequence` affects the way a client should interpret the `reset` property described below.
1209
1190
1210
-
####Content States on Manifests
1191
+
### Content States on Manifests
1211
1192
1212
1193
When an annotation with the motivation `contentState` is provided via the `annotations` property of a Manifest, rather than contextually via `scope`, it is assumed to be generally available for selection by the user at any time. A client may present such as annotations as a menu of views, allowing arbitrary jumping into any Scene (or Canvas or Timeline) from any other point.
1213
1194
1214
1195
// Is there some overlap here with Range?
1215
1196
1216
-
####Processing Content States in Scopes: reset
1197
+
### Processing Content States in Scopes: reset
1217
1198
1218
1199
When a Content State is applied to a Container such as a Scene, it is assumed to be a "diff" - for example if 3 cameras and 4 lights are already present in the Scene, and a Content State asserts a single new Camera, the default behavior is to add this fourth Camera to the Scene and leave the existing resources as they are.
1219
1200
@@ -1291,17 +1272,17 @@ Before applying the content state to the Scene, the client should reset the Scen
1291
1272
1292
1273
// I am assuming reset is always true except in `linear-nav` - otherwise it's completely unpredictable!! or is it... arbitrary navigation, state provided by initialization content states, etc...
1293
1274
1294
-
####Contribute additional information permanently
1275
+
### Contribute additional information permanently
1295
1276
1296
1277
Rerum inbox scenario - should be covered in CS2 protocol
1297
1278
1298
-
####activating - animation and interactions
1279
+
### activating - animation and interactions
1299
1280
1300
1281
Annotations with the motivation `activating` are referred to as _activating_ annotations.
1301
1282
1302
1283
There are two uses of `activating` annotations:
1303
1284
1304
-
#####Triggering a content state
1285
+
#### Triggering a content state
1305
1286
1306
1287
An activating annotation links a painting annotation to a content state. When a user interacts with the painting annotation - whether through clicking it, tapping it, or other client-specific behaviors - the linked content state should be processed to modify the Scene or other Container, as in the previous examples. The painting annotation is the target of the activating annotation, and the content state is the body value. Only one content state may be specified in the body array, but the body array may include a `TextualBody` to provide a label for the interaction. The pattern is the same as for the `linking` motivation, but rather than the client opening a new browser window on the resource specified in the `body`, it applies the modification provided by the Content State.
1307
1288
@@ -1375,7 +1356,7 @@ The activating annotation is provided in a Container's `annotations` property. I
1375
1356
1376
1357
1377
1358
1378
-
#####Triggering a named animation in a model
1359
+
#### Triggering a named animation in a model
1379
1360
1380
1361
Sometimes a model file has inbuilt animations. While a description of these is outside the scope of IIIF, because it is 3D-implementation-specific, as long as there is a way to refer to a model's animation(s) by name, we can connect the animation to IIIF resources.
1381
1362
@@ -1463,7 +1444,7 @@ if the `target` is an AnimationSelector, then the `body` can ONLY be TextualBody
0 commit comments