Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Timeline class #2279

Open
tomcrane opened this issue Feb 1, 2024 · 6 comments
Open

Consider Timeline class #2279

tomcrane opened this issue Feb 1, 2024 · 6 comments

Comments

@tomcrane
Copy link
Contributor

tomcrane commented Feb 1, 2024

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
Copy link

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
Copy link

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
Copy link

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
Copy link

mprove commented Feb 3, 2024

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.

  • photos, paintings, pages, maps >> 2D pixel areas == canvas √ok
  • music, podcasts, radio shows >> frequencies during a time span from 0 to an end == "timeline" (?) ––– "Timeline" feels odd to me; timeline is a sequence of events following each other in time. First a, then b 10 seconds later, then c 10 years later… Don't know if "timespan" is more generic or more specific than "timeline". We are looking for an equivalent to "canvas", a dimension with a scale that can be used to navigate the audio stream. It should be continuous and not a discrete set of time stamps.
  • a sculpture >> 3D pixels == "space" or "scene" …
  • a video >> a 2D pixel area that changes over time >> canvas + timespan/timeline
  • a juggler >> 3D pixels that change over time >> ok, now we are in 3D space + timeline/timespan (or just "time"!?).

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
Copy link

robcast commented Feb 5, 2024

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
Copy link
Contributor Author

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

  • has continuous duration in seconds

Canvas

  • has integer, unitless width and height
  • has optional continuous duration in seconds

Scene

  • has continuous, unitless x,y,z cartesian coordinate space
  • has optional continuous duration in seconds

Two classes

Canvas

  • has optional integer, unitless width and height
  • has optional continuous duration in seconds
  • must have one or other or both of these options

Scene

  • has continuous, unitless x,y,z cartesian coordinate space
  • has optional continuous duration in seconds

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants