Re: Proposal for ontology and api structure

Hi Felix, all,

Nice progress!

I only have a brief comment on the API example.

I would not attach the API example to the HTML5 video tag. That
assumes that the annotation is associated to a video file or at least
to the video tag in some way. I don't think you can assume that from
the HTML5 standard or from a video file.

Instead, I would define the API based on having a stand-alone
annotation file, maybe a RDF file or something.
And then I would encourage media file formats to encapsulate these
annotation fields directly into the header of the video files and
expose these to the video tag in a standard way. This standard way
could be a javascript API - or maybe preferrably a DOM of its own.

Just my thoughts on this. It is a difficult issue.

Regards,
Silvia.


On Mon, Nov 10, 2008 at 4:29 PM, Felix Sasaki <fsasaki@w3.org> wrote:
>
> Hi all,
>
> I have created a proposal for the structure of the ontology and the API. See
> http://dev.w3.org/cvsweb/~checkout~/2008/video/mediaann/mediaont-api-1.0/mediaont-api-1.0.html?rev=1.9
>
> It would be great to get your feedback on these via mail and / or during
> the next call (agenda to be provided). Some notes before:
>
> - This is only a proposal for the general structure of ontologoy and the
> API, nothing put in stone, and not a lot of material.
>
> - Ontology and API are currently in one draft. The reason is that I
> think we have agreement that there should be a close alignment between
> the two, and having one document was an easy way to achieve this.
>
> - For the timeline, I mainly would like to discuss this before and at
> the f2f in Belgium, especially since Raphael is on holiday until then
> and I know that he already has worked on an ontology, which I think we
> definitely should take into account.
>
> - You might be surprised that the above draft does not contain any
> formal definition in RDF or a different format. That is on purpose: from
> the viewpoint of the API, it is sufficient to have for each property a
> name, an informal description of mappings to existing formats, and the
> related API methods. The draft contains an example for the createDate
> property. For other use cases than the API, we might need a more formal
> description, but I have put the informal one in the center here to see
> if in that way we can gather the attention of the browser vendor community.
>
> - While writing this draft I have not taken the discussion off XMP,
> transmission.cc or comments on the use cases & requirements document
> into account. Again this is on purpose, to be able to focus on the API
> use case - for the time being.
>
> Looking forward for your feedback.
>
> Regards, Felix
>
>
>

Received on Monday, 10 November 2008 06:10:56 UTC