Re: Review of MFWG use cases and requirements

Hi all,

I agree with Werners and Veroniques comments. Here are some more, mostly
minor ones:

"3.1 Single Media Resource Definition": Media fragments can also be used for
identifying regions of still images, e.g. described in 4.5.3.. Could you
make this explicit in 3.1 too?

In sec. 6.1, you write
"The name dimension cannot be combined with other dimensions for this
version of the media fragments specification. Projection along the other
three dimensions is logically commutative ..."
It seems to me that there are two ways to defind "name":
1) semantics is depending on the underlying source media format (your
definition)
2) "name" is a shortcut for the combination of the other free dimensions,
e.g.
http://www.example.com/example.ogg#track='audio'&t=10s,20s
converted to a shortcut
http://www.example.com/example.ogg#media-frag-name('karl-laughing')
So having not a new dimension "name", but a means to name shortcuts for
combinations of the other free dimensions would be interesting.

very minor: the way you write references is not consistent, sometimes with
"(...)", sometimes without. Some references miss spaces.

A general comment: Your document contains so many details about the actual
media fragments technoloy (e.g. "3.13 fallback ...") that is seems much more
than a requirements document. You have written many parts which fit into the
actual specification / to be completed Recommendation. Maybe to address this
you should write a paragraph at the beginning of both documents describing
their relation.

Also general: really great work.

Felix

2009/9/4 Veronique Malaise <vmalaise@few.vu.nl>

    Dear all,

    I also had a look at the document. I have nothing special to add
content-wise, but I would have a remark about the organization of the
document:

    "This specification provides for a media-format independent, standard
means of addressing media fragments on the Web using Uniform Resource
Identifiers (URI)."
    I would mention here the fact that this document lists use cases that
justify the interest for accessing such media fragments. Otherwise the
mention of the use cases arrives a bit late in the document.
    Generally speaking, an outline of the document could be helpful to
explain how the different topics covered relate to each other, as they are
quite diverse.

    Hope that these comments are not totally useless! Nice set of use cases,
pretty clear and well defined, otherwise.

    Best,
    Véronique


    On Sep 3, 2009, at 4:08 PM, Bailer, Werner wrote:

>     Dear all,
>
>     As stated in Tuesday's telecon I reviewed the MFWG use cases and
requirements WD. Please find below my comments (to be merged with those of
other reviewers).
>
>     - 3.6 Singe fragment: Not sure that the term 'mask' is the best choice
here, e.g. in MPEG-7 mask is used for the opposite, i.e. not a single
segment but a segment composed of several unconnected parts.
>
>     - 4.4 Annotating media fragments: A reference to the MAWG deliverables
could be added here.
>
>     - 6.2.1 temporal dimension: Currently on three frame rates are
supported for frame-precise addressing. Especially given the fact that the
HDTV standards include other frame rates (e.g. 24, 50, 60), which can be
expected to be also increasingly available on the web, it seems useful to
adopt a more generic support for frame-precise addressing (cf. the proposal
to use edit units).
>
>     - 6.3.2 track dimension: The restriction to only a single track seems
to be a problem for some of the intended use cases, e.g. scenario 5 in 4.5.5
mentions that Katrina would like to receive the original audio + the audio
commentary for visually impaired. How would she request the two tracks? A
similar problem is requesting the video stream + the French audio (but not
the English and Spanish audio, and not the Dutch captions).
>
>     - editorial note in 6.2.3 on track names: MAWG discussed about the
support of fragments in the MAWG API in the F2F in June. One result was to
add a property ma:numTracks which then allow to iterate through the tracks
numerically and query language, format, title (if supported) for each track
fragment. This could be used to construct appropriate fragment identifiers.
>
>     - 6.4 semantics, editorial note on reasonably close to requested
segment: Returning something close to the requested fragment to avoid
transcoding seems a good choice for use cases like display, browsing, etc.
However, for the recompositing use cases a precise fragment might be
preferred even if it requires transcoding. It might be an option to include
in the request whether the fragment request is to be interpreted strictly or
not.
>
>     Best regards,
>     Werner
>
>     --------------------------------------------------------------------
>      Werner Bailer
>      Institute of Information Systems
>      JOANNEUM RESEARCH Forschungsgesellschaft mbH
>      Steyrergasse 17, A-8010 Graz, AUSTRIA
>
>      phone:  +43-316-876-1218               mobile: +43-699-1876-1218
>      web:    http://www.joanneum.at/iis        fax: +43-316-876-1191
>      e-mail: mailto:werner.bailer@joanneum.at
>     --------------------------------------------------------------------
>
>