So we should make sure we're consistently using dcterms:created for any of the date/time info that's currently in the UIs. (Perhaps we can someday use dcterms:temporal to indicate the academic term, as suggested in your table, Olaf?)
Judy On Mar 9, 2011, at 2:57 PM, Schulte Olaf A. wrote: > 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] > _______________________________________________ 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] _______________________________________________
