Re: Review of use cases and requirements

Hi Jack,

On Wed, Nov 12, 2008 at 9:04 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>
> Here's my review of
> http://www.w3.org/2008/WebVideo/Fragments/wiki/Use_Cases_%26_Requirements_Draft,
> dated November 8.
>
> Browsing media:
> Scenario 1: I think a logical pagination here would make a more powerful
> example, so could "20 minutes" be replaced by something like topics?

By what logic would you replace the temporal segmentation? Not every
video has topics or is annotated with topcis based on which the video
can be rearranged. I only assumed a long video with no given structure
here. I have seen videos that are 8 hours long and that people want to
simply page through to get a quick overview of. That's what this use
case is about. E.g. http://www.metavid.org/ works like this.

The use case of jumping to topics is however a very strong one for the
search use case in my opinion. If I were looking for specific topics
in a long video, I'd go search annotated clips for that topic
relationship and have them all on one page as search results rather
than tabbing through the playing video. But we could add another
scenario for this, if you prefer.


> Scenario 2: again, logical splitting may be more powerful. Daisy books, for
> example, allow jumping by chapter, section, paragraph, sentence.

Scenario 2 implies a logical splitting. I said "blocks" to leave it
open. This could be captions, audio annotations, or anything else such
as chapters. We can probably make this more explicit.


> Recompositing media fragments:
> This section I have the most problems with. For all of these I would *not*
> use url fragments, but in stead use SMIL (also for scenario 1 and 4: SMIL
> tiny was done specifically for playlists).

Notice how I suggested SMIL tiny as an example playlist format?

However, inside the playlist, you will still need to refer to the
media fragments, right? So, the use of media fragment URIs together
with a defined means of how to request and receive the fragments from
a server would be the best way, right?

Correct me if I'm wrong, but the way in which I understand SMIL is
that it has a means to address media fragments, but there is no
defined retrieval mechanism behind it, which in the case of
network-located media must current mean a retrieval of the full
resource and then a local offsetting.

For that reason, I can see SMIL as being one option (depending on what
complex compositions you want to achieve possibly even the only
option) towards specifying recomposed media, however I would suggest
it to use media fragment URIs to address the fragments.

> There's little added value in
> using url fragments here: the UA will have to implement (part of) the work
> anyway, so I see little advantage in specifying
>    < video src="http://example.com/myvideo.ogg#t=20-30"/>
> over
>    <video src="http://example.com/myvideo.ogg" clipBegin="20" clipEnd="30"/>
> Same for spatial clipping.

The main advantage that I see is really that in the first version it
is clearly defined that only the fragment is retrieved from the
server, while this is undefined in the second case.


> As to the specific question in scenario 2: I don't know of any
> implementation of SMIL as a background image.

Actually, that question was wrongly posed. The question should have
been: can SMIL create an image from a collection of image fragments?
If yes, then it totally fits that use case.

Feel free to make up better use cases here, please.


> Technology requirements, Media Accessibility
> Should we add a use case for a search engine robot here?

Accessibility is in particular for deaf and blind people of varying degrees.

However, I can see where the idea of making text representations
available to search engines comes from. Is it a use case for media
fragment URIs though?


Thanks for the review!! Awesome feedback!

Cheers,
Silvia.

Received on Wednesday, 12 November 2008 12:13:40 UTC