Olaf, I thought we were using dc:temporal for time of the event. That
is my understanding at least for MH-6901.
On 3/8/11 10:49 AM, Schulte Olaf A. wrote:
Hello Judy
Today, in our Product Owner meeting it was tentatively agreed that we would work
on Delete in this next iteration; the user story that we voted on was
http://opencast.jira.com/browse/MH-6018, but this is too big and needs to be
split
into more reasonably scoped stories, of which we presumably would work on only
one or two.
So, I kindly request that you take a look at
http://opencast.jira.com/wiki/display/MH/1.2+Delete+Options
Here we list the various stages in the life of a recording in which users would
want
to delete or remove recordings and/or media, along with relevant current user
stories (and use cases).
My instinct is to NOT tackle anything in the Finished column. Sticking to
providing
them options in the On Hold stage would be my vote. What about yours?
Agree with restricting the options for the iteration, but going beyond the "On
hold" state for a moment as discussed:
With respect to the "slug" (I assume we're talking about a dummy episode à la http://fwd4.me/xAf),
I think we might have to clarify what "Replacing media with slug" means: You would probably have to
update metadata as well, if only for dcterms:extent for the video duration, maybe dcterms:title also for
people to identify the missing episode immediately without having to click on it ("Chemistry IV: Lecture
4 - unpublished"). Also, I seem to remember there was a technical reason (checksum being built?) you
couldn't just easily swap media tracks, but maybe that's a REPLAY phantom pain.
As far as "Publication without media" is concerned, I'm not sure that is a good option in
that the MMM as well as the embedded player or any other video player you use to present your
episode won't have anything to display. While this might work in a portal (or even the MMM) where
the additional metadata informs people the episode hasn't been published, this information would
not be displayed in a "pure" video player - it would be a blank, suggesting technical
failure. So I would argue for always having some slug/dummy episode to replace de-/unpublished
media. The downside being that they also make it to RSS and iTunes (U) as you can see from the
example above. Thoughts? We actually accept that in order for people not to worry why March 23 was
not recorded.
Finally, you're asking about metadata for ordering the episodes of a series: That of course is
dcterms:created which should be "YYYY-MM-DDThh:mm" in order to make sure you can order
episodes from the same day (conference). As discussed, an additional option to order episodes
"anti-RSS" (where the oldest recording is first in the list) would be handy at some stage
in the workflow to display episodes from a one-day workshop in the order they were recorded - not
the other way round...
Regards
Olaf A.
Judy
Judy Stern
Educational Technology Services, UC Berkeley [email protected]
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
