Re: Identifying vs Describing media URI fragments

Hi Jack, all,

On Tue, Sep 30, 2008 at 10:34 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>
> Would it be a good idea if we separate two issues: the functionality we want
> from media fragments and the external representation of that functionality?

I agree. At this stage we want requirements.

I was trying to make a case for requiring a mechanism to link to named
fragments in addition to temporally and spatially represented ones.
The name would just be a random string that stands for a time
interval, a spatial area, or a spatial area over a time interval. It's
like defining a hot spot in a video that will be related to
frequently, so giving it a name will be easier (just like tinyurls are
easier).


> This way, we could first decide on a list of the things we would like our
> eventual solution to be able to do without worrying about whether this can
> be done through HTTP headers already or needs URL adornment or so. We could
> then also investigate what existing technology already handles that
> functionality, and how.
>
> The functionality wanted already poses a number of questions:
> - Do we want to select only continuous sections or allow discontinuous
> selection too?

In the temporal URI specification we did both - it seemed to make
sense to be able to put a kind of selective view onto a video and take
multiple parts together to create a new resource. However, since we
have implemented Annodex and temporal URIs, we never had a case where
we actually used complex multi-fragment URIs. Do we have a really
compelling use case for multi-fragment URIs over just individual
fragments? In our experience you can always concatenate multiple
single-fragment URIs to create a multi-fragment presentation.

Don't get me wrong with this argument though: I'm not saying that we
should not regard multi-fragment URIs. I am just saying that when we
get around to the specification, this is a nice-to-have requirement,
but not a absolute necessity and if it complicates things overly, we
should consider dropping it.

> - Do we want only temporal selection or also spatial?
>  - If we want spatial too, only rectangular or do we want free shapes?
>  - If we want spatial, are the coordinates static over time?
>  - How about discontinuous spatial selections?

Spatial is already part of the Working Group mandate. Spatial for
images is a mandate now, whereas spatial for video is part of the
second phase.

We want free shapes, I would think - similar to image maps. It allows
to mark a specific object in an image and make it addressable. For
example: the image of a tiger that is included in this slide...

Also, we would want dynamic free shapes over time I would think. This
allows to mark a specific moving object in a video and make it
addressable. For example: the car that is driving in this scene...

> - Do we want selection of substreams?

I think we may want that, too. At least that's what the Video UC is
describing. We may want to ask the server to get the video track and
the caption track from a certain video resource and ignore all other
tracks (in particular sound tracks). Do we want to regard this as a
media fragment?

> - Do we want only out-of-context selection (crop) or also in-context (in-point/out-point)?

It's a good question to ask. I think we have to have in-context as a
fallback to formats that do not allow easy cropping. However, if I am
after the last 30sec of a video that is 3 hours long, would I really
prefer downloading the full video and watch the last 30sec after an
extensive wait and a lot of bandwidth wasted over a simple 404?


>  - If we also want in-context selection, does this mean we want optional
> client-side selection too?

Good question. With Annodex we had both: queries and fragments that
should both enable server-side selection and client-side selection. In
practical use we didn't need client-side selection. However, this is
just one example - there may be real use-cases for client-side
selection...


> These are just a couple of design choices I can think of while typing this
> message, there's probably heaps more if we really think about the issues.

They're awesome and should be added to the requirements.

Cheers,
Silvia.

Received on Monday, 6 October 2008 10:44:12 UTC