NewsDesk;Bringing Maps to Grassroots Journalism

Hakon Arneng HolmstedtHøgskolen i Østfold

Digital MapsHalden

May 19, 2005

Abstract

The NewsDesk project is an attempt to facilitate the use of geo-data in

Grassroots Journalism, a burgeoning field where everybody can have a go at

being a journalist. It presents a design for a go-between application between

an assumed mobile application that records sounds, images, and text, and

any number of online publishers. It uses a variation of the well known MMS-

protocol and standard Internet connections for mobile communication. This

makes multimedia messaging quick and cheap. Application level communi-

cation is performed through the XML-standard SOAP, where system calls

can be encapsulated in cross-platform, cross-language messages. The project

presents a static prototype as proof of concept, and suggests future work.

Keywords: Mobile technology, SMIL, AMMS, SOAP, cellular phones, Grass-

roots Journalism, Citizen Journalism, Java, Servlet, J2EE, SAAJ

Contents

1 Introduction 3

1.1 Grassroots Journalism . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Mobile Technology . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1 On the Spot Reporting . . . . . . . . . . . . . . . . . . 7

1.4.2 Simple Editing . . . . . . . . . . . . . . . . . . . . . . 7

1.4.3 Public Commentary . . . . . . . . . . . . . . . . . . . 7

1.4.4 Rare Insights . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.5 Local knowledge . . . . . . . . . . . . . . . . . . . . . 8

1.5 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Approach and Methodology 10

2.1 Object Orientation . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Component Based Software Development . . . . . . . . . . . . 11

2.3 Programming Approach . . . . . . . . . . . . . . . . . . . . . 11

3 The System 12

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1 Functional Requirements . . . . . . . . . . . . . . . . . 13

3.1.2 Future Functionality . . . . . . . . . . . . . . . . . . . 13

3.2 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3 System Task and Architectural Overview . . . . . . . . . . . . 15

3.3.1 System Task . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.2 Architectural Overview . . . . . . . . . . . . . . . . . . 16

1

3.4 Minimal Implementation . . . . . . . . . . . . . . . . . . . . . 17

3.5 The Repository . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.6 AMMSListener . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6.1 Module Architecture . . . . . . . . . . . . . . . . . . . 23

3.7 Editor’s Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.7.1 Module Architecture . . . . . . . . . . . . . . . . . . . 25

3.8 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.9 The Syndicaters . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.10 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.10.1 Service Requests . . . . . . . . . . . . . . . . . . . . . 28

3.10.2 Service Replies . . . . . . . . . . . . . . . . . . . . . . 29

3.11 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Results and Conclusion 34

4.1 Prototype Two . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Design Improvments . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.1 Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.2 New Services . . . . . . . . . . . . . . . . . . . . . . . 36

4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2

Chapter 1

Introduction

The NewsDesk project is an attempt to facilitate the use of geodata in Grass-

roots Journalism (see 1.1). It will do this by presenting persistent storage

for geo-annotated articles written with geo-aware cell-phones, i.e. those with

integrated GPS1 or with some sort of GPS-connection, like a GPS-device con-

nected to the telephone through Bluetooth. It will also present an interface

for browsing and editing these articles.

The project should bridge the gap between geography and Grassroots

Journalism.

First, though, I will outline the three major topics that are brought

together in this project, Grassroots Journalism, Digital Maps, and Mobile

Technology, and then show some possible uses for the NewsDesk.

1.1 Grassroots Journalism

Today, Big Media2 is experiencing so-called audience disaggregation [1]. This

means that the audience is getting hungry for more specialized content. They

1A GPS device, or Global Positioning System device, is a tool for determining one’sexact position on the planet. It uses a number of satellites to triangulate the device’sposition, and this information is presented by the GPS in a way that many other unitscan intercept and understand.

2Big Media is a term signifying the major players in the field. I have not been able toascertain who coined the term, or when it was coined, but it has become an importantlabel in the ongoing media-debate.

3

want to hear about what is going on in their particular fields of interest,

and are less willing to pay for generic news. The result is that online news

publications have a hard time creating profits and are currently only seeing

minor gains from selling advertisements. On the other hand, niche journals

are experiencing steady gains. These are journals that focus on small topics

and cover those in great detail. However, since such journals necessarily have

a small number of readers, it can be unprofitable to produce the news-articles.

This is where grassroots journalism comes in.

Grassroots journalism is an exploding subculture where normal people

like you and I take on the burdens of the journalist and produce news articles

about what is happening in our personal sphere of interest. By publishing ar-

ticles on the Internet, on so-called blogs, these everyday journalists can reach

an audience all over the globe. With the advent of technologies designed to

be easy to use, available for free, and geared towards fast publication on the

Internet, we have seen a growth in Internet communities focusing on the dis-

semination of news. Entire online newspapers written by non-professionals,

but of high quality, have cropped up and are challenging the hegemony of Big

Media. It has also garnered quite a bit of academic interest [2]. Backed by

professional journalists like Dan Gillmor[3] and Steve Outing[4], this trend is

beginning to shape the way we think about news. The Korean online news-

paper OhMyNews[5] is an example of how regular citizens like you and I

have created a free, online newspaper of high quality and even some political

influence.

The rise of the Citizen Journalist has uncovered a lack of attention to-

wards an important field, that of Geographic Information Systems. While

