Introduce timeMode property

[jpstroop]

For Annotations this applies to all resources in the Body of the Annotation that could be considered to have a duration. Possible values are trim (default), scale, and loop

[azaroth42]

Is the set of values a closed list, or open to extension via URIs? I prefer extensible with the clear warning that URIs are not expected to be processed by general clients, and that they will fall back to the default.

[zimeon]

I agree that simple string values defined in the spec, with URIs allowed for extension is good. That follows the spirit of the Define Success, Not Failure pattern while avoiding possible future incompatibility.

[tomcrane]

Agreed that there should be these three timeModes on AV call 25/7/2017.

Issue discussed:

Canvases MUST have asserted dimensions, which means you have to assert a duration for your canvas for Citizen Kane. Your metadata says that your video file for Citizen Kane is 119m (that's what Wikipedia says, for instance). So you have a canvas with duration: 7140

Turns out your video of Citizen Kane is 7167 seconds long.

The default timeMode is trim, which means that the client brings the viewing experience to a halt 27 seconds before the end.

To counter this behaviour, as a manifest publisher unsure of the precise duration, you add a bit of leeway. For example you say that the canvas has duration: 7200 to avoid it being trimmed.

But now you have the possibility of dead air at the end of the canvas.

We spent some time discussing an additional behaviour that can be specified for the canvas, that tells a viewer that if there is no content left to render in the canvas's time dimension, to do whatever it would do for that canvas when it reached the end of its duration naturally, i.e., bring the canvas to an early end in this case.

This doesn't stop anyone later adding annotations in the dead air, the manifest publisher is providing a clearly defined extent of time (and space in this case) for annotations to target. Now there would be content in what was the dead air. This extra property of a canvas tightens up the user experience when there is no content at the end of that space.

Or is this a client implementation decision, on which the spec should be silent?

@mikeapp considered how this behaviour would interact with content that specifies loop and scale, if they target the whole duration of the canvas. What happens then? I think that this is OK, there is no dead air in this case, it's being filled with looping or time-distorted content.

[mikeapp]

In other words, the presence of an annotation on the canvas as a whole would cause the canvas to play for the entire specified duration. Does the Citizen Kane video annotation in the example above have an explicit duration?

[mikeapp]

On further consideration @tomcrane's suggestion is that only loop or scale will extend the canvas to full duration, so that's no objection to the the Citizen Kane video being annotated to the canvas without duration. I don't see a problem with that.

[workergnome]

If I'm understanding this correctly, we're dealing with the fact that some annotation durations , as annotated, might be incorrect. The question in my mind is, "is the annotation or the media the source of truth as to the duration of the media?"

I think a viewing hint specifying what a canvas should do with 'dead air' can be a useful thing, particularly in the case of empty canvases—if I have a canvas with duration 1 min, but I do not have any annotations on it, it would seem useful to set it it 'trim', so a viewer could know that it's not essential to have 1 min of dead space in a playlist.

[tomcrane]

Generalising...

The publisher of the canvas establishes an extent with coordinates of (x,y), (x,y,t) or (t). All clients must respect that extent and accurately render content positioned within it. The hint would convey to a client application that if all the content it has managed to collect together (whether inline, external, a live annotation made just now) falls short of the boundaries of the extent, it is permitted to collapse that extent to fit the content.

Maybe that's the default behaviour in the time dimension. Or for the end of the canvas time but not the start.

This issue doesn't come up with spatial content because there is absolutely nothing wrong with making it fit the canvas, it's a complete non-issue and it's what the spec wants us to do, the problem just doesn't exist. And if we were 4 dimensional hyper-beings, it wouldn't matter for (x,y,t) content either. But we're not... and we don't want a behaviour that requires a client to stretch time-based media by a tiny percentage when there's a slight and almost certainly unintentional discrepancy between the media running time and the canvas duration. Having trim as the default timeMode solves this when the content is too long, but there's a UX issue when the content falls short.

There may be a very good reason why a publisher wishes to establish an extent of dead air, maybe to encourage people to add content to it. So the choice needs to be there, between automatically collapsing the end of the canvas time, and keeping the clock running.

[workergnome]

I agree with almost everything @tomcrane says.

I just want to reiterate that what we're accommodating for is for inaccurate metadata—when the annotation says it's duration: 7140, but is duration: 7167. I think the equivalent would be if we were to mis-state the aspect ratio of a canvas—as in, say: http://evil-manifests.davidnewbury.com/iiif/garden/scaled.json.

So I think we're asking if we need to encode a hint to help clients figure out the right thing to do when the manifest contains an error?

[azaroth42]

Confirm in Toronto.

[azaroth42]

Getty Discussion: 👍 to extensibility, and 👍 to prefixed URIs in custom contexts, eg the (fictional) British Library Timemode of Sandwich that squashes from both ends could be blt:sandwich.

[azaroth42]

Acknowledged the possibility of the jarring effect described above, but recommendation to see what happens in practice both before 3.0 Final and then can still fix in 3.1 if needed.

[jpstroop]

Toronto WG Plenary: 👍

[azaroth42]

Done: http://prezi3.iiif.io/api/presentation/3.0/#timemode