Please Note: You are viewing the non-styled version of our site. Either your browser does not support Cascading Style Sheets (CSS) or it is disabled.

WP5: System specification and platform development

WP5 contains two main activities

System specification and components
Applications and integration

merged to provide a tighter relationship between the general system architecture and its instantiation into the aceMedia research prototypes.

As a result, WP5 has a close relationship with all the other technical workpackages, so there will be continuous interaction with them during all phases in the development of the project.

Objectives

In order to test and demonstrate the functionalities of ACEs and the capabilities of the components developed in the project, two scenarios have been selected to create application frameworks. They are called "frameworks" since they imply more than a single application (the whole ACE chain must be supplied).

These application frameworks are named Personal Content Services (PCS) and Commercial Content Management (CCM). The differentiation between both stems essentially from the content type they manage (personal vs. professional). This distinction influences requirements for creation, delivery and consumption, and as a consequence will be translated to differences in system requirements, therefore providing complementary ways of testing ACE capabilities and performance.

It is clear that the possibilities of using ACEs for multimedia knowledge management are not exhausted with these two scenarios. In particular new environments could be created by selecting and combining features from both, or by adding some new functionalities. However their specification is wide enough as to provide a rich environment into which the objectives of the project can be demonstrated.

In this context, WP5 specific objectives are:

System and architecture specification for the overall aceMedia system, with special work items devoted to network and terminal development.
Specification of the two application frameworks that incorporate the desired user functionality and allow showcasing the technology to be developed in the project .
Integration of the global environment for ACE technology deployment and testing, in two versions.
Implementation of the two application prototypes, developed in two design cycles for continuous feedback to the technical WPs, and prepared for usability testing.

The building of software blocks follows an established component model, and has been designed to be as free as possible from operating system and development language constraints, to ease the job for the development groups contributing components from the different workpackages. A coherent and reliable outcome is ensured by adopting a common environment and by using software repositories with version control and software test suites and metrics.

The core of the workpackage tasks is led by industrial partners: Telefónica I+D (WP leader), Motorola, Philips, Alinari. The proven experience of those companies in product and service creation will ensure the efficiency of the work. However most other partners will also be involved in this WP, since it will work as the integration point of all research efforts. Finally, partners with deep expertise in user requirements gathering will contribute to the specification of the applications.

Innovation

Since WP5 will build the applications by integrating components from the other workpackages, most of the innovation will be fed into it by them. Nevertheless, some specific items will have to be addressed here, starting with the definition of the system architecture, the application scenario and the specification of the application frameworks that, since they are based on the highly innovative ACE concept, will need to include its novel aspects when developing. Also the implementation and deployment of the environment for ACE creation, delivery and consumption needs to be adapted to the ACE structure and behaviour.

With regard to software creation, it builds on state-of-the-art software component models, with the aim of creating an efficient multi-platform developing and testing environment. Due to the distributed nature of the team of developers, standard tools will be used to allow version control, sharing source code repositories and defect and enhancement tracking.

Workplan

The workplan, as mentioned in the previous sections, is based on overlapping two release cycles of each of the application frameworks. It can be summarized with the following picture:

Results

Thanks to the work carried out since the beginning of the project, a number of important items are already available, notable the specification and instantiation of the overall architecture and the integration of the first PCS prototype.

aceMedia architecture

An overall architecture for the aceMedia system has been defined. This consists of a framework on top of which applications are running. The purpose of this aceFramework is to provide a convenient and secure usage of ACEs. For example, an application could use the aceFramework to browse ACEs, to execute an ACE, or to analyze the content inside an ACE using one of the tools provided by the aceFramework. An aceMedia system will then be composed of an instantiation of the aceFramework together with an application (or several) which sits on top of it and provides functionality, either locally to users interacting with the system, or remotely to users (remote only aceFramework).

The following figure shows a high level overview of the components in a single aceMedia-enabled device. The aceFramework must be present on a device to make it aceMedia-enabled. On top of the aceFramework there can be any number of applications using it.

The mission of the aceFramework is to provide a set of standardised services to aceMedia applications, so that developers of those applications have an easy work and the consistency of the interaction is facilitated. To maximise portability (since aceMedia systems must run in a number of devices – PCs, mobile, set top boxes) the current implementation of the aceFramework has been done in Java.

Inside the aceFramework a number of components provide all the functionality; we could make a further logical division attending to the type of service they provide:

Fundamental services (base utilities, needed for any aceMedia system to work) are provided by what we call the acecore subsystem. This is in turn wrapped by an utility layer called aceSDK that provides developers an easy and standard access to its functionality.
Additional services are then provided by independent components called Application Modules (AMs). The use of AMs enables aceMedia systems to be customised by including in them just the functionality needed, and also makes possible to upgrade them.

Application Modules (AMs) are the workhorse of the aceMedia system; they provide services for the benefit of ACEs, other Application Modules or an aceMedia application via the aceManager. These modules can perform tasks, triggered by a user, by the ACEs themselves or by the aceManager.

The AM definition and requirements have logically motivated the need to use an architecture based on software components. These systems are specially suited to solve problems such as the large number of configurations that need to be developed and maintained, life-cycle of components and automated administrations.

In our case to enable the functionality required to AMs we have based their structure (and by extension the whole aceFramework) on the OSGi™ architecture. The OSGi™ specifications define a standardized, component oriented, computing environment for services, in particular network services. Adding an OSGi Service Platform to a networked device (embedded as well as servers), adds the capability to manage the life cycle of the software components in the device. Software components can be installed, updated, or removed on the fly without having to disrupt the operation of the device.

aceMedia AMs are therefore managed as OSGi bundles and have to be registered to be known by the other aceMedia system components.

aceMedia first PCS prototype

Based on an available implementation of the aceFramework, the first PCS prototype was developed and integrated. There exists three different applications in this prototype:

A desktop PC application
A TV (Set top box) application
A mobile terminal application

All these applications use the same underlying aceFramework, thus enabling code and component reuse. A number of AMs developed in other work packages are integrated into the prototypes to provide advanced functionality:

Audiovisual processing and characterisation tasks, grouped in a connected set of tools named as the aceToolbox, which include low-level media descriptor production descriptors such as colour descriptors (histograms, dominant colours), texture descriptors, edge and shape definitions, etc, many of them based on the corresponding MPEG-7 image descriptors. This group also includes the production of image spatial segmentations.
Specialised image understanding tasks, such as high level feature detection (Face Detection and Person Detection), ontology-based image cataloguing (e.g. indoor-outdoor decision), and knowledge-assisted analysis, capable of assigning semantic labels to segmented region images (e.g. sky, sand, beach, for a holiday ontology).
A search and retrieval AM, able to perform both text searches through semantic annotations (with the help of a natural language processing AM capable of extracting and matching concepts from natural language texts) and visual similarity searches, including user relevance feedback for enhanced results.
Content adaptation and personalisation. This includes a cross media engine (based on MPEG-21 DIA concepts able to automatically adapt media formats to terminal, network and user profiles, and personalisation tools such as personal filters to adapt search results to user preferences and profile managers.