Good point about the licencing issues, Olli. Comments inside.
...
> 3) We'd like to solve the oh-so-problematic copyright + lisencing problems
> with the
> adoption of MH. Our underlying idea is to ask the publishing permissions and
> e.g.
> possible Creative Commons lisencing attributes from the person who actually
> owns the lecture capture / the uploaded video file. Currently we do this with
> a
> separate web form + database, but I'd like to find one, way more robust
> solution
> for this task. One of the reasons for this attempt is the question: is the
> lecture
> scheduler / file uploader the actual copyright holder or is the scheduler /
> file
> uploader merely an "operator"? I assume that in many of the cases the
> scheduler /
> file uploader isn't the copyright owner. Thus, if we really want to address
> this
> problem thoroughly - and I guess we do
> - we may need an extra ROLE_COPYRIGHTHOLDER in MH. If MH could save the
> copyright holder data into the db we wouldn't need to deal with the printed
> out
> Terms of Service documents etc. This would save the admins from so much
> hassle!
I like the idea of the person responsible to make certain decisions, i.e. about
the licence and the actual publication. I guess it would be closely linked to
the hold-status where you would schedule everything for the lecturer, the
recordings are being processed, but the final step towards publication waits
for that person. However, I wouldn't like to bother lecturers with this on a
weekly basis, so the decision on the licence for example should be made once
for a series of recordings.
> 4) In our long term plans we would like to open our MH for all of our
> teachers and
> professors. Our idea is to create a "Univ of Helsinki MH-Tube"-type of a
> service
> which would let the staff members be active publishers of video content. This
> is
> why we see that our teachers should get a path from our LMS to schedule
> recording and upload videos from within the LMS (in our case, Moodle). This
> way
> we wouldn't actually make a pointless detour where the teacher asks the ICT
> support person to schedule the lecture capture if the teacher could do it
> him/herself from the LMS.
>
> >Basically, what we're interested in is whether there are some >Matterhorn
> admin
> activites that you want some of your users to be able >to do that you don't
> want
> others to do.
>
> Our teachers are asking me if they'll be able to do e.g. the following:
>
> - publishing the videos with a separate password. This is a painful thing to
> maintain, I know, but we have teachers who ask it on a daily basis. They'd
> like to be
> able to set a simple password for their videos so that the vids would show up
> in
> their video series but viewing them would require the password. This use case
> would help e.g. our Open University who have lecturers and students with no
> user
> account from our Uni.
Again, interesting point, that could be good for non-lecture recordings also
(workshops, conferences) where you have people looking for access from all over
the place.
> - publishing the videos to a range / list of IP addresses
Not very likely scenario here, unless you're referring to some form of national
authentication/authorization infrastructure.
> - publishing the videos for only a certain amount of time (e.g. 6/12/18
> months). It
> would be great if the lecture scheduler or file uploader could set the expiry
> date at
> the publishing process. After the vid has expired the MH server could send a
> message to the vid owner stating that the file will be deleted unless the
> video
> owner sets the expiry date to a date and time in future. We've done this with
> our
> Moodle and Wiki installations and would very much want to see a similar
> approach
> possible with MH. After all, within a couple of years the MH servers in our
> Universities will become crowded with useful and not so useful data.
> We as admins cannot take the burden of separating these vids from each other
> but
> the file owners can. Thus, I think it would be a great idea to add a garbage
> collection feature to MH. We just have to make sure it is our teachers who
> "take out
> the carbage". :-)
That's a very good point (not related to this topic, mind you). While we're not
that much into deleting content at ETH, it would be good to have a date of
expiry especially for videos your hosting for third parties, where you don't
know whether the website where the video is being embedded is still active.
Just have the contract say "available for three years" and let MH take care of
reminding you and the owner of upcoming expiry dates and upcoming deletion.
O
>
> Yours, Olli Salo from the University of Helsinki
>
>
>
>
>
>
>
>
> On 13.9.2011 0:52, Judy Stern wrote:
> > Thanks, Olaf, for responding. Still hoping to hear from others describing
> > their
> needs re. levels of authorization for *administering* Matterhorn; I'd hate to
> move
> forward only taking into account the needs of ETH and Berkeley.
> > Or should I assume that folks are only concerned with authorization as
> > it pertains to *viewing* published media? (Thanks, Pete, for giving us
> > input on that side of things.)
> >
> > Specific responses inline:
> >
> > On Sep 9, 2011, at 5:00 PM, Schulte Olaf A. wrote:
> >
> >> Changed the "Edit" to "Manage". There is "Make changes" also, is that
> >> identical
> to "Manage" (cannot edit that mock-up)?
> > Many thanks for making those edits! (Balsamiq can be quite annoying at
> > times!) "Make changes" was simply the wording I used in an alternative
> > design. I
> was using all three ("Manage", "Make changes", "Edit") to mean essentially the
> same thing and just hadn't settled on one; it's the kind of thing we can
> change
> easily later on.
> >
> >
> >>> --Or do you need this to be more fine-grained, e.g. something like
> >>> <http://opencast.jira.com/wiki/display/MH/Extended+Series+Authorizat
> >>> ion>? (This is only a sketch to demonstrate what more fine-grained
> >>> authorization might entail...don't take it too seriously.)
> >>
> >> Having a quick look at your mock-ups, I'd say that the extended
> >> authorization is
> not necessary for us here at ETH. If I understand your distinction
> correctly...
> > Good to know. So far I haven't heard that anybody needs Series permissions
> > to
> be more fine-grained than "Manage".
> >
> >>> <http://opencast.jira.com/wiki/display/MH/Roles+page> (again just a
> >>> sketch as we begin to play with ideas...these may not be at a useful
> >>> or realistic level of granularity). We'll also need to limit access
> >>> to capture agents (no sketches for this yet).
> >>
> >> ... I would speak in favour of having sophisticated "admin" roles
> >> instead in that
> >>
> >> - we would like students to do the trimming, without being able to do
> >> anything else or
> >> - would like to restrict any deletion action (scheduled recordings,
> >> recordings) to
> the actual admin(s).
> >
> > If a Roles UI (similar to what I sketched) included "Trim Recordings" and
> "Authorize publishing" (or something like that) as privileges that could be
> checked,
> wouldn't that meet your needs? (I realize that the current Review/Trim UI
> doesn't
> separate out these actions, but it seems like it could.) Or am I
> misunderstanding
> your needs?
> >
> >>> let us know if you'd be
> >>> willing to be interviewed!
> >>
> >> Sure - makes a change from talking about metadata...
> >
> > Good! We'll be in touch to set something up.
> > (But don't assume you're off the hook for talking about metadata! I
> > need to get back to you on that, too!)
> >
> > thanks,
> > 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]
> > _______________________________________________
> >
>
>
> --
> Olli Salo
> Tietotekniikkakeskus
> Helsingin yliopisto
> Tel: +358 9 191 21782
> Gsm: +358 50 407 5509
> 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]
_______________________________________________
