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: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 28 Jan 2009 09:50:47 +1100
Message-ID: <2c0e02830901271450q69d6f1dp71d99410c05f4808@mail.gmail.com>
To: Yves Raimond <yves.raimond@gmail.com>
Cc: Michael Hausenblas <michael.hausenblas@deri.org>, David Singer <singer@apple.com>, Media Fragment <public-media-fragment@w3.org>, RaphaŽl Troncy <Raphael.Troncy@cwi.nl>

Could sombeody explain what FRBR is?
Sorry if it's obvious to everybody else.
Thanks,
Silvia.

On Wed, Jan 28, 2009 at 2:19 AM, Yves Raimond <yves.raimond@gmail.com> wrote:
>
> 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 22:51:24 GMT

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