Difference between revisions of "Data Model Creation"

From crowdresearch
Jump to: navigation, search
Line 2: Line 2:
This section contains tasks associated with creating various data models and schemas.<br>
This section contains tasks associated with creating various data models and schemas.<br>
'''<u>Data Model Example</u>'''
'''<u>Data Model Example</u>'''
[[File:Core Data Model Team Betzy.png|650px|center|thumb|Fig 3. Data Model Example]]
[[File:Core Data Model Team Betzy.png|650px|left|thumb|Fig 3. Data Model Example]]

Revision as of 20:54, 13 April 2015


This section contains tasks associated with creating various data models and schemas.
Data Model Example

Fig 3. 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.

For more details please see an example: Data Model