Re: ISSUE-2: What is the mime type of a media fragment? What is its relation with its parent resource?

Yves,

> For me we should stick to fragments only when the returned content would
> have the same mime type as the original, and another URI for a "fragment"
> (in the video/audio/whatever content meaning of "fragment") of the main
> resource in another mime type. In that case, using a Link: header to
> indicate that it is a sub-part of a bigger resource would be the easier
> way of giving the information to the client.

Thanks a lot for your nice rendering, seems sensible to me. Unfortunately
I'm not able to find an indication how that answers my earlier question
(still sort of around; might have been buried under the mail flood today ;)

I'll restate it and would like to ask you to explain me how we gonna handle
this - in case I understand it I offer a bounty (not sure if that has
already been assigned, so ...), that is, to take care of the Test Cases:

" ...
1. We want to specify W3C REC for a *syntax* for URI fragments in order to
address spatio-temporal fragments of media items.

2. In order to become a W3C REC we need to go REC track, including Test
Cases (for CR exit).

3. In order to write Test Cases for our spec, the semantics of the URI
(fragment) addressing a certain media fragment must be defined somewhere
(most likely in natural language, though I would love to do this in, say,
Prolog ;)

I've recently gone through this in RDFa. No fun without the paper trail,
believe me. TAG would most likely tear us apart before we knock on their
door."

Cheers,
      Michael

-- 
Dr. Michael Hausenblas
DERI - Digital Enterprise Research Institute
National University of Ireland, Lower Dangan,
Galway, Ireland, Europe
Tel. +353 91 495730
http://sw-app.org/about.html


> From: Yves Lafon <ylafon@w3.org>
> Date: Tue, 27 Jan 2009 17:44:03 -0500 (EST)
> To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> Cc: Raphaël Troncy <Raphael.Troncy@cwi.nl>, Media Fragment
> <public-media-fragment@w3.org>
> Subject: Re: ISSUE-2: What is the mime type of a media fragment? What is its
> relation with its parent resource?
> Resent-From: <public-media-fragment@w3.org>
> Resent-Date: Tue, 27 Jan 2009 22:44:13 +0000
> 
> 
> On Tue, 27 Jan 2009, Silvia Pfeiffer wrote:
> 
>> 
>> On Tue, Jan 27, 2009 at 11:26 PM, Raphaël Troncy <Raphael.Troncy@cwi.nl>
>> wrote:
>>> 
>>> ISSUE-2: What is the mime type of a media fragment? What is its relation
>>> with its parent resource?
>>> 
>>> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/2
>>> Raised by: Raphël Troncy
>>> 
>>> Related to a discussion started by Guillaume [1].
>>> 
>>> A media fragment URI can be used for addressing, for example, a particular
>>> audio track of a mkv movie, or a particular key-frame of a video. What is
>>> the resulting mime type of the secondary resource specified by the fragment
>>> (audio, thumbnail, text)? Should we specify it in the recommendation?
>>> What RFC3986 does say about the mime type of a fragment [2]?
>> 
>> The mime type is information that is provided by the server through
>> http to the client. It relates to a resource. I wonder what happens if
>> we specify a jpg thumbnail extract from a video through a fragment
>> identifier ... since a fragment only identifies a subresource and not
>> a new resource, we may not be able to do so. Yves, what do you think?
> 
> The issue is not as simple as it look. First a URI can have multiple
> representations using different mime types (see Vary: in HTTP), of course
> you may have a Content-Location to indicate a URI to access directly this
> representation, it is not always sent, or even not always doable.
> 
> Also a fragment is computed relatively to the representation of the
> resource, so according to its mime type, so obviously in that case,
> sending only the fragment with a new mime type blurs the boundaries
> between regular content-negotiation (see above), and fragment processing.
> So the client have no way of figuring out which case is the right one.
> 
> For me we should stick to fragments only when the returned content would
> have the same mime type as the original, and another URI for a "fragment"
> (in the video/audio/whatever content meaning of "fragment") of the main
> resource in another mime type. In that case, using a Link: header to
> indicate that it is a sub-part of a bigger resource would be the easier
> way of giving the information to the client.
> 
>> 
>>> Side issue: in case we create a new resource (i.e. using the query '?'
>>> parameter instead of the fragment '#' parameter), how do we make explicit
>>> the relationship with the parent resource it was extracted from?
>> 
>> By leaving out the query part, we arrive at the parent resource.
>> Specifying the parent resource should not be a problem for either
>> query or fragment, I would say.
>> 
> It can be a uery or a / or whatever you want, having a template for doing
> this would be useful to deploy thing, but not more than that.
> 
>> 
>>> Do we use Link: rel="part_of" <video_uri> as suggested by Yves [3]?
>> 
>> I am not even sure we want to do these kind of URIs:
>> http://www.annodex.net/cmmlwiki/OSSForum-Trailer.png?t=0:02:10
>> 
>> They should really be something more like:
>> http://www.annodex.net/cmmlwiki/OSSForum-Trailer.anx?t=0:02:10&type=image/png
>> 
>> What do people think?
>> 
>> Cheers,
>> Silvia.
>> 
> 
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
> 
>          ~~Yves
>

Received on Tuesday, 27 January 2009 23:23:02 UTC