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 http://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.