Just a reminder there's also "dcterms:available" ("Date (often a range) that
the resource will become or did become available.") and "dcterms:valid" ("Date
(often a range) of validity of a resource.") to limit the time of publication
(if publication channels allows).
O
>-----Ursprüngliche Nachricht-----
>Von: [email protected] [mailto:matterhorn-users-
>[email protected]] Im Auftrag von Michelle Ziegmann
>Gesendet: Mittwoch, 12. September 2012 20:42
>An: [email protected]
>Betreff: Re: [Matterhorn-users] Anybody interested in a publish delay feature?
>
>Agreed - great ideas from all. Especially Olaf's suggestion to use the
>"dc:issues"
>metadata field.
>
>We talked about the option of restricting access vs delayed processing, which
>is a
>good idea except when you're dealing with other distribution channels, YouTube
>for
>example. We need to prevent the recording from getting published to YouTube
>until
>the specified date, so need to look into this from the processing/workflow
>side.
>
>Thanks!
>Michelle
>
>
>On 9/12/12 11:28 AM, Denny wrote:
>> On 9/12/12 12:09 PM, Hank Magnuski wrote:
>>> Rather than thinking of it as a "delay" perhaps the right concept is
>>> "Publication Date". I can think of other scenarios for a "Publication Date"
>>> idea:
>>>
>>> 1. If your video is announcing some new scientific discovery you
>>> might want it to be restricted until the official Journal publication
>>> of the news is on the streets.
>>>
>>> 2. If you are launching a new product you will probably want to
>>> restrict access to the video of it until the official press releases
>>> and announcements are done.
>>>
>>> A companion feature would be "Publication End Date" when you want the
>>> video to go into hiding once again. Perhaps you are running some type
>>> of promotion and the news becomes old news after some cutoff time. At
>>> a University this might be a video on how to register for classes
>>> which is no longer needed when the registration deadline passes.
>> Great ideas!
>>
>> I see this as more of an authorization issue (as you said, "restrict")
>> than a processing issue, per se. If it is kept in the authorization
>> realm, then you can do stuff like share it with a select group first, etc..
>>
>> The stickler is that MH doesn't really /do/ authorization. That
>> responsibility is (generally) on a different layer, right?
>>
>> FWIW, I use CAS for authentication and then the default DB for
>> authorization, so something in MH would work for me... tho we'll
>> probably add in LDAP at some later point.
>>
>> How are most people handling roles/groups/authorization?
>>
>> :Denny
>>
>
>--
>=================
>Michelle Ziegmann
>Technical Project Manager
>Educational Technology Services
>University of California Berkeley
>
>_______________________________________________
>Matterhorn-users mailing list
>[email protected]
>http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
_______________________________________________
Matterhorn-users mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
