IIIF / api

Source for API and model specifications documents (api and model)
http://iiif.io/api
105 stars 54 forks source link

Consider `Timeline` class #2279

Open tomcrane opened 5 months ago

tomcrane commented 5 months ago

Presentation 3 only has Canvas as content carrier, which can either have dimensions width, height, duration, or just duration (e.g., for audio).

Presentation 4 will introduce a Scene class, an unbounded, 3D space. This is necessary as 3D is fundamentally different and extending Canvas, while simple, would not be practical for 3D implementations.

Given that we MUST now introduce more than one content carrier, we could use Presentation 4 to introduce another new class Timeline, to use instead of Canvases with t dimension only.

This has much simplifying potential in the spec, for rules on dimension compatibility. And the conversion from Presentation 3 to 4 would be to simply change the type of time-only canvases to Timeline, leaving everything else as-is.

However...

There are millions of audio-only manifests with Canvases having duration-only that, we think, will already be valid Presentation 4 manifests too, if we don't make this change. E.g., all the recent Internet Archive audio manifests.

We would end up with:

Timeline

A virtual container that represents a bounded temporal range, without any spatial coordinates.

Canvas

A virtual container that represents a bounded, two-dimensional space and has content resources associated with all or parts of it. It may also have a bounded temporal range in the same manner as a Timeline.

Scene

A virtual container that represents a boundless three-dimensional space and has content resources positioned at locations within it. It may also have a bounded temporal range in the same manner as a Timeline.


Feedback very much appreciated!

triplingual commented 5 months ago

Reflexive, shallow thoughts:

Having two ways to do time-only resources helps backwards-compatibility but is confusing for new adopters. I'd think formal deprecation of Canvas for time-only resources would be good, though I don't begin to know the way that would go down.

It also feels awkward for video. With Timeline, we'd have resources in categories Visual, Time, 3D and Visual+Time (video). This is probably the overly literal part of my brain reacting, but I also think it's worth some consideration on how video use is accommodated and what the community interaction is going to be like around the changes.

DiegoPino commented 5 months ago

From the perspective of an developer,Timeline just for Audio and an eventual deprecation of time based media (also just for audio bc video is still drawn in 2 space) for Canvas, I feel if you decide to go that route it should be "recommended for V4, to be deprecated in V5", there are just too many Viewers and APIs (e.g Content Search) that are fixed on the idea of Canvas right now. On a positive side, I don't think any existing manifests or even code will be 100% compatible in V4 (@context, properties all will need to be changed anyways), so that is less a concern for us. Also, time as a dimension is not in the plans for 3D? like a annotation/time based tour of a 3D scene for example? Or a 3D animation? This last question is without knowing (or doing Specs reading legwork) enough of course.

Also a bit off topic to the discussion but I wonder how under the idea of this new Container, "Scene" you plan on defining the 2D aspect of the 3D scene, which at the end, from a software/device implementation is 3D coordinates drawn in 2D Space (3D is projected by a camera) and could still fit/require the idea of a Canvas? I imagined that Canvas, in that sense, fitted into the concept of Camera/projection/render dimensions (or aspect ration at least) for 3D and the scene would be a child element of a Canvas even maybe allowing e.g a 3D object to be positioned on top of a static asset. Even more off topic, how e.g a 3D Video (which has embedded the idea of 2 dimensions as frame for pseudo 3D (the camera can move) that could have annotations pointing to a particular camera rotation? This is just a side thought that comes late of course.

workergnome commented 5 months ago

My sense is that I'd take a single way to do things, even if it's not as linguistically elegant, over two ways to do a thing. My preference is to stick with Canvas and add Scene if that's something that you need for 3D, since it's going to be quite different!

mprove commented 5 months ago

Well, it looks clean and simple. But I cannot really comment w/o considering the scenarios that should be supported by this data structure. Let me try. Although this might lead us down the garden path into the banal.

I also have the feeling that there is a distinction between "scene" and "scenery". The latter sounds static to me while "scene" is more movie-like, the change of something over time.

I hope this helps by any means. I just won't jump to new terms that are in common use somewhere else with a different meaning for us. And I don't have a final opinion as long as the kinds of media that should be represented by IIIFpresentationV4 is blurry in my head.

Update: I was looking for a corresponding 3D metaphor to canvas. I came up with » stage « You scan a 3D object and present it on a IIIF stage. Makes sense to me.

robcast commented 5 months ago

I really like the idea of separating the basic types based on their basic presentation and interaction model: 1d Timeline, 2d Canvas, 3d Scene. I think this distinction makes it easier for newcomers to read and write manifests than the current duration-only-Canvas.

I think the question of compatibility is a separate concern that needs to take into account how the parallel use of V3 and V4 (and V2?) is envisioned. If V4 is mainly introduced for new resources and new clients for e.g. 3d content then backwards-compatibility is not so important and I would vote to deprecate duration-only Canvases for V4. The Internet Archive's V3 time-only Canvases will remain V3 which is fine for all the existing V3 clients. Clients that want to accommodate both V3 and V4 have to do a bit of translation which seems easier than dealing with both V2 and V3 today (knowing nothing about the rest of V4's changes ;-).

tomcrane commented 3 months ago

Thank you all. As expected, mixed feelings.

To be clear, Scene is a given - we must introduce that new concept, that new class that can be a member of manifest.items along with Canvas. That is a decided conclusion of the 3D TSG, and is necessary for the reasons given in that issue. To try to force this behavior into Canvas would produced a very unsatisfactory spec.

If we had tackled 3D and introduced Scene at the same time as AV work was happening, back when work on what became Presentation 3 started, it would have made sense at that time to also introduce another class to represent an extent of time only. But back then it was not necessary to take the drastic step of introducing a new class; it was neater to add a continuous duration property to Canvas, measured in seconds, in addition to the existing width and height, and also permit Canvas to only have that property if it did not represent a spatial extent. Which gives us our current Presentation 3 Canvas definition.

Now that we must introduce a new class Scene, now that we must permit manifest.items to contain more than one type of thing, is it worth taking the opportunity to introduce a third class that represents a continuous extent of time without any spatial extent? i.e., Timeline (or Timespan or whatever we might call it)?

Or is it the case, as it quite strongly made by some above, that that ship has sailed, and the potential simplification for newcomers does not outweigh the undesirable task of explaining that you used to be able to use a Canvas as a Timeline, that it's still allowed in V4 but deprecated, etc.

A Scene shares most of its properties with Canvas, including duration - as always and for obvious (and not so obvious) reasons a continuous property measured in the real world units of seconds.

So to rephrase it's a choice between:

Three classes

Timeline

Canvas

Scene

Two classes

Canvas

Scene


There's an opportunity to discuss this in tomorrow's TSG (Wednesday) for those attending.