Task Assignment in Amara: Prototype FCFS (First Come First Served)

Task Assignment in Amara: Prototype FCFS (First Come First Served)

One of the case studies of P2P Models is Amara On Demand (AoD), a pay-on-demand subtitling and translation service that is part of the Participatory Culture Foundation’s Amara project. Professional linguists and translators working at AoD are paid for their work, unlike Amara, where the work is voluntary.  This work consists of subtitling, translation, transcription and analysis of videos or text files. 

The system for assigning tasks to linguists in AoD follows the First Come, First Served (FCFS) policy. This system emulates a line of people where the first person to arrive is the first person to be served to take a task. This arrangement usually results in people interested in doing a job constantly consulting the system waiting for new tasks to appear so that they can take them first. In the months in which we have investigated the ways in which Amara on Demand works, and thanks to the research and analysis carried out within our project, this process of assigning tasks has been identified as a possible point of intervention where blockchain technology could be used, since workloads are inconsistent and cause a sort of competition among linguists to have tasks assigned to them. 

first-come-first-serve

Our aim is to approach this intervention point gradually and iteratively, through the design and development of prototypes that implement different models of assigning tasks and value, using blockchain technologies that can improve the workflow and general wellbeing of the community. Each iteration of development is accompanied by a “testing” phase where we present the prototype to a pilot group of linguists to collect data related to how they interact with the system to obtain and refine the software requirements.

This first prototype consists of a simple decentralized app (dApp) that emulates the current FCFS assignment logic of tasks with the slight difference that the assignments are stored in the blockchain.  With this prototype we do not seek to improve the original system but to incorporate the blockchain technology in a non-intrusive way and to provide linguists with an introduction to the technology, so that they become familiar with its key elements, for example: wallets, private or public keys, crypto-currencies and transactions, among others. 

With this prototype we do not seek to improve the original system but to incorporate the blockchain technology in a non-intrusive way and to provide linguists with an introduction to the technology, so that they become familiar with its key elements

If you want to see the code behind the prototype, you can visit the project’s repository on Github. Below, we explain in depth the details of the prototype.

In the next section we describe the architecture that our prototype will have.  

Task Assignment in Amara

The prototype will consist of a web application that will communicate with a server that acts as a proxy API in order to connect to the Amara API and obtain the translation or transcription tasks. We will use this proxy to avoid the CORS problems that would arise if we connected directly to the Amara API.

As we need a key associated with an Amara user account in order to access Amara’s API, we will create a series of demo accounts that we will store in a database to which our API proxy will have access. Finally, we will make use of a smart contract located in the blockchain to which our web application will be connected where we will store the tasks that have been assigned to users.

Technology Stack

In this section the  set of technologies that have been used to develop the prototype are outlined:

Technology Stack

The Aragon modules found in the diagram are part of the framework of the same name. If you are not familiar with this framework, you can find a definition and description of its structure in a previous blog post

Prototype functioning

The prototype will consist of a single view that displays both the translation and transcription tasks, in gallery mode, that the user is working on and the available tasks that can be assigned.

Overview. Available tasks section
Overview. Available tasks section
Overview. Assigned tasks section
Overview. Assigned tasks section

Each card displays a screenshot of the video to be translated along with its duration and the language into which it should be translated. You can also find a section where some details of the task are shown such as: the source language, the subtitles that have been done so far and the delivery date of the task, among other things. 

The assigned tasks have a green button that redirects users to the Amara subtitle editor to start the translation or transcription of the video. On the other hand, the available tasks have a blue button which allows users to create and sign a transaction through the smart contract which will assign the task.

What we seek is for the community to gain an introduction  to blockchain tools

A look at the smart contract of our prototype

The smart contract of the prototype is quite simple. Below we can see its basic structure:

contract TaskAllocationApp is AragonApp {
 using SafeMath for uint256;
 
 ///Events
 event TaskAssigned(bytes32 languageGroup, string userId, string taskId);
    
    ///Types
    enum Status {New, Assigned, Completed}
    
    struct Task {
     Status status;
    }
    
    ///State

    /**

     * Key: Language group.

     * Value:

        Key: User id

        Value: Task id

     */
    mapping(string => Task) tasks;
    mapping(bytes32 => mapping(string => string)) taskRegistry;
  
   /// Permissions
    bytes32 constant public ASSIGN_TASK_ROLE = keccak256("ASSIGN_TASK_ROLE");
    
   function assignTask(
        bytes32 _languageGroup,
        string _userId,
        string _taskId
    )
    external
    taskAlreadyAssigned(_languageGroup, _userId, _taskId)
    userAlreadyHasTask(_languageGroup, _userId)
    auth(ASSIGN_TASK_ROLE)
    {
     ...
    }
    
    ...
}

We will have a single event that we will broadcast each time we assign a task so that we can update the front end.

To keep track of the tasks we will use mapping (hashmap) where we index each task by its ID. At the moment we will only store the status of each task.

We must also keep a record of the tasks assigned according to the language group, as each user can only be assigned a single task per language. To do this, we will use mapping where for each language group we will have, in turn, mapping with the users who have been assigned a task with that language to translate.

The prototype will implement a single permission named ASSIGN_TASK_ROLE that, in principle, all linguists will have in order to call the assignTask() function.

Conclusions

As you can see, this first prototype is quite simple in terms of business logic. The logic of the smart contract is also simple, even basic. As we have commented before, what we seek is for the community to gain an introduction  to blockchain tools. Therefore, this is the first phase in a series of development cycles where we will design and implement new task assignment models that are increasingly sophisticated in terms of the use of technology. 

AUTHOR

Paulo J. Colombo
Paulo J. Colombo

Blockchain developer

You may also like