NewsDesk; Bringing Maps to Grassroots Journalism H˚ akon Arneng Holmstedt Høgskolen i Østfold Digital Maps Halden May 19, 2005
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