the Grassroots Journalist is more than capable of producing insights into

any an all subjects and reporting from remote and obscure locations, they

have so far failed miserably at attaching any geographic significance to their

work. To put it bluntly, they do not use maps. This project is an attempt

to bridge the gap between Geographic Information Systems and Grassroots

Journalism.

As grassroots journalism has grown, new roles form. One such role is the

citizen media editor. Glaser[6] points out that this role is currently undefined.

4

Some editors are glorified chat-moderators while others have nearly the same

role of a traditional editor. In this project, I have assumed that the editor is

someone responsible for proof-reading, fact-checking, and general editing of

news items. That is, the citizen media editor is something beyond the chat-

moderator, but not necessarily a full blown news editor. For the NewsDesk,

this means that the editor should have read and write access to articles and

some tool to perform these actions.

1.2 Maps

In traditional news coverage, maps have become ubiquitous. It is nearly

impossible to watch a news-show without references to at least one map. It

can be something simple like an overview of a particular area of the world to

show the location of a nation, or something more detailed like a map showing

chemical spillage. Even if the news-show itself does not use maps, the weather

forecast is based completely around the map. Today it has become common

for weather forecasts to have satellite images showing storm fronts and the

like, and more stylized maps for the detailed forecast. Maps are everywhere

in newscasting.

Citizen Journalism has suffered from not using maps in the same way. In

fact, Dan Gillmor himself commented recently that this field seems to have

forgotten maps altogether [7]. When grassroots journalists fail to include

maps they deprive their readers of a source of understanding. This lessens

the value of their writing and relegates grassroots journalism to a secondary

position in relation to traditional media, however,there exists technology that

can change all this.

A Web Map Service (WMS) is a web based service that provides insight

into the vast databases of geographic data via maps. Many WMSs are free

of charge. By allowing the general public to access the enormous amounts

of geodata gathered, WMSs represent a free and dynamic way for Grass-

roots Editors to create beutiful and informational maps to accompany their

articles.

5

1.3 Mobile Technology

In the area of mobile technology, great strides are being made every day. In

fact, by the end of 2005 there will be over two billion mobile phone subscrip-

tions worldwide [8]. In several parts of the world, the market has reached

more than 100% penetration, meaning that there are more than one cell-

phone per person. Clearly, the mobile phone has become ubiquitous in the

industrialized world.

As mobile phones find their way into everybody’s pockets, so do various

technologies find their way onto our cell-phones. Today you’ll be hard pressed

to find a phone that is not also a camera, a recorder, an e-mail client, a web-

browser, and general purpose personal assistant. Although such technological

convergence offers many challenges, especially as the growing complexity of

the devices surpasses the consumer’s will to put in the effort to use the device

[8], developers keep adding functionality to their products. Soon it will be

common for mobile phones to come equipped with GPSs.

This means that the current standard of mobile technology allows a per-

son to act as an entire news-van if he should so desire. A top of the line

cell-phone provides the would-be journalist with opportunities for recording

short videos, taking pictures, writing texts, recording sounds, and sending

all of this to the news-desk or another interested party. No longer does one

need satellite dishes and sound booms. In fact, Newplex reports that CNN

is currently using mobile technology for less that 500USD to create some

of their reports [9]. With such cheap technology, news can be made by the

masses!

The abundance of light-weight, potentially geo-aware, and fairly cheap

technology presents us with the opportunity to create geographically enriched

newsitems. I will now describe a few ways this project can utilize the power

of mobile technology.

6

1.4 Scenarios

Here I outline some possible applications of the NewsDesk project. Some of

these scenarios will be directly addressed by this project, while others will

represent possible future expansions.

1.4.1 On the Spot Reporting

Alice is on a ski vacation. While up in the mountains, she witnesses an

avalanche (from a safe distance). Quick to react, she whips out her mobile

camera-phone and takes a picture of the avalanche. She composes a short

text regarding the event and sends the whole thing off to an online grass-

roots newspaper she often reads. The story gets syndicated within a few

minutes and everybody around the world can read about the avalanche in

the Norwegian mountains. Alice then proceeds to call the authorities.

1.4.2 Simple Editing

Bob the Grassroots Editor runs a small, online newspaper off his private

server. He has employed the NewsDesk system to good effect and has built

up a small cadre of readers that send him news-items from time to time.

He likes to keep an eye on the NewsDesk in-box from his laptop while

having lunch at a local cafe. He sees that Alice has sent a message and

proceeds to read it. Realizing the time-criticality of the situation, Bob decides

to publish the story immediately, only performing the most superficial of

proofreading.

1.4.3 Public Commentary

Charlie is a rescue worker at the ski resort Alice is visiting. He participated in

the search and rescue operation after the avalanche. Afterwards, he returns

to his home and begins surfing the web. He finds Bob’s newspaper and sees

that someone has written a description of the avalanche. Charlie decides to

7

add his own comments, allowing the public to know that no one was hurt.

He fills out a comment-form attached to the story and sends it off to Bob.

1.4.4 Rare Insights

Daniel is a Political Science major travelling through Europe. In Spain he

gets in touch with a number of people with various and strong opinions on the

Bask separatist movement. Daniel takes copious notes, records conversations

with locals, and puts together a small gallery of pictures, all with the help

of his PDA. Sitting in his hotel room, Daniel then composes an article with

the recorded interviews and illustrations about the issues in Spain. All the

