System Architecture Approach

Our approach for the system architecture is to use the lessons learned from the MMM and Wishter projects. The MMM and Wishter projects both use a faceted metadata structures to store the annotations of images. The images are stored in a local file directory and associated to the annotations via reference names.

The system architecture is a basic client server architecture just like the MMM project. As seen in figure 1 (Mobile Image Component Architecture), the architecture is very similar to that of MMM and Wishter. The architecture consists of 3 main components that include the application server, mobile phone, and the PC browser. The PC browser and the mobile phone both have the same functionality with the exception of browsing and becoming a member of a group only available on the PC browser. The application server will be a global store of the images that are downloaded during the completion of a photo challenge as well as the global store for the faceted metadata and the generated tasks.

Some of major differences are the use of a java application running on the handset (mobile phone) and queueing of images during download either through the application or via email. Our experience developing the MMM application raised some issues regarding latency as well as control over the application on the handset. We are going to use java code to implement the user inteface between the mobile phone user and our game. By coding our own client application on the phone using Java, we will have greater control over the functionality responsibilities between the phone and the application server. This will also alow us to address the latency issues we experienced in the MMM project. The latency issues during the upload and download of images were due to the lack of control over caching on the client application as well as on the client browser on the phone. We are looking to alleviate this issue by queueing up the images either via email or through our application. Also, when transferring images from our application server to the phone, we will be using thumbnails of the images to upload.

As shown in figure 1, the application server contains four major processes. All of these processes either add or modify the faceted metadata store. This is another key difference between the implementation of MMM and Zooke. By having all of these process modify and add to the faceted metadata store, we will be implementing our distributed annotation approach discussed in the next section. This distributd annotation approach to create metadata for a photograph is leveraging the game aspect of Zooke as well as the multiplayer game aspect of Zooke.

Figure 1 Mobile Image Phone Game Component Architecture

Distributed Annotation for Metadata Gathering

The current annotation approach by both Flamenco and MMM are shown in figure 2. This approach basically burdens the user with all the work. The user takes the photograph, uploads the photograph to the data store, and does the annotation of the photograph. As shown in the figure 2 (Current Annotation Process), all the work is done by the same user and further, most of the work is done in the third phase, photo annotation. Through user studies we conducted regarding the MMM annotation process, a major finding was the lack of incentive to annotate photographs. Many users found little or no use of descriptively annotating their own photograph.

Figure 2 Curent Annotation Process

A major goal of the Zooke game is to address this concern from the users. Our approach is to use a distributed annotation approach in order to add metadata to photographs. We have divided the annotation process into three steps and have different users complete each step. We are using the zookes/tasks to accomplish this. Figure 3 (Annotation Approach) highlights the distribution of work among the tasks. When a player generates a photo challenge zooke, they initially will be asked to annotate the zooke with initial metadata such as primary facet and secondary facets. The facet node from the primary facet selected will not be too deep into the facet. During the zooke photo completion activity, the photograph taken will be associated with the zooke and all the initial metadata will be inherited by the photograph. Also, the location, time, and userid of the person taking the photograph will be added as metadata as well. In th verify activity, the photograph will be verified as completing the zooke/task and through iteration, the photograph will be further annotated.

Figure 3 Annotation Approach

Figure 4 shows a more descriptive picture of the distribution of work and annotation. This figure highlights the amount of metadata gathered is larger than the previous annotation method. Also, you notice that the work is divided across multiple users and that the majority of the work which still occurs in the last phase (annotation phase) is divided across the community.

Figure 4 New Annotation Process

Figure 5 User Interaction Component Diagram