W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2009

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

From: Yves Raimond <yves.raimond@gmail.com>
Date: Tue, 27 Jan 2009 15:27:49 +0000
Message-ID: <82593ac00901270727k2464544n6daeecc51ba53857@mail.gmail.com>
To: Michael Hausenblas <michael.hausenblas@deri.org>
Cc: David Singer <singer@apple.com>, Media Fragment <public-media-fragment@w3.org>, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>

On Tue, Jan 27, 2009 at 3:22 PM, Michael Hausenblas
<michael.hausenblas@deri.org> wrote:
>
> Yves,
>
>> The more I think about it, the more I'd think it would make sense to
>> see media fragments as FRBR manifestations. After all, other fragment
>> URIs (RDF and HTML) already work like that. They identify an object
>> within the target document, and not a part of the target document!
>
> Really?
>
> Looking at 3. Fragment Identifiers in [1]:
>
> " The URI specification [URI] notes that the semantics of a fragment
>   identifier (part of a URI after a "#") is a property of the data
>   resulting from a retrieval action, and that the format and
>   interpretation of fragment identifiers is dependent on the media type
>   of the retrieval result.
>
>   For documents labeled as text/html, the fragment identifier
>   designates the correspondingly named element; any element may be
>   named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and
>   MAP elements may be named with a "name" attribute.  This is described
>   in detail in [HTML40] section 12."

Well, yes, that's what I mean - it's an identifier for that element
(in HTML). It is not a list of bytes corresponding to a part of an
html document. And same thing for RDF:
http://moustaki.org/foaf.rdf#moustaki is not the array of byte that
constitutes my description, it is an identifier for myself.

I am not saying it is a universal rule (it is not), it just happens to
be that way in two well-known setup.

Best,
y

>
> Cheers,
>      Michael
>
> [1] http://www.ietf.org/rfc/rfc2854.txt
>
> --
> 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 Raimond <yves.raimond@gmail.com>
>> Date: Tue, 27 Jan 2009 15:19:20 +0000
>> To: Michael Hausenblas <michael.hausenblas@deri.org>
>> Cc: David Singer <singer@apple.com>, Media Fragment
>> <public-media-fragment@w3.org>, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
>> Subject: Re: ISSUE-2: What is the mime type of a media fragment? What is its
>> relation with its parent resource?
>>
>> Hello!
>>
>>> Good point re FRBR. I'd also target FRBR manifestations but I fear we will
>>> need end up with FRBR items.
>>
>> The more I think about it, the more I'd think it would make sense to
>> see media fragments as FRBR manifestations. After all, other fragment
>> URIs (RDF and HTML) already work like that. They identify an object
>> within the target document, and not a part of the target document!
>>
>> Best,
>> y
>>
>>>
>>> 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 Raimond <yves.raimond@gmail.com>
>>>> Date: Tue, 27 Jan 2009 15:10:54 +0000
>>>> To: David Singer <singer@apple.com>
>>>> Cc: Michael Hausenblas <michael.hausenblas@deri.org>, Media Fragment
>>>> <public-media-fragment@w3.org>, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
>>>> Subject: Re: ISSUE-2: What is the mime type of a media fragment? What is its
>>>> relation with its parent resource?
>>>>
>>>> On Tue, Jan 27, 2009 at 2:48 PM, David Singer <singer@apple.com> wrote:
>>>>>
>>>>> At 14:36  +0000 27/01/09, Michael Hausenblas wrote:
>>>>>>
>>>>>> Dave,
>>>>>>
>>>>>>
>>>>>>>  a) the MIME type of the requested fragment is the
>>>>>>>  same as that of the original resource;  yes, that
>>>>>>>  might result in one-frame movies, and so on;
>>>>>>
>>>>>> Sounds good. Didn't think about this one yet. But how do we technically do
>>>>>> this? I fear I don't understand. Could you be more precisely on this
>>>>>> option,
>>>>>> please?
>>>>>>
>>>>>
>>>>> Well, I am trying hard to think of a case *in multimedia* where the
>>>>> statement
>>>>> "the type of a piece of X *cannot* be the same as the type of X"
>>>>> would be true.
>>>>>
>>>>> The obvious problem area is if you select a time-point in a video track of
>>>>> a
>>>>> movie, then a fragment cast as a movie would have zero duration -- it's
>>>>> more
>>>>> sensibly a picture.  Unfortunately, zero duration frames are explicitly
>>>>> forbidden in MP4, 3GP etc. (since they can make the visual display at a
>>>>> given time ambiguous).
>>>>>
>>>>> But this gets semantically tricky if there is sound;  what is the correct
>>>>> representation of a point in time of a sound track?  It's not right to drop
>>>>> it from the fragment (oof, we'd need media-type rules for what types get
>>>>> dropped and what don't).
>>>>>
>>>>> This is steering me towards wondering if a piece of X, in time, necessarily
>>>>> has some extension in time, i.e. a time-point is not a fragment (can you
>>>>> see
>>>>> a zero-width character if you meet one in the street?).
>>>>
>>>> I think that raises lots of really interesting questions, and
>>>> highlight the need for a debate about what a media fragment actually
>>>> is. Is it a bunch of byte (in that case, it makes sense to associate a
>>>> mime-type with it), or is it an identifier for a piece of the content?
>>>> In other words, does it identify a FRBR item, or a FRBR manifestation?
>>>> I would personally go for the latter, which would allow us to use
>>>> media fragments for identifying a particular signal sample, a frame in
>>>> a video, etc.
>>>>
>>>> Best,
>>>> y
>>>>
>>>> --
>>>> Yves Raimond
>>>> BBC Audio & Music interactive
>>>> http://moustaki.org/
>>>
>
Received on Tuesday, 27 January 2009 15:28:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT