Publications (remove or change?) and event assets (delivery, internal)

[LukasKalbertodt]

Opencast currently has "publication channels", which I always disliked. I see these disadvantages:

• Metadata (title, description, ...) can be different in publications than the main data store. This is highly unintuitive and trips up basically all new Opencast users, and many experienced ones as well.
• Metadata updates require starting a workflow, at least for the "engage" publication, which is argueably the main one right now. Again, super unexpected and confuses lots of admins. UIs for "normal users" always automatically start this workflow, as they realize that's what normal users expect. But this adds lots of implementation complexity.
• Publications mean that there can be ambiguity of which video files to show to a user. Ignoring different qualities and multi-track events, there should always be a unique video file to show to the user when a user wants to "watch" a video.

The new data model should solve those points: there is a single "title" for an event, which is always updated immediately, and there is always a well defined (set of) video file(s) to show to the user.

So should we remove the conecept of publications completely? Maybe. But there are some reasons to keep the concept around, albeit in a different form:

• We might want plugins that push a video to an external system, like YouTube. We want to keep track of that somehow.
• Tobira or an LMS referencing a video can be seen as some kind of publication. For example, Olaf always thinks of "adding a video to a page in Tobira" as a publication, even though it's not one in the current Opencast-way of the term.
• Apart from media for playing the video (which might be HLS stuff), one might want to offer a file for download. This asset should be differentiated from the others and publications might be a way to do that?
• Similarly, an event might have internal assets that are temporary versions, the original ingested video, or what not. These need to be differentiated as well.

For all of these, there are different options (e.g. tags for assets, extraMetadata, ..). Publications are not needed. But maybe some kind of new publication system could be a nice way to cater to those use cases. Again, it would need to confirm to the requirements laid out above, e.g. publications don't have their own metadata copy.

Previous discussions:

• 2025-04-01
• Discuss: Event Assets #2 (comment)
• Discuss: Event Assets #2 (comment)
• Discuss: remaining topics #3 (comment)
• Discuss: remaining topics #3 (comment)

[mtneug]

Publications in Opencast do the following:

• Distributing elements and keeping track of what elements have been distributed
• Attaching a URL to the event that represents the publication (can be optional)
• Serving that publication hopefully under the specified URL

At the moment, we have the following implementations:

Engage

• Distributes files to the "engage-player" channel, i.e. path on the local fs or S3
• Attach the /play/{id} URL to the event
• Add event (and series) to the search index
• Serving = search index, static assets, more?

Configurable

• Distribute files to {user-defined} channel, i.e. path on the local fs or S3
• Attach {user-defined} URL to the event (optional)
• Serving = static assets

OAI-PMH

• Distribute files to oaipmh-{user-defined} channel, i.e. path on the local fs or S3
• Attach URL to OAI-PMH item to the event
• Add/Update item to the OAI-PMH data store
• Serving = OAI-PMH API, static assets

YouTube (never used this, so this might not be fully correct)

• Distribute files to YouTube
• Attach YouTube URL to event (?)
• Serving = YouTube serves the video

---

A publication thus represents multiple things at the same time. Maybe we can pull things apart:

• Provide a way to group different elements. This can be similar to tagging, i.e. a groups field on the element. We could use group names similar to the current channel names engage, download, youtube, {user-defined}. Downstream services can then select from these groups for their purpose (play video, allow downloads, etc.)
• Always add events to the search index. If there is only one metadata version, the search index should always contain the current version as well.
• Distributing files could happen in different ways. We could unify asset stores (archive and distribution) and only have a single way to access static assets. This may be tricky for users of streaming distributions, i.e. Wowza users right now. But we could also argue to no longer support Wowza for VoD content and package for HLS/DASH ourselves.
• Some URLs could be well-known without adding them to the event. Or we could have a url field on the event that has a mapping of id -> url with an operation that fills this field.
• Threat YouTube and OAI-PMH as special cases and not store publication data from those services within the event data model, i.e. keep the data in additional tables. Or we could keep it in the extraMetadata field.