Karen's scenario looks more like a republishing strategy to me, especially as I wouldn't want the recordings in a space for a year where I usually expect them to remain for a couple of days or weeks. In general though, ETH would welcome such a feature.
With respect to Warren's remarks, metadata could come to the rescue as there is a DC metadata field available which might be helpful: "dcterms:issued" is the "Date of formal issuance (e.g., publication) of the resource." [1], which could be made available for both the episode (publishing recordings at regular intervals) and the series (publish all recordings with same delay). O [1] http://opencast.jira.com/wiki/display/MHDOC/Matterhorn+metadata+scheme+%28work+in+progress%29. Von: [email protected] [mailto:[email protected]] Im Auftrag von Long, Warren Gesendet: Mittwoch, 12. September 2012 16:45 An: Opencast Matterhorn Betreff: Re: [Opencast Matterhorn] Anybody interested in a publish delay feature? Hi there: It sounds like having a release date for each capture would be useful. I do like the fact that a delay could be part of the series info, and therefore only needs to be set once, but this is an awkward thing to use for last years lectures... Warren On 2012-09-12, at 6:39 AM, Michelle Ziegmann wrote: Karen, that's interesting. So in your case, instead of specifying the "number of days after capture" to proceed with publishing, you would want to specify a specific date for each recording. That's a little different than we were thinking, but I think that approach offers more flexibility to accommodate different needs. Thanks for your input! Ruben, yes, we need something automated. The problem is that it would be incredibly time-consuming (and error-prone) for a webcast administrator who is responsible for review/trim/publish for 60+ courses to keep track of each instructor's preference for how long they want to delay publishing and manually implement those delays. Michelle On 9/12/2012 5:29 AM, Karen Dolan wrote: Rubén & Judy, A use case for automated delay... We occasionally republish a lecture series from previous terms. The re-engineered episodes have a staggered release to simulate the normal pacing of a course. The paced release keeps a group of students on the same page, literally, to work through the material together. Karen On 9/12/2012 3:55 AM, Rubén Pérez wrote: I wonder... doesn't it suffice with modifying the distribute / publish operation(s) so that they can hold until the administrator approves their publishing? Or do you need an automated delay that does not require further human intervention? Best regards Rubén Pérez TELTEK Video Research www.teltek.es<http://www.teltek.es/> 2012/9/12 Judy Stern <[email protected]<mailto:[email protected]>> Here at UC Berkeley, our existing webcast administration system has a publish delay feature, where he can specify that recordings for a course not be made available for a specified number of hours or days. This is appreciated by instructors who feel that immediate publication of their lectures encourages student absences from class. (One instructor, who opted for a several day delay, wrote: "a number of my colleagues in CS have been hesitant to have webcasting because they believe students won't come to class anymore, but so far my experience is that this short delay is enough to prevent that problem".) The relevant user story, http://opencast.jira.com/browse/MH-5393, is now assigned to Michelle, who is project managing our local efforts. Our UI work will likely involve minor changes (an extra element or two) on the Scheduling/Upload UI's; we also need to decide where such "delayed" recordings appear in the Recordings tab. John King, one of our developers, will also likely be writing new workflows and workflow operations to enable this. I would like to hear from any of you if your institution would be interested in using this feature, or if you would like to participate in a community design review of this feature. (We think it's good open source citizenship to share with the community what we're working on, and would love to take into account the needs of other institutions wherever possible.) If there's interest in a design review meeting, I'll work with those interested to schedule. Regards, Judy Stern _______________________________________________ Matterhorn mailing list [email protected]<mailto:[email protected]> http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected]<mailto:[email protected]> _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected]<mailto:[email protected]> http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected]<mailto:[email protected]> _______________________________________________ -- Karen Dolan Harvard University, DCE 617-998-8439 [email protected]<mailto:[email protected]> _______________________________________________ Matterhorn mailing list [email protected]<mailto:[email protected]> http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected]<mailto:[email protected]> _______________________________________________ -- Michelle Ziegmann Educational Technology Services University of California Berkeley _______________________________________________ Matterhorn mailing list [email protected]<mailto:[email protected]> http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected]<mailto:[email protected]> _______________________________________________ _____________________________________ Warren Long Senior Instructional Support Specialist Information and Communications Technology Email: [email protected]<mailto:[email protected]> Ph: (306) 966-5426 [cid:[email protected]]
<<inline: image001.png>>
<<inline: image002.png>>
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