pictures and interviews have geodata attached to them. He sends the article

to an online newspaper he knows that runs NewsDesk.

At the newspaper, Eve the Editor reads the submitted article with great

interest. Although it is written with skill and insight, she feels that it is hard

to place the story on the map. By using the alternative geodata attached to

each piece of media, Eve is able to create an overview over where in Spain

people have what opinions on the subject. Eve then proceeds to compose a

map of Spain using a layer of political bent to give the reader an idea of who

is in control where. The map has a number of hotspots attached to it, where

each such spot is a link to the particular interview or picture.

1.4.5 Local knowledge

Fred spots a strange gas emanating from the ground on his way home from

school. He takes a picture of it, writes a short text explaining his worry,

and sends the whole thing to his local grassroots newspaper. There, editors

create a map of the area around where the AMMS was sent, using layers like

roads, sewers, and ground-type. They quickly realize that this is probably

a matter of a pipe sprung leak and publish the story under the headline

”Sewers sprung leak under Halden?”

8

1.5 Document Outline

In this document, I will present a preliminary design and proof-of-concept

for a system that should provide grassroots editors and journalists with the

tools to raise geo-awareness in their work. This document can be seen to

represent a first iteration of the NewsDesk’s life-cycle. The system will be

oriented around the geographic location of each article.

In chapter 2 I give a brief overview of the methodology I have used for this

project. Like all software development projects, the methodology is usually

a idealization of what actually happened. This project is no different, and

the methodology has been a guideline more than a strict recipe.

The actual system is described in chapter 3. Here I present some require-

ments for the NewsDesk system. These are requirements that any implemen-

tation of the system should meet. I have also presented some suggestions for

future features that originally was a part of the requirements. This due to

time constraints on the project.

The chapter on the system also describes the general architecture of the

NewsDesk. In doing so I look in some detail at the various modules that

must be a part of the system. These modules are required in order for

the NewsDesk to be a useful application, although one of the modules can

be considered optional. I have also described additional optional packages

that should be implemented by third party developers for syndication and

publishing of articles.

Finally, in chapter 3, I describe a prototype system that proves the con-

cept of the NewsDesk and the underlying communication protocol.

After the system description, I sum up the results of the project and

suggest future work.

9

Chapter 2

Approach and Methodology

For the NewsDesk project, I have decided on a somewhat informal and hybrid

solution. I approach the problem from a theoretical, system development

point of view, while employing the loose rules of Extreme Programming[10]

to solve technical difficulties and to prove that my ideas are sound. This

way I should end up with a detailed design for the application and a set of

prototypes that can be put together to form a real application with little

difficulty. In the end, I believe that these approaches come together to form

a robust methodology for the NewsDesk project.

2.1 Object Orientation

Formally, I get my methods and project activities from the tradition of object

orientation first suggested by Dahl and Nygaard[11]. It is described in a

bewildering array of academic and technical books ([12], [13]) and is a well

known approach in Computer Science. Object orientation is, in short, a way

to abstract the task the application should perform and break it down into

separate entities with behavior and state. A truly object oriented system is

a set of objects talking to each other, where each object performs some small

subset of the application’s task.

10

2.2 Component Based Software Development

I also draw upon the relatively new component based system development

school of thought [14]. Component based systems further abstract the inter-

actions between objects in a system and allows for independent development

of components. Ideally, component based system development should allow

a developer to subscribe to the services of some third party component that

solves part of the application’s task. The developer’s job will then be reduced

to creating components that use these third party components in a sensible

way.

In order to make the NewsDesk component based, I wish to define in-

terfaces between the modules using the XML based language SOAP. This

way, modules should be able to talk to each other independently of how each

module is implemented. In fact, the modules can be written in any number of

languages and communications between them would remain the same. The

goal is to ensure implementation independent communication.

2.3 Programming Approach

As mentioned above, my programming methods lie closer to Extreme Pro-

gramming than anything else. This in part because Extreme Programming

is a fairly informal method, and in part because it is an intuitive way of

working. The discipline of Extreme Programming is, to simplify, program-

ming through trial and error. The field in which I am programming, mobile

phones and MMS technology is not new, but there is almost no available

documentation on it. This is because most research in the field is performed

by large corporations that understandably wants to keep their trade secrets

to themselves. The consequence is that I have to experiment with code to

find out what works and what doesn’t.

In the end, I want a strictly modular design with few couplings[13] and

clearly defined delegation of responsibility.

11

Chapter 3

The System

3.1 Requirements

Requirement analysis lies at the heart of system development. In the News-

Desk project, however, this analysis (rather, these analyses) have been done

somewhat lightheartedly. This is, in part, because there are few similar

projects available. It has also been difficult finding potential users, as Grass-

roots Journalism has yet to gain the following in Norway as it has in, for

example, Korea. However, discussions with Halden Arbeiderblad revealed

that the project has some interest even with established local media, and

some of the requirements listed below comes from their input.

The list of functional requirements outlined below have been reached

through discussions with my supervisor and my own ideas and visions. Sev-

eral points have been moved from the original list of functional requirements

and onto a list of future functionality. This has been done to better reflect

the scope of this project.

Furthermore, I have used language common to requirement documents.

This means that I have used the word ’shall’ for requirements that must

be met to validate the system, and ’must’ for legal requirements. Since

this project has no legal requirements, I have only used ’shall’. I have used

