Data Model Creation
This section contains tasks associated with creating various data models and schemas. Following example shows how to structure the attributes for various entities.
- Please add your proposal under the sections below
- Include the GitHub link for implementation
Targeted Modules & Focus
- User Management
- Create Account
- User Roles
- User Profiles
- Dashboard for workers
- List of Available jobs
- Selecting a desired job.
- Executing & Submit the job
- Profile with list of jobs completed and payment accumulated.
- Publish tasks
- Dashboard for requestors
- Create Project & design Tasks
- Create Qualification
- Publish Tasks
- Review Results
- Mechanisms for viewing the jobs that workers executed.
- Profile with list of jobs that were requested and the amount of money spent on each.
- DataModels supporting above functionalities
Data Model 1
Data Model Example
- User - This is the Django User model, it provides functions like create_user and it's used for login/logout.
- UserProfile - Inherits from the User model, it extends it with more information about the user.
- Worker - Inherits from the UserProfile, this will be the worker profile.
- Requester - Inherits from the UserProfile model as well, it contains the requester profile. *
- Skill - This model is used to maintain the skills, allows subskills as well.
- WorkerSkill - Maps the skills to workers, it allows skill verification.
- Tests - These will be tests for skills WorkerTest - Maps the tests to workers, the result and so on.
- Project - This is the project itself which is led by one Requester ProjectRequester - defines the requester and the collaborators of a project.
- ProjectModule - A module is a set of HITs, this defines the project modules, with a description, template, status and so on. A project can have many
- Template - this will be the template model which contains the defined templates by the user (the html source).
- Qualification - There are module based qualifications and there can be as many qualifications as needed.
- QualificationItem - Defines the actual qualification parts, using the workerAttribute, operator, value1 and value2. This allows the requester to create any kind of qualification e.g. username='john', age>20, country = 'USA', approvalRate>'80%' and so on. There will be complex qualification clauses combined with binary operators. #There will be an option to specify the type of the Qualification it could be STRICT or ALLOW_APPLICATIONS, where strict would make these hits appear only to the workers who pass this qualification, and *ALLOW_APPLICATIONS would allow for example new users to apply for the modules even though they don't fullfill the requirements of the qualifications.
- WorkerApplications - Here we *maintain the worker applications for modules/projects, the requester can review these applications and approve or deny them. Approving them would mean that a new qualification *would be added to the module itself username='approved username' ORed with everything else.
- HIT - This will be the hit model, every hit belongs to a project module. HITWorker - *This will contain the workers which are working on the hits.
- HITResult - Maintains the results submitted by the workers, it works together with the specified template for the module. *There will be result requirements which are pretty much the same as "qualifications", but they will be applied to the results instead of workers, e.g. SELECTLIST1 IS NUMERIC AND *SELECTLIST1 BETWEEN 1 AND 10 TEXTFIELD1 is $ANIMAL_NAME and so on.
Link to GitHub
Data Model 2
In this section we will define the user model in more detail.
The aim of this model is for it to be extensible, non-redundant and modular.
A single user is defined, from which the "type" determines if it is a requester or worker (or maybe a moderator in some particular cases). The same basic information need to be created for all users. From there, each user can have other modules. All users require a "work profile", which will keep track of their skills, their reputation or rating and other specification necessary for them to depict when they are working. Users might also require a "social profile". This profile is very useful in cases where teams want to work on empathy or other social aspects. Linked to it are activities related on a social basis. More information can be acquired from this model (e.g. all users involved in a particular activity) if the right query is performed.
Data Model 3
In this section we will define the HITS model in more detail.
The aim of this model is for it to be extensible, robust, non-redundant and modular.
A single HIT and its characteristics are defined under "HIT". Pricing is considered as a separate table or module in case some teams want to incorporate their own pricing methods and tactics. The "HT_Q&A" keeps track of questions asked about HIT and how they were answered.
Data Model 4
This is another proposed overall data model design.
The diagram is self explanatory w.r.t. in attributes ,primary/foriegn key relations.The SUBMISSION_TABLE is created at runtime for any JOB entry created. Multiple SUBMISSION_TABLEs are created, one for each JOB .This involves the time taken for running DDL queries at the RDBMS level,which is acceptable at the time of creating tasks.
DRI Durim Morina
|Member||Model||Link to the Git|
Horizontal Team: Gaby, Elsa, Neil, Saiph, Durim