Discuss: Event Metadata #1
Conversation
| - `creators: NonBlankString[]`: The people mainly responsible for creating this video and/or presenting the talk which this video is a recording of. Should contain human-readable names and not usernames. Plain text. This is the main "who?"-information shown in the UIs; other fields in `extraMetadata` (e.g. `dct:contributor`) might be shown too, but less prominently. | ||
| - `language: LangCode?`: describes the (main) language of this event and its metadata. For example, the audio language and (if applicable) language of video content is more important than the language of available subtitles. Generally, assets can have their own language specified. | ||
| - `series: SeriesID?`: optional ID of the series this event belongs to. Must be a valid series ID of an existing series at all time. | ||
| - `owner: Username`: TODO figure out details |
There was a problem hiding this comment.
Should we allow owner to also be a group rather than just an individual?
There was a problem hiding this comment.
Personally, I would like to only ever have a single individual (one person to "speak" to), but I see that others might want to have multiple users.
docs/event/metadata.md
Outdated
| - `endTime: DateTime?`: Like `startTime`, but when the video recording stopped. Due to cutting, recording pauses and etc, the `duration` is not necessarily `end - start`. | ||
| - `duration: Milliseconds` 🟦: duration of the event. As specified in ["assets"](./assets), this needs to always match the duration of all non-internal tracks. | ||
| - `updated: Timestamp` 🟦: Timestamp of when anything about this event was last changed. | ||
| - `created: Timestamp` 🟦: Timestamp of when the event was created in Opencast. It is set once when the event is first stored in Opencast's DB, and never changed again. This also implies that scheduled event's `created` date is when the scheduling took place, _not_ the time it is scheduled for (that would be `startDate`) |
There was a problem hiding this comment.
Can you elaborate? Like, add an immutable field to the event? What would that do exactly?
There was a problem hiding this comment.
@JamesUoM ping (otherwise i will mark this as resolved soonish to have a better overview over open issues)
docs/event/metadata.md
Outdated
| - `endTime: DateTime?`: Like `startTime`, but when the video recording stopped. Due to cutting, recording pauses and etc, the `duration` is not necessarily `end - start`. | ||
| - `duration: Milliseconds` 🟦: duration of the event. As specified in ["assets"](./assets), this needs to always match the duration of all non-internal tracks. | ||
| - `updated: Timestamp` 🟦: Timestamp of when anything about this event was last changed. | ||
| - `created: Timestamp` 🟦: Timestamp of when the event was created in Opencast. It is set once when the event is first stored in Opencast's DB, and never changed again. This also implies that scheduled event's `created` date is when the scheduling took place, _not_ the time it is scheduled for (that would be `startDate`) |
There was a problem hiding this comment.
available: DateTimeRange : publication period when the event is visible to intended audience. Can be unset or open-ended.
Maybe this should be specific to each publication?
There was a problem hiding this comment.
publication
No idea what you are talking about :D
But yeah I guess this available is related to the lifecycle management? Did not consider anything there. Will think about it and also talk to Arne.
mtneug
left a comment
mtneug
left a comment
There was a problem hiding this comment.
Is ETHZ still using translated metadata (e.g. metadata with a language code attached to it)? Do we want that?
| - `description: string?`: user-specified, human-readable description, potentially quite long. | ||
| - TODO: Decide whether this is plain text, markdown or anything else. External apps displaying this need to know that. Some basic formatting options might be nice? | ||
| - `creators: NonBlankString[]`: The people mainly responsible for creating this video and/or presenting the talk which this video is a recording of. Should contain human-readable names and not usernames. Plain text. This is the main "who?"-information shown in the UIs; other fields in `extraMetadata` (e.g. `dct:contributor`) might be shown too, but less prominently. | ||
| - `language: LangCode?`: describes the (main) language of this event and its metadata. For example, the audio language and (if applicable) language of video content is more important than the language of available subtitles. Generally, assets can have their own language specified. |
There was a problem hiding this comment.
So what if you have multiple audio tracks with different languages? If this can be specified at the asset level, why have this at the event level?
There was a problem hiding this comment.
Mhh interesting. So when e.g. Tobira would want to a show a language for an event, it would be derived from the track properties... maybe? But how would that work for an uploader UI? I am assuming that we do not always can/want to auto-detect the language, so it is useful for the user/video manager to specify a language when uploading, right? But what if a video file with multiple tracks is uploaded? Mh... Does the user then need to specify the lang per track? Or does an uploader only have a single "language" field? Since multiple audio tracks are likely very rare?
| - `creators: NonBlankString[]`: The people mainly responsible for creating this video and/or presenting the talk which this video is a recording of. Should contain human-readable names and not usernames. Plain text. This is the main "who?"-information shown in the UIs; other fields in `extraMetadata` (e.g. `dct:contributor`) might be shown too, but less prominently. | ||
| - `language: LangCode?`: describes the (main) language of this event and its metadata. For example, the audio language and (if applicable) language of video content is more important than the language of available subtitles. Generally, assets can have their own language specified. | ||
| - `series: SeriesID?`: optional ID of the series this event belongs to. Must be a valid series ID of an existing series at all time. | ||
| - `owner: Username`: TODO figure out details |
There was a problem hiding this comment.
Personally, I would like to only ever have a single individual (one person to "speak" to), but I see that others might want to have multiple users.
| - `creators: NonBlankString[]`: The people mainly responsible for creating this video and/or presenting the talk which this video is a recording of. Should contain human-readable names and not usernames. Plain text. This is the main "who?"-information shown in the UIs; other fields in `extraMetadata` (e.g. `dct:contributor`) might be shown too, but less prominently. | ||
| - `language: LangCode?`: describes the (main) language of this event and its metadata. For example, the audio language and (if applicable) language of video content is more important than the language of available subtitles. Generally, assets can have their own language specified. | ||
| - `series: SeriesID?`: optional ID of the series this event belongs to. Must be a valid series ID of an existing series at all time. | ||
| - `owner: Username`: TODO figure out details |
There was a problem hiding this comment.
In the past, people disagreed on the definition of the term "owner". Mainly is this the person legally owning this piece of media vs is this the person responsible for uploading this and having all the rights to manage this video. IMO it should be the latter and leave copyright stuff to other fields.
Note: ILIAS and Moodle encode ownership in the ACLs with a specific owner role (ROLE_OWNER_{username} by default). This makes sense if the owner should have all access rights. On the other hand, you could not include the write action, which doesn't make sense... On the other other hand, if access rights are controlled by metadata, this feels wrong.
This is not written here, but I would not require the username to exist. Uploading from Moodle / ILIAS is possible without Opencast knowing that the user exists. And I don't want Moodle / ILIAS to create user records.
There was a problem hiding this comment.
As obvious by the "TODO", I will still think about all of this, but here are a few points that are already clear in my head:
- Yes, the copyright/legal stuff I would solve with other fields, most likely DC
rightsHolder - The owner field will not affect access rights, only the ACL does that.
- Yes the username does not need to exist. The check is simply not possible with the wide range of auth systems we want to support.
docs/event/metadata.md
Outdated
| - `endTime: DateTime?`: Like `startTime`, but when the video recording stopped. Due to cutting, recording pauses and etc, the `duration` is not necessarily `end - start`. | ||
| - `duration: Milliseconds` 🟦: duration of the event. As specified in ["assets"](./assets), this needs to always match the duration of all non-internal tracks. | ||
| - `updated: Timestamp` 🟦: Timestamp of when anything about this event was last changed. | ||
| - `created: Timestamp` 🟦: Timestamp of when the event was created in Opencast. It is set once when the event is first stored in Opencast's DB, and never changed again. This also implies that scheduled event's `created` date is when the scheduling took place, _not_ the time it is scheduled for (that would be `startDate`) |
There was a problem hiding this comment.
@KatrinIhler wrote:
- suggestion: add ingested additionally to created?
- more (explicitely named) date fields = less confusion & discussion about what they mean?
There was a problem hiding this comment.
Are you suggesting two fields that do exactly the same?
There was a problem hiding this comment.
ingest would be different for events from capture agents. it would the timestamp when the finished recording was ingested in opencast.
For user uploads it's probably the same as created.
| - `startTime: DateTime?`: Actual real life datetime when the video recording started or will start, with timezone. If this is not applicable, for example because it's a short movie, this should be undefined. UIs should use this as primary date to show for a video and if unset, fallback to `created`. | ||
| - `endTime: DateTime?`: Like `startTime`, but when the video recording stopped. Due to cutting, recording pauses and etc, the `duration` is not necessarily `end - start`. | ||
| - `duration: Milliseconds` 🟦: duration of the event. As specified in ["assets"](./assets), this needs to always match the duration of all non-internal tracks. |
There was a problem hiding this comment.
My understanding is that endTime would be the endTime used to schedule the recording.
But there could be a difference between the scheduled endTime and the real live end time of the recording.
An event scheduled to end at, say, 16:00 might end early and they manually stop the recording on the recording device at, say, 15:47. I'm not sure if it's necessary to have the real live end time as an event attribute, but certainly the duration of the tracks would be different to the duration of the event.
Is it even necessary to have the duration on the event level? From my point of view, the duration should always be endTime - startTime, so it would be redundant information.
Since `created` and this field talk about the same event in time, they should share similarity in their name. And `ingest` is just wrong for scheduled videos.
Some fields I previously suggested were questionable in widespread usefulness so we decided to introduce them as experimental fields first. To do that, I fleshed out the `extraMetadata` section with more details.
| - `modified: Timestamp` 🟦: Timestamp of when anything about this event was last changed. | ||
| - More precisely: at any point in time since `modified`, all fields, assets, ACL and any other part of the event data model need to have the exact same value as they have at the present moment. | ||
| Whenever anything about an event described in this data model changes, `modified` has to be set to `now()`. | ||
| - Noteworthy case: when a series is deleted and the event's `series` field is set to `null`, the event's `modified` needs to change. |
There was a problem hiding this comment.
Do we still want this configurable? Currently, you can configure if deleting a non-empty series is forbidden or allowed and leaving the events without a series. I would suggest disallowing deleting non-empty series and making this not configurable.
There was a problem hiding this comment.
Hu interesting, that's fine by me. But I suspect that at least some people want an easy way to remove the series from a bunch of videos at the same time. But 🤷 I can also just remove this note from the spec, so that the spec does not directly say anything about this topic.
This discussion PR is for only event metadata.
To add new comments, go into the "files changed" tab and comment on individual lines or sections of lines. Or you can comment on existing discussion threads here. If you feel like you want to start a discussion about a broader topic (than something mainly referencing a few lines), consider open a new discussion here.