Ruben,

You would be fine with the CA just supplying new or modified metadata
and not having its metadata delete values from the server, correct?
This limitation would make a declarative approach much easier I think.

Chris

On Wed, 20 Jun 2012 21:48:09 +0200
Rubén Pérez <[email protected]> wrote:

> >
> > So far I don't know of any capture agent that supports changing
> > metadata locally
> 
> 
> Galicaster does. We use it all the time (in the Oxford Unconference,
> for instance, we would edit the metadata as the recording was going
> on).
> 
> 
> > , and the scenarios that we have been discussing on list recently
> > seem artificial, however not completely off.
> 
> 
> A class is scheduled but the administrative services do not know which
> topic is it about beforehand. The teacher updates the metadata as
> he/she desires on the spot, so that no further communication is
> needed with the administrators to set the right
> title/description/etc. right.
> 
> The teacher wants to include some comments or remarks on whatever
> interesting have occurred during the class, which was not foreseen:
> some answer to a student's question, which turned out to be very
> instructive, for instance; or correcting some mistake made in the
> lecture which the teacher notices before the class ends (even though
> it's corrected later on, you can expect some students to see the
> mistake but miss the part where it's corrected).
> 
> We schedule some unconference sessions, of which we know the length,
> but not the subject. The device is set to not ingest the recordings
> automatically. After the sessions, an operator edits the fields of the
> recordings and ingests them.
> 
> Not saying that cannot be done in the core afterwards, but this may
> save some trouble (specially the first scenario) because the
> professor does not have to contact the media services to correct some
> typo/add some metadata to their classes --they just edit that
> themselves. Or not. But at least there's a choice.
> 
> 2012/6/20 Greg Logan <[email protected]>
> 
> > On 12-06-20 06:58 AM, Tobias Wunden wrote:
> > > Hi Ruben,
> > >
> > >> If I understand it correctly:
> > >>      • The scheduler will keep sending ALL the catalogs in the
> > >> iCal
> > file.
> > >>      • It's up the the CA implementations whether to send those
> > catalogs back to the server or not.
> > >> -- But this may cause data inconsistencies if the scheduled
> > >> metadata is
> > changed and the agent starts the recording before polling the new
> > data from the scheduler.
> > >>      • Those catalogs which are sent back "overwrite" those that
> > >> are
> > kept in the server.
> > >
> > > this is from my point of view an exact summary of the proposal.
> > >
> > >> I've got some remarks here:
> > >>      • The synch problem explained in 2) is a more general issue.
> > Perhaps we should somehow check the agent's polling time and lock
> > changes to the schedules that will surely not be updated on time.
> > In the end, it all goes down to the communication protocol between
> > server and capture agent --either we change it completely so that
> > the core can activelly poll the agent or we assume the limitations
> > of the current model and deal with them.
> > >
> > > By design there is no communication between core and capture
> > > agent that
> > is initiated by the core, since in many cases, the capture devices
> > will not be reachable from the outside world (including the core).
> >
> > The CA pushes its configuration to the core however, and one of the
> > configuration items is the polling interval (at least for the
> > reference CA).  I don't know about the vendors though...
> >
> >
> > _______________________________________________
> > Matterhorn mailing list
> > [email protected]
> > http://lists.opencastproject.org/mailman/listinfo/matterhorn
> >
> >
> > To unsubscribe please email
> > [email protected]
> > _______________________________________________
> >



-- 
Christopher Brooks, BSc, MSc
ARIES Laboratory, University of Saskatchewan

Web: http://www.cs.usask.ca/~cab938
Phone: 1.306.966.1442
Mail: Advanced Research in Intelligent Educational Systems Laboratory
     Department of Computer Science
     University of Saskatchewan
     176 Thorvaldson Building
     110 Science Place
     Saskatoon, SK
     S7N 5C9
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to