Graphic Interfaces and Operational Prototype: Summary
This page summarises the public deliverable “D7.3 Graphic interfaces and operational prototype,” which describes the first operational prototype of the MULTISENSOR platform.
The report presents the initial technical scaffolding of the system: a rough user interface, dummy implementations of the main services, the first prototype applications, the code organisation, and the infrastructure used to host the platform. Its purpose was not to present the final system, but to document the first working prototype on which later development would be built.
What the Report Covers
The deliverable provides a technical overview of the first operational prototype, including:
- the high-level prototype architecture
- the supervisor, crawler, and content extraction pipeline
- the Central News Repository and OPS Repository
- prototype applications for UC1 and UC3
- code organisation and packaging
- hosting infrastructure and demonstrator access information
The report describes this prototype as a “walking skeleton” for the future platform: a first proof of concept with dummy services and workflows that could later be replaced with full implementations.
Main Purpose of the Prototype
The operational prototype was designed to validate the overall system design at an early stage. Rather than providing full production functionality, it established the basic architecture and interaction patterns needed for iterative development. The report states that the prototype included a first rough UI and dummy implementations of the major services, processes, and workflows.
Prototype Architecture
The document explains that the MULTISENSOR architecture followed a service-oriented approach with two broad modalities: offline asynchronous processing of harvested data, and synchronous retrieval and delivery of analysed data to the end-user applications. For this first prototype, the core components were present as dummies or proof-of-concept implementations.
Supervisor
The Supervisor was designed as an always-running Node.js process. In the prototype it had three main jobs: triggering the crawler periodically, initiating the content extraction pipeline on demand, and hosting a bootstrap service for shared platform configuration. At this stage the crawler was configured to run every 30 minutes.
Crawler
The prototype included an initial crawler implementation that fetched news items from sources and stored them in the Central News Repository. The crawler was implemented in Node.js and controlled by the Supervisor. For the prototype, crawling was sequential and synchronous for simplicity, with the expectation of more parallelism later.
Content Extraction Pipeline
The Content Extraction Pipeline was represented by dummy analytical services used for dry runs of the process. Items could be selected from the Central News Repository and streamed through the pipeline, with data exchanged via a shared JSON-based object until the final result was stored in the OPS Repository. The analytical services were Jersey-based REST services deployed under Jetty.
Repositories
The report describes two main repositories. The Central News Repository stored raw crawled content and supported search for the applications; as of August 2014 it held around 8 million articles in ElasticSearch. The OPS Repository stored the output of the content extraction pipeline and was implemented with MongoDB, chosen as a suitable NoSQL solution for loosely structured analytical data.
Prototype Applications
The report says the first operational prototype was demonstrated through two use cases: UC1 Journalism and UC3 SME internationalisation. UC2 media monitoring was not separately implemented at this stage because, from an implementation point of view, it was considered very similar to UC1.
UC1: Journalism
The journalism prototype was built around topic-based search over the Central News Repository. It included a landing page with auto-completion, a main search page with filters, compact and detail views, and support for summaries, social information, sentiment, entities, and translations. It also included a “My Findings” dossier for collecting relevant items during analysis. The application was built as a Node.js web application using the Locomotive MVC framework, with HTML5 and Bootstrap for the interface.
UC3: SME Internationalisation
The SME internationalisation prototype began with a map-based interface where users could select a country, sector, and product. It included pages for economy and politics, comparative country assessment, sector information, and product information. The report describes a decision-support dashboard comparing countries across cultural, economic, political, and demographic dimensions, plus sector- and product-related news, sentiment, and summary views. Some of these outputs were still dummy-generated in the first prototype.
Infrastructure
The prototype ran on a small cloud-based infrastructure. The main server, msinfra1, hosted most of the initial setup. A second machine, mscrawler1, was dedicated to the Yahoo! crawler based on Hadoop, Nutch, and HBase, though it had not yet been fully integrated into the platform. A larger server, msgrinder1, had already been commissioned and was intended to host extraction services and repositories progressively; at the time it was already being used to run WP6 summarisation algorithms.
Why This Deliverable Matters
This report matters because it shows how a research platform moved from architecture diagrams and requirements into a first working technical prototype. It captures the early integration logic of the project: crawled content, extraction services, repositories, search, and user-facing demonstrators all connected into one initial system.
For readers interested in multimodal AI, content extraction, search architecture, media analysis, and prototype system design, the deliverable provides a useful example of how a complex platform can be assembled incrementally rather than built as one monolithic release.
Key Takeaway
The main takeaway is that the first operational prototype was designed as a functional scaffold, not a finished product. Its value lay in validating the architecture, interface concepts, workflows, and infrastructure needed for later development of the full system.