Skip to content

Commit 41a97e5

Browse files
committed
Rationalise ### headings in P4 index
1 parent ee74f6a commit 41a97e5

File tree

1 file changed

+36
-55
lines changed

1 file changed

+36
-55
lines changed

source/presentation/4.0/index.md

Lines changed: 36 additions & 55 deletions
Original file line numberDiff line numberDiff line change
@@ -191,14 +191,10 @@ comment annotation about part of the previous example's Canvas using FragmentSel
191191
```
192192

193193

194-
## Presenting Content Resources
195194

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
197196

198-
199-
### Images
200-
201-
#### Use Case 1: Artwork
197+
### Use Case 1: Artwork
202198

203199
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.
204200

@@ -213,7 +209,7 @@ label, summary, metadata, rights, provider, homepage, thumbnail
213209
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.
214210

215211

216-
#### Example 2: Book
212+
### Example 2: Book
217213

218214
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.
219215

@@ -224,9 +220,9 @@ requiredStatement, behavior, viewingDirection, (no Ranges), rendering - PDF vers
224220

225221

226222

227-
### Audio and Video
223+
## Audio and Video
228224

229-
#### Example: a 45 single with one Timeline per song/side
225+
### Example: a 45 single with one Timeline per song/side
230226

231227
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.
232228

@@ -242,7 +238,7 @@ duration, autoPlay, format, annotations (transcript), language, accompanyingCont
242238
...
243239
```
244240

245-
#### Example: a movie with subtitles
241+
### Example: a movie with subtitles
246242

247243
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.
248244

@@ -264,7 +260,7 @@ duration, behavior=autoplay, format, Choice of video 720p, 4K? (forward ref), ti
264260
Sometimes, two different formats derived from the same source may have slightly different durations, perhaps a few milliseconds out. What to do...
265261

266262

267-
### 3D
263+
## 3D
268264

269265
3D Content Resources are painted into Scenes.
270266

@@ -273,7 +269,7 @@ Scenes have infinite height (y axis), width (x axis) and depth (z axis), where 0
273269
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)).
274270

275271

276-
#### Example: Static 3D Model of a Spacesuit
272+
### Example: Static 3D Model of a Spacesuit
277273

278274

279275
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
302298
point selector for positioning
303299

304300

305-
#### Example: 3D Model of a Chessboard
301+
### Example: 3D Model of a Chessboard
306302

307303
Chessboard is a Canvas with image
308304
more than one model
@@ -318,7 +314,7 @@ interactionMode
318314

319315

320316

321-
#### Merge the below into the examples or into model
317+
### Merge the below into the examples or into model
322318

323319
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).
324320

@@ -517,9 +513,9 @@ Todo add example
517513

518514

519515

520-
#### Scene-Specific Resources
516+
### Scene-Specific Resources
521517

522-
##### Camera
518+
#### Camera
523519

524520
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.
525521

@@ -559,7 +555,7 @@ The first Camera defined and not hidden in a Scene is the default Camera used to
559555

560556

561557

562-
##### Light
558+
#### Light
563559

564560
This specification defines four types of Light:
565561

@@ -718,33 +714,20 @@ When a Scene is nested into another Scene, the `backgroundColor` of the Scene to
718714

719715

720716

721-
## Annotations and State
722-
723-
724-
725-
### Example: Multi-spectral Images with Comments
726-
717+
## Annotations
727718

728719

729-
### Annotations
730-
731-
non-painting
732-
733-
Comments, tags, etc
734720

735-
transcripts (and back ref to OCR on images etc)
721+
### Comment Annotations
736722

737723

738-
#### Comment Annotations
739724

725+
### Choice of Alternative Resources
740726

727+
Example: Multi-spectral Images with Comments
741728

742-
#### Choice of Alternative Resources
743729

744-
Multispectral here
745-
746-
747-
#### Embedded Content
730+
### Embedded Content
748731