’should’ for recommendations.

12

3.1.1 Functional Requirements

The following requirements determine the basic functionality of the News-

Desk. If all these requirements are met, we have at least a minimal imple-

mentation. For this project, I will attempt to meet all these requirements.

• The system shall be available as a web-site.

• The system shall be usable by all major web-browsers.

• It shall be possible to submit articles over the internet, using the MMS

protocol amended as per the definition of the AMMS [15].

• It shall be possible to submit articles without being a registered user,

as long as the administrator does not restrict such access.

• It shall be possible for an editor to access any and all articles submitted

to the NewsDesk.

• It shall be possible to edit any article by changing text, adding or

removing graphics including maps and photographs, and adding or re-

moving sounds.

3.1.2 Future Functionality

Future functionality are requirements that are outside the scope of this

project, but are still interesting to implement at some later point. Some

of these requirements must be met for the NewsDesk to be a viable applica-

tion.

• The system shall be available 24/7.

• It shall be possible to sort articles by contributor/author, story loca-

tion, date/time, subject, and status.

• It shall be possible to register at the NewsDesk as a contributor.

• It shall be possible for an administrator to restrict submissions.

13

• It shall be possible to generate maps from known Web Map Services.

• It should be possible to add new WMSs to the list of known services.

• It shall be impossible for anyone to alter an article that an editor is

currently working on, i.e. it should be possible for an editor to gain

temporary ownership of an article.

• It should be possible to let the NewsDesk discover the capabilities of

new WMSs.

3.2 Design Guidelines

The main aim of the design guidelines is to facilitate a design that is easy

to understand and implement. A central issue with this project is the time-

limitation. As I only have one semester (one third of a semester in fact)

to complete the project, I cannot possibly create a fully functional system

that is anywhere near my vision of the NewsDesk. Instead, I shall focus on

creating a design that I, or anyone else, can pick up later.

In order to facilitate an easy to understand and easy to implement design,

I have identified a number of guidelines. I have been heavily inspired by

Szyperski [14].

• Analysis should break the system’s task into a list of several semi-

independent subtasks.

• The system should be designed in modules.

• Each module should solve exactly one subtask of the system’s task.

• Modules should be ’pluggable’, i.e. each module should be designed

independently of other modules. No module should rely on the actual

implementation of another module.

• Each module should be defined by two lists: ’Services offered’ and

’services required’.

14

Figure 3.1: Architectural Overview. The Dispatcher is a recommended add-on.

• ’Services offered’ are the services the module can offer to other modules.

A service could be to create a map in the Portable Network Graphics

format.

• ’Services required’ are the services that must be available to the module

for it to be able to offer the services in its ’Services offered’ list.

3.3 System Task and Architectural Overview

The System Task is a preliminary analysis of the main task of the NewsDesk.

It includes an overview of the separate subtasks that make up the NewsDesk

task. It also includes an attempt to separate these subtask into atomic1

tasks. That is, I intend for each subtask to be semi-independent of all other

subtask. A subtask must necessarily rely on that other subtasks are solved

correctly, but should be completely ignorant and independent on how the

tasks are solved.

The Architecture Overview (See Fig. 3.1) is a preliminary look at the

overall architecture of the NewsDesk system based on the above analysis. It

is meant to give an idea of what modules need be present for the system

1An atomic task is a task that is fully self-contained, i.e. given the proper data atstartup, it can be performed without soliciting services from other modules.

15

to perform its task, and how these modules are connected. It is also meant

as a point of departure for separating the subsequent analysis, design, and

implementation into manageable and independent units.

I have chosen to combine these topics under one header, as they are so

closely related.

3.3.1 System Task

The NewsDesk is the central hub where all parts of the newspaper comes

together. Here is where journalists hand in their articles, their interviews,

and their photographs. It is also where articles go through editing, and are

rejected or published.

There are a number of separate activities going on at the NewsDesk.

Journalists submit their articles, editors edit those articles, and maps and

other graphics are generated. Finally, the results of all these activities are

entered into some central repository for persistent storage. This means that

there should be at least three modules defining the NewsDesk:

1. AMMSListener, where journalists submit their work.

2. Editor’s Desk, where editors edit articles. This includes adding and

removing media like maps and sound-bites. It does not include gener-

ating this media.

3. Respository, where articles, maps, etc. are stored.

A fourth module that should be a priority to add is the Dispatcher. This

module is responsible for knowing where subscribing journalists are at any

point in time and passing messages of breaking stories to those journalists

that are nearby.

3.3.2 Architectural Overview

The AMMSListener should be a server of some kind that listens for incoming

AMMSs. Whenever an MMS enters the AMMSListener, it is parsed to see

16

if it qualifies as a news-item (if it is an AMMS). If it does, it is sent to the

Repository for storage.

The Repository should have a database containing all the AMMSs sub-

mitted and all the edited articles submitted by the Editor’s Desk. The Repos-

itory should be able to differentiate between articles that have been edited

and articles that have not. It should also know which graphics are connected

to which articles. The Repository should also have an interface that deals

with the SQL necessary to communicate with the database.

The Editor’s Desk should be a web-interface that allows an editor to

browse the articles in the Repository. It should also be able to claim owner-

ship of articles (though only one at a time) and edit this article.

3.4 Minimal Implementation

A minimal implementation is a bare-bones implementation of the NewsDesk.

