Re: Proposal for ontology and api structure

Dear Felix, all,
   sorry for late reply and I'd like to draw your attention to the  
MPEG Extensible Middleware (MXM) which aims to define APIs enabling  
applications to access standard multimedia technologies (including  
metadata). Note that within this standard we will also produce  
reference software which will be available under an open source  
license. Requirements, working drafts, and a proposal for the MXM  
public license is publicly available under [1].

You may find some parts thereof interesting, especially the APIs  
related to metadata for image, audio, video, and content in general.  
We may also collaborate (e.g., via liaisons) in order to stay  
compatible the one way or the other.

Thank you.
Best regards,
  -Christian

[1] http://www.chiariglione.org/MPEG/working_documents.htm#MPEG-M

On Nov 10, 2008, at 6:29 AM, Felix Sasaki 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
>