My understanding is that CA / scheduling service use dcterms:created to inform about starting time and end time (cf. http://opencast.jira.com/wiki/display/MH/Mapping+item+and+collection+metadata+with+Admin+UI). However, http://opencast.jira.com/wiki/display/MH/Metadata+mapping+in+the+UI tells me there is a mapping with a "date" property ("Recording Date/Time getDublinCoreProperty(dcCatalog, DublinCoreCatalog.PROPERTY_DATE") which doesn't actually exist in DC. Anyone can enlighten me on this? Chris?
Anyway, in order to stay consistent, I would recommend using dcterms:created. Any reason for using dcterms:temporal? O > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:matterhorn- > [email protected]] Im Auftrag von Adam Hochman > Gesendet: Mittwoch, 9. März 2011 07:24 > An: Opencast Matterhorn > Betreff: Re: [Opencast Matterhorn] Matterhorn 1.2, iteration 1: what should we > tackle about Delete? > > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