This includes just enough functionality to demonstrate the use of the News-

Desk, but not necessarily full production quality. That is, the minimal im-

plementation does not have to include robust error-handling, but rather lean

towards graceful failure2. If the goal of a modular, expandable architecture

is met, the minimal architecture could be the core of a future, fuller imple-

mentation of the NewsDesk.

The minimal implementation includes three main components that rep-

resent the minimum functionality of the application. First the NewsDesk

needs a repository. This is a central database that contains, at the very

least, records of articles and their components. The second component is the

AMMS Listener. This is a server type application that listens to incoming

messages from roving journalists and submits these to the repository. Finally,

the NewsDesk needs an Editor’s Desk. This last component allows an editor

to view and edit articles. In concert, these three components form the core

functionality of the NewsDesk.

2Graceful failure means that the program may fail upon errors, but will do so in agraceful manner; by releasing resources and presenting warnings to the user.

17

3.5 The Repository

The Repository is the data storage and retrieval hub of the NewsDesk. It is

responsible for maintaining complete records of all article submissions and

most recent editions. It also keeps all data on registered journalists. Finally,

the Repository contains a number of entry points for outside applications or

modules to access the database.

The Repository will appear as a web-service.

3.5.1 Database

The database holds all the stored information of the NewsDesk. It maintains

six relations that helps define the system-classes of the NewsDesk. These six

relations, see Fig. 3.2, are the Journalist, the Article, the Text, the Image,

and the Sound.

The Journalist relation contains information about each registered jour-

nalist. This includes their name, username, password, contact-details, last

known location, and availability. The last known location is only meaningful

if the journalist is available. This relation will contain a dummy entry known

as Anonymous. This is the journalist that will be registered as responsible

for an article in the case of anonymous entries.

The Article is the relation that contains the data on each individual ar-

ticle. It includes date of submission, title, status of the article (i.e. if it is

available for editing), location of article, and a reference to the journalist

that wrote the article.

The Text, Sound, and Image relations define the various media types

that may take part in an Article. They are binary objects with an index,

an optional location, and and optional comment. The text object will never

have a comment, as it should be self-explanatory.

Access to the database is given through the Repository’s interface.

18

Figure 3.2: The Core of the Repository: A relational database. Bold at-tributes are required attributes. In future implementations, sounds andvideos should be additional relations.

19

Figure 3.3: The Repository interfacing with the other NewsDesk modules

20

3.5.2 Interface

The interface represents the various means outside applications have to talk

to the database. It needs to be able to talk to the AMMS-Listener, the

Dispatcher, and the Editor’s Desk. Fig. 3.3 shows what services are offered

to the various modules. These are:

1. SubmitArticle. With this service, a module should be able to store an

article in the Repository. Only articles that do not currently exist in

the Repository or are owned by the submitting module may be stored.

The parameters for this service are many:

(a) Title. This is the title of the article. It may be empty, in which

case the article is to be considered not to be publishable until an

editor can give it a title.

(b) Location. This is the location of the story. It too may be empty,

in which case an editor should try to assign it a location. An

article without a location will not be shown on a map-based article

overview.

(c) Date. This is the date of submission. It is set by the AMMS-

Listener when it first receives the article. It can not be altered by

any module.

(d) Text-List. This is a list of the textual items in the article. In most

cases, this list will contain exactly one item, although an article

may contain several text items.

(e) Image-List. This is a list of the pictures that belong to the article.

This will be implemented as SOAP with attachments.

(f) Sound-List. Just like Image-List.

(g) Author. This is a reference to the Journalist that is responsible

for writing the article.

2. GetArticleOverview. This service must return a list of articles with

locations, date, and author. It’s parameters are:

21

(a) Location-Pair. This is two points on the map representing a rec-

tangle. This parameter may be empty in which case the scope of

the query is the world.

(b) Date. This is the date of the oldest article to be returned. The

parameter may be empty in which case the scope of the query is

the entire history of the NewsDesk.

(c) Status. This is a simple parameter that gives only those articles

that are available for editing, alternatively those that are currently

owned by some editor. This parameter may be empty.

(d) Journalist. This limits the returned articles to those written by

the specified journalist. This parameter may be empty.

3. GetArticleByID. This service returns an entire article. This includes

date of submission, author, status, title, and location in addition to

all the binary objects that make up the core of the article: The text,

images, and sounds. This service takes one parameter:

(a) ArticleID. This is the unique article identifier. This parameter is

mandatory. Failure to provide a valid articleID will result in an

error-message from the Repository.

4. GetLocationByArticleID. This service returns the location of the spec-

ified article. If the article lacks a location, an error message is returned

instead.

(a) ArticleID. This is the unique article identifier. This parameter is

mandatory. Failure to provide a valid articleID will result in an

error-message from the Repository.

5. GetJournalistsByLocation. This service returns the Journalist IDs, sta-

tus, and contact-details of a number of journalists. The service is ren-

dered in a rectangular or a circular fashion. That is, the parameters

are either two locations defining a rectangle or a location and a radius

defining a circle. Either way, the journalists returned are those whose

22

last known location is within the specified area. If too many parameters

are present, the service is undefined and the return may be an error

message or a list of journalists with some geometric shape defined by

some subset of the submitted parameters.

(a) Location. This is a point on the map, specified as a geometric

