Details

    • Type: Sub-Task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed, no review needed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Legacy

      Description

      Converse with Olaf and Allison to identify the best method of updating metadata in media packages that already exist, then update the wiki service definitions for ingestion that include methods to do this.

        Gliffy Diagrams

          Issue Links

            Activity

            cab938 Christopher Brooks created issue -
            cab938 Christopher Brooks made changes -
            Field Original Value New Value
            Fix Version/s Release 0.5 [ 10000 ]
            Fix Version/s Iteration 2 [ 10010 ]
            cab938 Christopher Brooks made changes -
            Component/s *Administrative Tools Team [ 10040 ]
            cab938 Christopher Brooks made changes -
            Additional Assignee(s) [abloodworth, oas]
            Component/s #openquestion [ 10043 ]
            Fix Version/s Iteration 3 [ 10020 ]
            Affects Version/s Iteration 2 [ 10010 ]
            Description Converse with Olaf and Allison to identify the best method of updating metadata in media packages that already exist, then update the wiki service definitions for ingestion that include methods to do this.
            Fix Version/s Release 0.5 [ 10000 ]
            Fix Version/s Iteration 2 [ 10010 ]
            Hide
            cab938 Christopher Brooks added a comment -
            Are extensions to the media inspection service to enable modification of metadata reasonable? Initial exploration of this for iteration 3 would be good.

            (What are the use cases by which we would need to change metadata?)
            Show
            cab938 Christopher Brooks added a comment - Are extensions to the media inspection service to enable modification of metadata reasonable? Initial exploration of this for iteration 3 would be good. (What are the use cases by which we would need to change metadata?)
            cab938 Christopher Brooks made changes -
            Affects Version/s Iteration 2 [ 10010 ]
            Affects Version/s Iteration 3 [ 10020 ]
            ahochman Adam Hochman made changes -
            Parent Issue MH-594 [ MH-594 ] MH-1258 [ MH-1258 ]
            ahochman Adam Hochman made changes -
            Fix Version/s Release 1.0 [ 10030 ]
            Fix Version/s Iteration 3 [ 10020 ]
            Affects Version/s Iteration 3 [ 10020 ]
            ahochman Adam Hochman made changes -
            Parent Issue MH-1258 [ MH-1258 ] MH-458 [ MH-458 ]
            Hide
            abloodworth Allison Bloodworth added a comment -
            I think one of the biggest use cases is that lecture titles will be added later (after the initial scheduling) to a recurring course recording.
            Show
            abloodworth Allison Bloodworth added a comment - I think one of the biggest use cases is that lecture titles will be added later (after the initial scheduling) to a recurring course recording.
            Hide
            cab938 Christopher Brooks added a comment -
            Allison: Is there metadata associated with the recurrence that might be important? e.g. changing a single recording is one thing, but changing a whole series might take a completely different approach technically.
            Show
            cab938 Christopher Brooks added a comment - Allison: Is there metadata associated with the recurrence that might be important? e.g. changing a single recording is one thing, but changing a whole series might take a completely different approach technically.
            Hide
            abloodworth Allison Bloodworth added a comment -
            I think the biggest question is *when* are we talking about making these changes? Is this bug addressing the situation before the recording takes place, or is it also addressing situations where there is "hold" of the media before processing (e.g. so it can be edited). There are different use cases in each of these situations. I think it's very possible that metadata associated with the recurrence could change before the semester starts--it's less likely after the semester begins, but possible. E.g. What if the instructor changes, or the instructor doesn't get the description of the course to the admin before the semester starts?
            Show
            abloodworth Allison Bloodworth added a comment - I think the biggest question is *when* are we talking about making these changes? Is this bug addressing the situation before the recording takes place, or is it also addressing situations where there is "hold" of the media before processing (e.g. so it can be edited). There are different use cases in each of these situations. I think it's very possible that metadata associated with the recurrence could change before the semester starts--it's less likely after the semester begins, but possible. E.g. What if the instructor changes, or the instructor doesn't get the description of the course to the admin before the semester starts?
            Hide
            cab938 Christopher Brooks added a comment -
            Times we may need to change metadata:

            1. Pre-capture
            2. During capture
            3. Post-ingest
            3. Post-processed
            4. Post-distributed

            Right now I think we can fold post-processed and post-distributed together into one category. Pre-capture is "easy" as we can change the data in the scheduler. During capture is hard, because the capture client is the one who has the metadata by now, and changing it on the client isn't really feasible (because of the "broken network" assumption we are taking with the agent). Post-ingest is straight forward, but we require a UI in the job controller/workflow manager to do this.

            MH-1138 seems like it would be related.
            Show
            cab938 Christopher Brooks added a comment - Times we may need to change metadata: 1. Pre-capture 2. During capture 3. Post-ingest 3. Post-processed 4. Post-distributed Right now I think we can fold post-processed and post-distributed together into one category. Pre-capture is "easy" as we can change the data in the scheduler. During capture is hard, because the capture client is the one who has the metadata by now, and changing it on the client isn't really feasible (because of the "broken network" assumption we are taking with the agent). Post-ingest is straight forward, but we require a UI in the job controller/workflow manager to do this. MH-1138 seems like it would be related.
            ahochman Adam Hochman made changes -
            Fix Version/s Release 1.0 [ 10030 ]
            cab938 Christopher Brooks made changes -
            Assignee Ruediger Rolf [ rrolf ] Christopher Brooks [ cab938 ]
            Hide
            oas Olaf A. Schulte added a comment -
            I have additionally assigned Tobias as he should be able to comment better than I could.
            Show
            oas Olaf A. Schulte added a comment - I have additionally assigned Tobias as he should be able to comment better than I could.
            oas Olaf A. Schulte made changes -
            Additional Assignee(s) [abloodworth, oas] [abloodworth, oas, twunden]
            oas Olaf A. Schulte made changes -
            Additional Assignee(s) [abloodworth, oas, twunden] [abloodworth, cedriessen, oas, twunden]
            Hide
            twunden Tobias Wunden added a comment -
            Chris, I agree that we should combine "post-processed" and "post-disributed" into one item. That leaves us (since you said that "pre-capture" is easy with two items, "during capture" and "post-ingest", and I would argue that we should take these as *one* item as well. The reason for this is that there is no handle to the job while it is being captured: it has left the scheduler and is not yet part of the backend's job controller.

            I am in favor of implementing a hold state for review, which will allow to watch a preview encoded version of the recordings (to detect the need for trimming etc.) as well as to edit/enhance metadata and upload attachment such as the presentation in pdf/powerpoint/keynote/...
            Show
            twunden Tobias Wunden added a comment - Chris, I agree that we should combine "post-processed" and "post-disributed" into one item. That leaves us (since you said that "pre-capture" is easy with two items, "during capture" and "post-ingest", and I would argue that we should take these as *one* item as well. The reason for this is that there is no handle to the job while it is being captured: it has left the scheduler and is not yet part of the backend's job controller. I am in favor of implementing a hold state for review, which will allow to watch a preview encoded version of the recordings (to detect the need for trimming etc.) as well as to edit/enhance metadata and upload attachment such as the presentation in pdf/powerpoint/keynote/...
            Hide
            abloodworth Allison Bloodworth added a comment -
            I believe pre-capture is already being handled by the Edit Recordings screen. Ideally, the metadata would be editable during capture, post-ingest and post-processed as well, but since Tobias and Josh said this would be a costly function to add, currently we are OK with it being editable only in the hold state. Later, we can consider adding edit functionality at these other stages.

            Editing post-distribution seems to me to be a separate state that can't be combined with post-processed, as to have any affect it would require that you can redistribute the media with edits, so it is a lot harder. You could more easily edit the metadata post-processing (e.g. when it is in a hold state) and have the new metadata sent to the distribution channel, couldn't you? I think it's still undecided for the project whether any editing post-distribution (with subsequent redistribution) will happen in year one.
            Show
            abloodworth Allison Bloodworth added a comment - I believe pre-capture is already being handled by the Edit Recordings screen. Ideally, the metadata would be editable during capture, post-ingest and post-processed as well, but since Tobias and Josh said this would be a costly function to add, currently we are OK with it being editable only in the hold state. Later, we can consider adding edit functionality at these other stages. Editing post-distribution seems to me to be a separate state that can't be combined with post-processed, as to have any affect it would require that you can redistribute the media with edits, so it is a lot harder. You could more easily edit the metadata post-processing (e.g. when it is in a hold state) and have the new metadata sent to the distribution channel, couldn't you? I think it's still undecided for the project whether any editing post-distribution (with subsequent redistribution) will happen in year one.
            Hide
            abloodworth Allison Bloodworth added a comment -
            Tobias, are we still considering having a hold state *after* processing as well as *before* processing (we'd talked about this so the Admin could review the media that was actually going to each distribution channel)? If so, are there any issues with adding attachments or metadata after processing? We know it may mean that attachments aren't used for media analysis, but we still don't think we should prevent the Admin from uploading them at that time if they need to. We'd also really like them to be able to edit metadata after processing if they need to --are there any similar issue with metadata (e.g. is the lecture title ever encoded into the media or something like that)?
            Show
            abloodworth Allison Bloodworth added a comment - Tobias, are we still considering having a hold state *after* processing as well as *before* processing (we'd talked about this so the Admin could review the media that was actually going to each distribution channel)? If so, are there any issues with adding attachments or metadata after processing? We know it may mean that attachments aren't used for media analysis, but we still don't think we should prevent the Admin from uploading them at that time if they need to. We'd also really like them to be able to edit metadata after processing if they need to --are there any similar issue with metadata (e.g. is the lecture title ever encoded into the media or something like that)?
            abloodworth Allison Bloodworth made changes -
            Additional Assignee(s) [abloodworth, cedriessen, oas, twunden] [abloodworth, cedriessen, judy, oas, twunden]
            Hide
            oas Olaf A. Schulte added a comment -
            Allison, I hope I'm not misinterpreting what you're saying, but it seems to me that there is too much emphasis on pre-distribution editing and too little on post-distribution editing. The litmus test for metadata is when they hit the customer, i.e. after distribution. Names spelled wrong, speakers to be added, titles having changed two minutes before the presentation - things you wouldn't know with the conference program you received two weeks before the conference. That's the main reason here for updating metadata.
            Show
            oas Olaf A. Schulte added a comment - Allison, I hope I'm not misinterpreting what you're saying, but it seems to me that there is too much emphasis on pre-distribution editing and too little on post-distribution editing. The litmus test for metadata is when they hit the customer, i.e. after distribution. Names spelled wrong, speakers to be added, titles having changed two minutes before the presentation - things you wouldn't know with the conference program you received two weeks before the conference. That's the main reason here for updating metadata.
            Hide
            judy Judy Stern added a comment -
            Olaf, you won't get any argument from us ba/ux people that editing of metadata is important post-distribution. We've been arguing that it should be available at *any* time--we've heard of use cases for adding/editing metadata during each phase--but understand there are currently technical limitations that make some difficult.

            Post-distribution metadata editing wouldn't rely on a "hold state" because presumably the workflow is completed by this time (i.e. in her last post Allison was focusing on metadata editing during workflow which is why post-distribution wasn't on her mind.)

            Our designs, however, would handle post-distribution metadata editing without much modification (just add edit links to recordings in "Finished" that have been distributed to channels that allow editing.) Question is what it takes to do it technically? (Tobias?)
            Show
            judy Judy Stern added a comment - Olaf, you won't get any argument from us ba/ux people that editing of metadata is important post-distribution. We've been arguing that it should be available at *any* time--we've heard of use cases for adding/editing metadata during each phase--but understand there are currently technical limitations that make some difficult. Post-distribution metadata editing wouldn't rely on a "hold state" because presumably the workflow is completed by this time (i.e. in her last post Allison was focusing on metadata editing during workflow which is why post-distribution wasn't on her mind.) Our designs, however, would handle post-distribution metadata editing without much modification (just add edit links to recordings in "Finished" that have been distributed to channels that allow editing.) Question is what it takes to do it technically? (Tobias?)
            Hide
            abloodworth Allison Bloodworth added a comment -
            Hi Olaf, I definitely think post-distribution editing would be an important feature for the Admin. It sounds like it might be pretty complicated, though, and Adam has always felt pretty strongly that it should be scoped out for year 1. However, I think this is something that should probably be discussed again in a PO meeting given our shifting priorities.
            Show
            abloodworth Allison Bloodworth added a comment - Hi Olaf, I definitely think post-distribution editing would be an important feature for the Admin. It sounds like it might be pretty complicated, though, and Adam has always felt pretty strongly that it should be scoped out for year 1. However, I think this is something that should probably be discussed again in a PO meeting given our shifting priorities.
            Hide
            judy Judy Stern added a comment -
            Tobias wrote:
            >Chris, I agree that we should combine "post-processed" and "post-disributed" into one item.

            When you say "post-processed", do you mean after the entire workflow completes, i.e. "processing" as you're using the term includes publishing/distribution? I'm assuming you don't mean "pre-distribute" because it was my understanding that we could insert a "hold" operation between any other operations--though in the default workflow we'd probably just want one pre-compose and pre-distribute--and those hold states provide the opportune time for metadata editing. (In later iterations we'd be able to do metadata even during other operations, but there's no mechanism for saving the edits right now.) Please correct me if I'm wrong.

            >I am in favor of implementing a hold state for review which will allow to watch a preview encoded
            >version of the recordings (to detect the need for trimming etc.)
            Seems like this hold state *needs* to be before Compose.

            > as well as to edit/enhance metadata and upload attachment such as the presentation
            but this calls for a 2nd hold state just before publish/distribute (last chance to add that stuff before the public sees it).

            I'm pretty sure the answer is that the default workflow just provides optional hold states in both places (but UI possibly limits what one can do in each hold), but let me know if I'm still misunderstanding.

            (I miss having you here to answer these questions in person!)
            Show
            judy Judy Stern added a comment - Tobias wrote: >Chris, I agree that we should combine "post-processed" and "post-disributed" into one item. When you say "post-processed", do you mean after the entire workflow completes, i.e. "processing" as you're using the term includes publishing/distribution? I'm assuming you don't mean "pre-distribute" because it was my understanding that we could insert a "hold" operation between any other operations--though in the default workflow we'd probably just want one pre-compose and pre-distribute--and those hold states provide the opportune time for metadata editing. (In later iterations we'd be able to do metadata even during other operations, but there's no mechanism for saving the edits right now.) Please correct me if I'm wrong. >I am in favor of implementing a hold state for review which will allow to watch a preview encoded >version of the recordings (to detect the need for trimming etc.) Seems like this hold state *needs* to be before Compose. > as well as to edit/enhance metadata and upload attachment such as the presentation but this calls for a 2nd hold state just before publish/distribute (last chance to add that stuff before the public sees it). I'm pretty sure the answer is that the default workflow just provides optional hold states in both places (but UI possibly limits what one can do in each hold), but let me know if I'm still misunderstanding. (I miss having you here to answer these questions in person!)
            Hide
            cedriessen Christoph E. Driessen added a comment -
            Just to throw something in from the day-to-day work with REPLAY. There is almost daily need to edit metadata after an episode was published to the multimedia portal. With the amount of metadata you gather chances are pretty good to get something wrong here and there. For examples see Olaf's post before.
            Show
            cedriessen Christoph E. Driessen added a comment - Just to throw something in from the day-to-day work with REPLAY. There is almost daily need to edit metadata after an episode was published to the multimedia portal. With the amount of metadata you gather chances are pretty good to get something wrong here and there. For examples see Olaf's post before.
            Hide
            judy Judy Stern added a comment -
            Yep, I'm sure we all have similar stories. The parent story for this card is not about post-distribution metadata editing at all, so, even though Allison points out that Adam said this was out of scope for 1.0, I've created a story card (MH-2781) for this and put it on the product backlog so it gets discussed in PO. Okay? (Olaf, Christoph: feel free to write story cards for functionality you feel is missing!)
            Show
            judy Judy Stern added a comment - Yep, I'm sure we all have similar stories. The parent story for this card is not about post-distribution metadata editing at all, so, even though Allison points out that Adam said this was out of scope for 1.0, I've created a story card ( MH-2781 ) for this and put it on the product backlog so it gets discussed in PO. Okay? (Olaf, Christoph: feel free to write story cards for functionality you feel is missing!)
            Hide
            oas Olaf A. Schulte added a comment -
            Judy, I thought this task was agnostic with respect to the status in the workflow as it included references to post-distribution changes of metadata. However, given it is a sub-task to MH-458 ("hold-status"), it makes sense to single out the way you suggest.
            Show
            oas Olaf A. Schulte added a comment - Judy, I thought this task was agnostic with respect to the status in the workflow as it included references to post-distribution changes of metadata. However, given it is a sub-task to MH-458 ("hold-status"), it makes sense to single out the way you suggest.
            Hide
            judy Judy Stern added a comment -
            Yeah, it's not entirely clear to me, either, when it matters what the parent of a task is and when it doesn't. But I just figure we're better off having a story in jira than not; makes it less easy to ignore.
            Show
            judy Judy Stern added a comment - Yeah, it's not entirely clear to me, either, when it matters what the parent of a task is and when it doesn't. But I just figure we're better off having a story in jira than not; makes it less easy to ignore.
            ahochman Adam Hochman made changes -
            Status Open [ 1 ] Closed [ 6 ]
            Resolution Fixed [ 1 ]
            Hide
            ahochman Adam Hochman added a comment -
            changed me mind. going to keep this around. good requirements discussion.
            Show
            ahochman Adam Hochman added a comment - changed me mind. going to keep this around. good requirements discussion.
            ahochman Adam Hochman made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            ahochman Adam Hochman made changes -
            Comment [ This question resulted in several stories. ]
            ahochman Adam Hochman made changes -
            Link This issue duplicates MH-166 [ MH-166 ]
            ahochman Adam Hochman made changes -
            Status Reopened [ 4 ] Closed [ 6 ]
            Resolution Duplicate [ 3 ]
            ahochman Adam Hochman made changes -
            Workflow jira [ 10636 ] Opencast [ 19883 ]
            greg_logan Greg Logan made changes -
            Workflow Opencast [ 19883 ] Opencast 2 [ 36572 ]
            lkiesow Lars Kiesow made changes -
            Status Closed [ 6 ] Open [ 1 ]
            lkiesow Lars Kiesow made changes -
            Component/s Legacy [ 10630 ]
            Component/s Administrative Tools [ 10040 ]
            Component/s #openquestion [ 10043 ]
            lkiesow Lars Kiesow made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Duplicate [ 3 ] Fixed, no review needed [ 10 ]

              People

              • Assignee:
                cab938 Christopher Brooks
                Reporter:
                cab938 Christopher Brooks
                Additional Assignee(s):
                Allison Bloodworth, Christoph E. Driessen, Judy Stern, Olaf A. Schulte, Tobias Wunden
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 1 day
                  1d
                  Remaining:
                  Remaining Estimate - 1 day
                  1d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified