Re: Identifying vs Describing media URI fragments

On Wed, Sep 24, 2008 at 7:43 PM, Yves Lafon <ylafon@w3.org> wrote:
> On Wed, 24 Sep 2008, Silvia Pfeiffer wrote:
>
>>> Giving a name with a well-defined semantics to an object is always
>>> subjective. Assuming I have specified a temporal fragment of a video, and
>>> I
>>> need to give a name to this fragment: for the machines, both the strings
>>> "id-3454645" and "kiss-scene" are equivalent. In both case, the machine
>>> will
>>> not understand what this fragment is about. Similarly, with only the
>>> fragment identifier, the machine will not know that this fragment points
>>> to
>>> a video encoded in the compression format x, under the resolution y,
>>> content
>>> which is also available on another media server with a different
>>> resolution/encoding, etc. This information is what I consider being part
>>> of
>>> the semantics of the fragment. The questio again is: does this fall into
>>> the
>>> scope of the WG?
>>
>> Again, I do not understand your point. The strings "id-3454645" and
>> "kiss-scene" are just simple identifier of a segment and do not
>> provide any semantics other than the ones that happen in the human
>> mind by reading the name. However, defining a referencing scheme where
>> we can use the name to identify a fragment is a different thing and
>> has nothing to do with semantics. We can still say: this is a URI to
>> the fragment called "id-3454645" or the fragment called "kiss-scene".
>> Just like class attributes of HTML elements bear no semantics, neither
>> do these.
>
> I think Raphael's point is: should the fragment be self-descriptive enough a
> machine can figure out without external context that it is a video fragment.
> (re: [[ for the machines, both the strings "id-3454645" and
>  "kiss-scene" are equivalent. In both case, the machine
>  will not understand what this fragment is about ]] ).


If we only identify that it is a fragment of a *video*, but not what
its semantics are, that comes through the media type of the resource,
right?


> This is especially critical when you want the machine to retrieve only the
> fragment and not the whole resource; as opposed to giving a first class
> identification to fragments (ie: giving them the resource status).

Do you mean that we need to have semantics to identify what segment of
a video we need to retrieve?

The way I envisage the fragment extraction to work is as follows:
* a URI references, say 5.3sec - 20.4sec of videoA
* the server maps 5.3sec-20.4sec to a byte range on videoA on the server
* the server composes a valid video file (potentially with new headers
etc) from the videoA fragment
* the server sends that videoA fragment back to the client and
notifies it that it is providing a fragment and not the full video

If I have misunderstood you, please explain further.

> In the case of fragments, being able to merge the 0-10s fragment to the 10s-
> (end) fragment in a local cache is something desirable, but it is difficult
> to achieve this if fragments are plain resources (unless you have extra
> informations available somewhere about relations between a potentially
> infinite set of resources), but I'm digressing...

Caches are a different matter to servers. While servers know for a
given media type how to map time to byte ranges, a cache may not have
such information and should only deal with byte ranges. This is
particularly true for Web proxies.

In that case, we need a special protocol to deal with this situation.
We had a plan with Ogg resources and temporal hyperlinks, which I can
explain. It would work within the existing Web proxy specifications,
but required some extra HTTP message headers
(http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html#anchor8).
Let's discuss that at some other time. :-)

Cheers,
Silvia.

Received on Wednesday, 24 September 2008 10:39:00 UTC