coordinate in decimal notation. This parameter is mandatory and

may be specified twice for a rectangular shape.

(b) Radius. This is a range in meters from a specified point. This

parameter is optional, but must be used if only one location is

given.

3.6 AMMSListener

The AMMSListener is the essential entry point for the roving journalist.

This is where articles are submitted as AMMSs. The AMMSListener is also

responsible for translating AMMSs into SOAP-messages and submiting these

to the Repository.

3.6.1 Module Architecture

The AMMSListener consists of four components; the Server, the AMMS-

Interpreter, the SOAP-Encoder, and the SOAP-Communicator. Consult

Figure 3.4 for the rest of this section.

The server is a small server that listens to a specified port. When re-

quests are made to this port, a socket connection is opened. The server

reads all bytes sent through this connection, and passes these on to the

AMMS-Interpreter. Once the server reads a close-byte (evaluated at -1), the

connection is closed. For the sake of efficiency, the server should spawn a

new thread for each connection, rather than running every connection in a

single thread.

The AMMS-Interpreter has a twofold purpose. It’s primary task is to

create an in-memory representation of the article represented by the byte

23

Figure 3.4: The AMMSListener architecture with connection to the Reposi-tory. The MMDecoder comes from com.nokia.mms.

stream read by the server. It does this by decomposing the message into lists

of the various media-elements and meta-data.

The secondary task of the AMMS-Interpreter is that of a controller object

for the AMMS-Listener. Although it is the server that kicks off the process

by receiving, control is left to the Interpreter. This to minimize load on the

server. The Interpreter maintains instances of both a SOAP-Encoder and a

SOAP-Communicator, and is the class responsible for administrating their

services.

The SOAP-Encoder’s job is to create a SOAP-Message that reflects the

article submitted to the server and that adheres to the demands of the Repos-

itory.

The SOAP-Communicator simply creates a connection to the Repository

and sends the message from the Encoder asynchronously. The Communicator

is not interested in a reply, as it can do nothing about a failed submission.

Future iterations could include retries and even re-encoding of the SOAP-

Message.

24

3.7 Editor’s Desk

The Editor’s Desk is the entry point for editors. Here, one can browse a

zoom-able map with hotspots. Each hotspot represents a submitted article.

By clicking a hotspot, the editor is given the opportunity to read and edit

the article in a separate window.

3.7.1 Module Architecture

The Editor’s Desk needs four submodules, see Figure 3.5. These are the Ed-

itor, the MapView, the SOAP-Communicator, and the Editor’s Desk Server

that ties it all together. In concert, these four submodules presents the user

with a web-interface for browsing and editing articles in the NewsDesk.

The Editor contains an overview of the various media components of the

chosen article. In the minimal implementation, only the textual components

are available for editing, but all items should be viewable. Each Editor exists

in relation to a single article and it knows itself whether it owns the article or

not. In the case that the Editor does not own the article, it will let the user

know. It will also give the user the opportunity to try and gain ownership

of an article. In such a case, the user should be given the chance to see the

current state of the article in the Repository.

The MapView is the main page for the Editor’s Desk. It contains a large

map overview of the area that the NewsDesk is supposed to cover. This map

is marked with a number of hotspots. Each of these hotspots are articles, or

several articles if more than one article has been submitted from the same

spot. The hotspots are clickable and will create an Editor for the particular

article. Hotspots that represents more than article, will present the editor a

choice whenever they are clicked. Zooming in on the map should separate

the articles from each other.

The MapView will also contain controls for checking for new articles.

These controls should allow the user to apply filters to the query. The filter

should give the user the option to select only articles after a certain date,

within a certain area, or by a certain journalist.

25

Figure 3.5: The Editor’s Desk’s architecture with the Repository and WebBrowser shown.

26

The SOAP-Communicator is the module responsible for communicating

service requests back and forth between the Editor’s Desk and the Repository.

The Editor’s Desk Server is a server capable of generating HTML-code

in response to the state of the Repository and the actions of the user. In

principle, the Editor’s Desk Server should not need to do anything but broker

messages between the user’s web browser and the other submodules of the

Editor’s Desk. The user should not need to know anything beyond the URL

leading to this server. The minimal implementation will not deal with access

control, but this is where editor’s will present their usernames and passwords.

3.8 Dispatcher

The Dispatcher is a module that maintains an overview of where in the world

journalists are. This information is used to warn journalists of breaking sto-

ries, or allowing editors to send journalists to various locations, based on

where the journalists are. The Dispatcher assumes that the journalists have

agreed to divulge their location to the Dispatcher and are running software

on their mobile devices that allow them to report their location to the Dis-

patcher. There are currently several projects at OneMap that are exploring

this issue.

The Dispatcher is a recommended add-on for the NewsDesk.

3.9 The Syndicaters

These are third party applications that present the articles from the News-

Desk. They are free to represent the articles in any way they wish. In order

to receive articles from the Repository, the Syndicaters need to know SOAP

and the correct form of query to the NewsDesk.

The NewsDesk can limit syndication to subscribers by enforcing username

and password at the Repository.

27

Figure 3.6: A request for an article overview

3.10 SOAP

The Repository is the central hub of communication and it prefers to commu-

nicate in SOAP messages, although it should be able to present Articles and

RSS-feeds independently. In order to present a well-defined SOAP environ-

ment for communication, the Repository will have to maintain a web-presence

that receives SOAP messages, acts on them, and replies. Doing this will al-

low clients to take one-step actions to send a message and receive a reply.

This eliminates the need for client modules like the the AMMS-Listener to

maintain web-presences themselves.

The content of the SOAP messages that are passed back and forth depend

on the client’s needs.

3.10.1 Service Requests

All service requests to the Repository will have similar headers. These head-

ers will contain two children, one named username and one named password.

These children will have one text node each containing respectively the user-

name and password of the person initiating the transaction. These values

may be provided by the user in NewsDesks that demand user-control, or they

may be entered by the client application automatically where control is not

needed. Figure 3.6 is an example of a simple request with username and

password.

The body of a service request contains the name of the service solicited.

28

Figure 3.7: A request for a Location based the submitted article ID (1565)

This name is a text node contained by a name-node ”Service” which again

is contained in a SOAP Body Element named ”ServiceRequest”. This is the

very first thing the Repository will look at, as it defines what further action

is to be taken. Figure 3.6 shows a simple request.

The body of service requests also contains all parameters needed to iden-

tify or limit the result of the request. These are contained in a child of the

body by the name ”Parameters”. The name-space for the parameter is the

name of the system class that the parameter is based on. For example, if

the parameter is a location, its name-space will be ”location”. If a service

request uses as a parameter the name of a journalist, the Parameter element

would have a child node by the name of ”Journalist:Name” and that node

would have a single text node that contained the name of the journalist. See

Figure 3.7 for an example.

3.10.2 Service Replies

The Repository will have the same header in all its replies. It will consist of

a single element called repository:serviceReply. This element will contain a

single text node with the exact name of the service solicited. For example,

if the Repository replies to a request for an Article by the article’s unique

identifier, the repository:serviceReply will contain the text node ”getArticle-

ByID”. See Figure 3.8 for an example of a successful request for an article

overview.

Figure 3.8: A reply to a successful request for an article overview. Shrunkto fit page.

30

The body of the Repository’s reply will contain one element by the name

of ”ServiceResult”. This element will carry the payload of the request. If

the service is meant to return several items, each item is given its own child

element of the Service Result. Note that all attributes of classes are defined

relative to the name-space by the same name as the class.

3.11 Prototype

For this project, I have implemented proofs of concept for each module in

the minimal implementation described in 3.4. I call this implementation my

first prototype. The main focus of my implementation has been to prove

the soundness of the communication protocol suggested, and to prove that

it is possible to translate an MMS sent from a mobile phone to a Java socket

server into a SOAP message with media attachments. To do this, I have

implemented the various modules of the minimal implementation to varying

degrees of completeness.

The AMMSListener has been implemented to near complete status. It

only needs some run-time customizability and a code review for robustness.

If these things are implemented/performed, this module is ready for the final

application. In testing I have used he Netbeans Mobile emulator and a real

life Nokia 6630 mobile phone. Both the emulator and the cell-phone had an

application known as Fast Media Reporter installed3. The tests showed that

the AMMSListener is capable of receiving AMMSs from the internet as well as

from local sources. The AMMSListener was also capable of producing SOAP-

messages with the media present in the received AMMSs as attachements.

The Repository is currently a static prototype that serves and handles

SOAP communication. It understands most of the SOAP-messages that it’s

interface requires it to understand, but it’s replies are all static responses.

The Repository’s database is not implemented at all. On the other hand, I

have implemented test applications to ensure that images and texts sent as

3Fast Media Reporter is a project developed by a fellow student in parallel to theNewsDesk. It allows a cell-phone user to compose articles and send them to specifiedIP-addresses.

31

Figure 3.9: An overview of articles in the Repository. This screenshot istaken from a test of the Arealis WMS.

SOAP-attachments survive the conversion into a database object.

The Editor’s Desk is partly implemented. The map-view (see Fig. 3.9

creates a map from a WMS and populates it with hotspots delivered from

the Repository. These hotspots can be clicked, and this will give the user

a view of a dummy article provided by the Repository. The map does not

allow interactive use of the map like zooming or filtering articles. The Article

Editor presents the article it receives from the Repository as it should, but is

not currently able to submit changes (see Fig. 3.10). Neither interfaces has

gone through extensive useability-testing and should not be considered final

in terms of layout.

32

Figure 3.10: The Article Editor. This interface is not usability-tested and isdesigned for demonstration purposes only.

33

Chapter 4

Results and Conclusion

The are two major activities for future work in this project. First, a dynamic

prototype must be produced to show that the concept is not only possible,

but useful. Secondly, the design must be revised, improved, and expanded.

4.1 Prototype Two

The changes needed to turn the current, static prototype into a functional,

dynamic prototype are actually not many.

The AMMSListener is as good as it needs to be for a demonstration of

the NewsDesk. For a final version of this module, it should be given a GUI

that allows a user to choose the URL to the Repository at run-time. This

would allow the AMMSListener to use several Repositories dependent on

need. The final version also needs a thorough review of the code in order to

ensure robustness.

The Repository needs a lot of work, but most of that work is fairly me-

chanical. It currently identifies the service requested and returns a default

answer to the correct service. If the service is unknown or is one of the ones

that have not been implemented, the Repository returns a default ’Service

not implemented’ message. Any request to the server that is not a SOAP

request returns a SOAP message with the only content being the text string

’This server can only accept SOAP requests’.

34

What is needed is to replace the default responses with dynamically gen-

erated responses that reflect the state of the database and possibly alter this

state. This implies that the database is implemented and that the Repository

gets the necessary SQL and database bridges implemented.

What I have done with regards to the SQL is to write exploratory code.

I have had simple SOAP clients pass messages with attachments to a simple

SOAP server. The server received the messages, decoded the attachments

and entered these into a simple Access database using a DNS-less connection.

I also created a separate program that searched the database for images and

displayed these on screen. This proves that SOAP attachments survive the

conversion from image file to SOAP attachment to database object and finally

to a displayable image. As the AMMSListener has proven that images survive

conversions from SMIL attachments to SOAP attachments, this means that

the entire life-cycle of attachments is viable.

The next prototype will also need to have an Editor’s Desk that is able

to submit the changes it makes to an article to the Repository. The Editor’s

Desk also needs to be able to request article overviews based on criteria like

location, date, and author. It is also an idea to store articles with reference

to genres like sports or culture. This should give the Editor’s Desk the option

of browsing news-items by genre.

Finally, the second prototype must be subjected to usability tests. These

tests must demonstrate that the graphical user interface (GUI) design is

usable and functional, or at least uncover what needs to be altered in the

GUI to make it so. They should also uncover what functionality might be

useful to add to later editions.

4.2 Design Improvments

As the first prototype showed, the concept of the NewsDesk is a sound one.

However, the design does not represent a complete solution. The interface

between the modules must be defined in a more definitive manner. This

could be done with schemas.

35

4.2.1 Schemas

The most pressing matter with regards to the design is that of the SOAP

messages. Until now, clients and servers have been written by only one

programmer, and so strict adherence to schemas has not been necessary. In

fact, encoders and decoders have mostly been developed in parallel. This has

not caused a problem because I have been alone on the work. In the future,

however, it is conceivable that more people will take part, and therefore it is

important to formalize the communication.

This means that each service offered by each module must be defined in

terms of two schemas. One schema defines the service request. This schema

declares what parameters, if any, may appear and what data-types these

parameters can be. The other schema defines the response the request gets,

provided the request was successful. This way, a developer working on a

particular module needs only look at the published interface that his module

talks to in order to know what to develop.

4.2.2 New Services

The driving idea behind the communication protocol was extensibility. That

is, the NewsDesk should support additional modules being tacked onto the

core. Future work with the NewsDesk should therefore look at new modules

that could expand the functionality of the project. Such modules could

include the aforementioned Dispatcher that knows where active journalists

are and can warn them of breaking stories. It could also be interesting to have

a WMS-browser that allows an editor to choose WMS, layers, resolution, etc.

4.3 Conclusion

In conclusion, this project has proven the concept of the NewDesk an interme-

diary between content-producing mobile applications and content-presenting

web-based news-services. It has done this by providing a skeleton design,

proof-of-concept implementations of the required modules, and testing of

the modules.

36

There is still a lot of work to be done, if the NewsDesk is ever to be used

in a real life situation. However, this project shows that it is possible to relay

multi-media messages with geographic annotation from mobile phones to the

Internet, and that this can be done with free software.

37

Bibliography

[1] I. Brightman, “Tmt trends: Predictions, 2005, a focus on the media

sector,” Deloitte, Tech. Rep., 2005.

[2] 6th International Symposium on Online Journalism, 2005. [Online].

Available: http://journalism.utexas.edu/onlinejournalism/index.html

[3] D. Gillmor, We the media : grassroots journalism by the people, for the

people. California: Sebastopol, 2004.

[4] S. Outing. (2005, feb) In defense of citizen journalism. [Online].

Available: http://www.editorandpublisher.com/eandp/columns/

stopthepresses display.jsp?vnu content id=1000809651

[5] OhMyNews. [Online]. Available: http://english.ohmynews.com/

[6] M. Glaser. (2005, mar) How to succeed as a citizen media editor.

[Online]. Available: http://www.ojr.org/ojr/stories/050322glaser/

[7] D. Gillmor. (2005, mar) So where is kyrgyzstan, anyway? [Online].

Available: http://dangillmor.typepad.com/

dan gillmor on grassroots/2005/03/so where is kyr.html

[8] I. Brightman, “Tmt trends: Predictions, 2005, a focus on the mobile

and wireless sector,” Deloitte, Tech. Rep., 2005.

[9] “Newsgear real life edition,” 2005. [Online]. Available:

http://www.newsplex.org/knowledgebase/newsgear2005matrix.pdf

38

[10] D. Wells. (2005, feb) Extreme programming, a gente introduction.

[Online]. Available: http://extremeprogramming.org/

[11] O.-J. Dahl and K. Nygaard, The SIMULA project : technical report,

1964.

[12] L. Mathisassen, A. Munk-Madsen, P. A. Nielsen, and J. Stage, Object

Oriented Analysis and Design. Aalborg: Marko Publishing ApS, 2000.

[13] V. Holmstedt, Objektorientert programmering med Java. Bergen: Fag-

bokforlaget Vigmostad og Bjørke AS, 2002.

[14] C. Szyperski, Component software : beyond object-oriented program-

ming. London: Addison-Wesley, 2002.

[15] G. Misund and M. Lindh, “Annotating mobile multimedia messages

with spatiotemporal information,” 2004, to be published.

39