Re: Proposal for ontology and api structure

Dear Felix,

On Nov 14, 2008, at 1:41 AM, Felix Sasaki wrote:

> Hello Christian, all,
>
> Thank you very much for making us aware of this discussion. I agree  
> that we should try to be compatible as much as possible. Regarding  
> declaring a liaison, from the W3C side there is no problem, as long  
> as we don't have formal requirements on the liaison. Just  
> participate in the discussions on this list. I don't know about the  
> ISO side though.
Officially, W3C and MPEG have a liaison and I think there's no need to  
establish something explicitly. However, I'll clarify this at the next  
meeting in February 2009. On the other hand, MXM WDs are publicly  
available and so reference software will be open source. Current  
discussions are coordinated through so-called Ad-hoc Groups (AhGs)  
which are established in between meetings [1]. For MXM-related issues  
you may join [2].

> Just a few questions below. I have taken a look at
> http://www.chiariglione.org/MPEG/working_documents/mpeg-m/pt2.zip
> which says
> "The APIs are made available to applications by means of MXM  
> Engines. Each Engine (e.g. the MediaFramework Engine) provides  
> access to a single MPEG technology (e.g. video coding) or to a group  
> of MPEG technologies where this is convenient."
> Does this mean that this API focuses on interoperabiltiy of MPEG  
> technologies?
The API itself should be open for other technologies but for the  
reference software we'll use engines that focus on MPEG technologies.  
Basically, we'll reuse existing reference software from the various  
MPEG standards. For example, for creating, editing, accessing video  
metadata the API should be defined in a general way but the  
implementation (i.e., reference software) will be MPEG-based, let's  
say. This does not prevent to use MXM and, thus, the API for something  
else. It's just the current implementation (i.e., reference software)  
will not support this something else.

> Also, in e.g. sec. 6.8 "Video Metadata Engine APIs" I saw a  
> seperation in Video Metadata Creation, Video Metadata Editing, Video  
> Metadata Access and Video Metadata Presentation. Isn't there a lot  
> of overlap to be expected between these? E.g. for editing I need  
> access.
I also though this at the beginning but I think the difference can be  
explained as follows:
  - presentation ... methods to present it to the user
  - access ... parsing and getter methods
  - editing ... setter methods
  - creating ... general methods to create/serialize the whole thing

Thanks.
Best regards,
  -Christian

[1] http://www.chiariglione.org/MPEG/meetings/busan08/busan_ahg.htm
[2] http://lists.uni-klu.ac.at/mailman/listinfo/gen-sys

>
>
> Felix
>
>
> Christian Timmerer (ITEC) さんは書きました:
>>
>> 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
>>>
>>
>

Received on Friday, 14 November 2008 09:44:20 UTC