Implementation report for the API for Media Resources 1.0

Table of contents

1 Summary

This document reports the interoperability test results for multiple implementations of features of the API for Media Resources 1.0 specification and is maintained by the Media Annotations Working Group.

The purpose of the implementation report is to document that at least two independent implementers can independently read the same specification and produce two independent interoperable implementations for a given feature. This tests both the clarity of the specification, in that the specification language must be clear enough to sufficiently describe an interoperable implementation, as well as the implementability of the specification itself. This implementation test report is not meant to test conformance of any given API for Media Resources 1.0 implementation.

Implementations tested

• Implementation 1: Linked Media Framework of Salzburg Research Forschungsgesellschaft m.b.H.
  The Linked Media Framework (LMF) is a general purpose framework for building Linked Data and Semantic Web applications. It provides commonly used services linked Linked Data Server, Linked Data Client, SPARQL Endpoint, Semantic Search, Rule-based Reasoner, Versioning, etc. that can be used for building custom Semantic Web applications using e.g. the LMF Client Libraries available on the project website. The Media-Module builds upon the LMF and provides special services for images and videos (e.g., fragmentation, metadata extraction, etc.).
• Implementation 2: Firefox extension of University of Passau and JOANNEUM RESEARCH
  This showcase utilizes the API in a browser extension following the asynchronous mode of operation. The application enables a user to generate a video playlist, where videos and corresponding metadata informations from different platforms can be arranged in an unified way. As a proof of concept, the browser extension is able to handle YouTube and Vimeo videos.
• Implementation 3: Web service implementation of University of Passau and JOANNEUM RESEARCH
  This implementation is integrated into an image gallery showing images as well as its metadata information. Here, the API is implemented as a Web service following the synchronous mode of operations abstracting from the actual underlying metadata formats. As a proof of concept, Dublin Core and MPEG-7 are used.

Note:

a) Availability of the code:
All implementations are open source projects. Linked Media Framework (LMF) is hosted at Github, the browser extension can be downloaded at the prototype page (the dpi includes the source files and can be extracted similar to a ZIP file). The third implementation (web service) can be downloaded at source forge.

b) Usage of the API
Two papers explain the implementations and  provide details for the browser extension and the server side implementation. The code pieces of the API will soon be available in the LMF branch at Github (maybe with the next major release). Currently it can be found here: https://svn.salzburgresearch.at/svn/lmf-media/ This project needs the complete LMF as dependency. That´s why it seems to be a little bit "tiny".

2 Results of the implementation report

The Implementation results are publicly released and are intended solely to be used as a proof of API for Media Resources 1.0 specification implementability. It is only a snap shot of the actual implementation behaviors at one moment of time, as these implementations may not be immediately available to the public. The interoperability data is not intended to be used for assessing or grading the performance of any individual implementation. Any feedback on implementation and use of this specification would be very welcome. To the extent possible, please provide a separate email message for each distinct comment.

The test cases are devided into two groups: test cases independent of metadata formats (see Section 4.1) and test cases, that need format specific information to be conducted (see Section 4.2 & 4.3). In terms of the metadata format specific test cases, every property has to be listed in two instantiations (core attributes vs. specific attributes). Here, an implementation has to at least behave correct for the core properties (specific properties are optional).

Results are "passed","failed", "not supported" (not executed) or "not tested".

All tests have fulfill the exit criteria of the API for Media Resources 1.0 CR version. Each test has at least two passing implementations which have been developed independently.

Comments on this document should be sent to public-media-annotation@w3.org. The archive of public comments is available at https://lists.w3.org/Archives/Public/public-media-annotation/.

3. Formats in scope

The following tables lists the formats that were selected as in-scope. We distinguish multimedia metadata formats that focus on the description of multimedia resources from multimedia container formats. In the case of the latter, only few technical properties are relevant, because of they widespread usage.

The API for Media Resources 1.0 specification defines a specific JSON response structure, to which a implementation has to be compliant. To enable an (automatic) evaluation, a normative JSON response for a example media resource for each metadata format has been created covering all properties defined in the corresponding mapping table. These files are available in Section 3.1 & 3.2.

Note: The example media resources have been taken from the in the Ontology for Media Resource 1.0 test suite. The normative JSON responses provided in sections 3.1 & 3.2 only consider the properties that have a corresponding property in the core vocabulary defined in the Ontology for Media Resource 1.0. An example for a response for a property wihout a corresponding partner in the core vocabulary can be found in the atomic examples, e.g., Y3-a in section 5.2.

Note: The example media resources have been taken from the Ontology for Media Resource 1.0 test suite.

3.1 Multimedia metadata formats in scope

3.2 Multimedia container formats

4 General behaviour tests

For some of the general behaviour test cases no input data can be given. For this test cases, only a valid JSON response shall be produced.