749732
e.g., painting TextualBody on Canvas
750733

@@ -755,34 +738,34 @@ It is important to be able to position the textual body of an annotation within
755738

756739

757740

758-
#### Non Rectangular Segments
741+
### Non Rectangular Segments
759742

760743
SvgSelector - move to SpecificResource too ^^
761744

762745

763-
#### Style
746+
### Style
764747

765748
Move to SpecificResource
766749

767750

768-
#### Rotation
751+
### Rotation
769752

770753

771-
#### Hotspot Linking and Activation
754+
### Hotspot Linking and Activation
772755

773756
Move to SpecificResource
774757

775758

776759

777760

778-
#### Annotation Page
761+
### Annotation Page
779762

780763
"Overlapping elements with a larger z-index cover those with a smaller one."
781764
link to https://developer.mozilla.org/en-US/docs/Web/CSS/z-index
782765

783766

784767

785-
#### Annotation Collection
768+
### Annotation Collection
786769

787770
deal with this:
788771
https://github.com/IIIF/api/pull/2304/files#diff-cc70f02818f6bed2b14dfbf8bf3206e0825047951c8e83ad56fc73e489f82ac4R1757
@@ -865,10 +848,8 @@ partOf -
865848

866849

867850

868-
## State
869-
870851

871-
### Content State
852+
## Content State
872853

873854
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:
874855

@@ -982,14 +963,14 @@ Annotations with the motivation `contentState` are referred to as _content state
982963

983964
Content States are used for the following applications:
984965

985-
#### Load a particular view of a resource or group of resources
966+
### Load a particular view of a resource or group of resources
986967

987968
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.
988969

989970
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.
990971

991972

992-
#### Load a particular view of some resource and modify it
973+
### Load a particular view of some resource and modify it
993974

994975
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:
995976

@@ -1033,7 +1014,7 @@ TODO: what is the processing algorithm for applying incoming `hidden` ?
10331014
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.
10341015

10351016

1036-
#### Modify the Container in a particular context
1017+
### Modify the Container in a particular context
10371018

10381019
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.
10391020

@@ -1201,19 +1182,19 @@ Use of `scope` is permitted in annotations on any Container type, not just Scene
12011182

12021183

12031184

1204-
#### The `sequence` behavior
1185+
### The `sequence` behavior
12051186

12061187
// Is this right? Language...
12071188

12081189
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.
12091190

1210-
#### Content States on Manifests
1191+
### Content States on Manifests
12111192

12121193
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.
12131194

12141195
// Is there some overlap here with Range?
12151196

1216-
#### Processing Content States in Scopes: reset
1197+
### Processing Content States in Scopes: reset
12171198

12181199
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.
12191200

@@ -1291,17 +1272,17 @@ Before applying the content state to the Scene, the client should reset the Scen
12911272

12921273
// 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...
12931274

1294-
#### Contribute additional information permanently
1275+
### Contribute additional information permanently
12951276

12961277
Rerum inbox scenario - should be covered in CS2 protocol
12971278

1298-
#### activating - animation and interactions
1279+
### activating - animation and interactions
12991280

13001281
Annotations with the motivation `activating` are referred to as _activating_ annotations.
13011282

13021283
There are two uses of `activating` annotations:
13031284

1304-
##### Triggering a content state
1285+
#### Triggering a content state
13051286

13061287
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.
13071288

@@ -1375,7 +1356,7 @@ The activating annotation is provided in a Container's `annotations` property. I
13751356

13761357

13771358

1378-
##### Triggering a named animation in a model
1359+
#### Triggering a named animation in a model
13791360

13801361
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.
13811362

@@ -1463,7 +1444,7 @@ if the `target` is an AnimationSelector, then the `body` can ONLY be TextualBody
14631444

14641445
There is a more general rule here!
14651446

1466-
#### reset
1447+
### reset
14671448

14681449
See above...
14691450

0 commit comments

Comments
 (0)