Re: [W3C Media Annotation WG] Request for Expert Review

Dear Soohong, all,

I have reviewed the two documents and have a lot of feedback.

I will provide separate feedback on the Ontology to the API, since
otherwise the emails will get too long.

So, this is the first email with feedback on the Ontology. See below.

On Tue, Mar 16, 2010 at 3:17 PM, Soohong Daniel Park
<soohong.park@samsung.com> wrote:
> Hello Silvia
>
> Now, MAWG ready for LC process on both WG documents.
>
> Before LC, we’d like to have more valuable feedbacks from you in order to
> increase the quality of documents.
>
> Can you accept our *request for expert review* ? Please do let chairs know
> your opinion.
>
> All of your comments are highly welcome to Media Annotation WG.
>
> Thanks in advance.
>
> Soohong Daniel Park & Joakim Soderberg
>
> Chairs, Media Annotation WG
>
> ==============================================
>
> [1]
>
> Ontology for Media Resource 1.0 [Version 09 March 2010]
>
> http://www.w3.org/TR/2010/WD-mediaont-10-20100309/
>
> Abstract: This document defines the Ontology for Media Resource 1.0, a core
> vocabulary to describe media resources on the Web. It is defined based on a
> core set of properties which covers basic metadata to describe media
> resources. Further it defines syntactic and semantic level mappings between
> elements from existing formats. The ontology is supposed to foster the
> interoperability among various kinds of metadata formats currently used to
> describe media resources on the Web.



FEEDBACK ON THE ONTOLOGY:

I have read the documents mainly with a HTML5 background. I am
considering what it would mean to introduce the Ontology and its API
into the HTML5 specification and how it would work.

At the same time, I have looked at the specification from an Ogg
point-of-view, which seems to be something that is missing from your
efforts. MPEG files are somewhat covered with ID3, quicktime and
iTunes (not sure what the standard is now for MPEG-4 metadata).

Generally, the list of properties seems sensible and relates a lot to
existing formats with the exception of the media fragments part. I do
wonder how the uptake of that interface will be since there are no
containers that support such specifications right now. I would expect
media fragments to be more intrinsic to the media than to just be
metadata, so that part is probably not very useful. But it might have
a completely different effect in making people more aware of the Media
Fragment specification.

I have several questions about properties, in particular ones that
seem duplicated:

1. ma:identifier and ma:locator

It seems to me that these always contain identical information. Your
examples in the API document indicate this, too. So, it might make
sense to remove ma:identifier or retarget it towards giving it
something more like a XML ID field than a URL. At minimum, your
example in the API doc should be an example for when the value for
these two fields is different.

2. ma:compression and ma:format

I believe the ma:compression field is surplus. The ma:format field
already provides for specifying the codecs used in a media resource.
It would not be necessary to duplicate this information in the
ma:compression field.

3. ma:numTracks

It is unclear what this field refers to. The name "track" is vastly
overloaded in digital media. The different songs on a CD are called
tracks. The different multiplexed parallel data streams inside a media
resource are called tracks. This has to be clarified. Note that it is
possible to encode all the tracks of a CD in a single file and thus it
could make sense to expose this information in an API. It might make
sense to add a "type" field to the API there and allow both types of
"tracks".

4. Fields

I checked your list of possible additional elements in comparison with
what is available for Ogg through Vorbiscomment or Skeleton and these
are some that you don't seem to have considered yet:

* CONTACT - contact information for the creators or distributors of
the data; could be a URL, email address, or physical address
* ENCODER - information about the encoding software of the metadata


5. I would propose to add a table for a Ogg Metadata mapping. This
relates to tracks inside an Ogg file, which usually have a
vorbiscomment header and a skeleton header. All of the metadata that
is stored in Ogg files in this way is provided as name-value pairs -
there is no particular external file format for it, but a simple list
of name-value pairs will provide sufficient such information.

Attached is my mapping table for Ogg Metadata with the hope that it will help.


Best Regards,
Silvia.