Ah, finally back to metadata nit-picking... Judy, I think you're referring to
dcterms:temporal ("Academic term") for the series/collection - as indicated in
the headline for the table at
http://opencast.jira.com/wiki/display/MH/Mapping+item+and+collection+metadata+with+Admin+UI,
the series/collection metadata are to the left. My understanding is that
dcterms:created is being used for start/end for the episode, granulated down to
the actual time (subject to clarifications mentioned) and could bear the same
"period character" for series by indicating the first and last lecture of a
course or a conference. dcterms:temporal would then indicate the semester for
the series and date for the episode (and, yes, that would be redundant to this
information being contained in dcterms:created for the item already). CC'ing my
library colleague here to get confirmation on my half knowledge.
O
> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:matterhorn-
> [email protected]] Im Auftrag von Judy Stern
> Gesendet: Donnerstag, 10. März 2011 00:10
> An: Opencast Matterhorn
> Betreff: Re: [Opencast Matterhorn] Matterhorn 1.2, iteration 1: what should we
> tackle about Delete?
>
> 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]
> _______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
