Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Introduction

This wiki explains the design approach for enhancing the Question and QuestionSet Objects to support creation and consumption of Observation with Rubrics.

Problem Statement

  • Creator should be able to create an observation with rubrics against a framework which will have domain & criteria (criteria’s will be associated to domain).

  • Creator should be able to tag observation and its questions with Evidence Collection Method (ECM).

  • Creator should be able to decide on page numbers for questions under either ECM or Criteria

  • Creator should be able to define Scoring, Max and Min Scoring level (at each criteria level).

  • Gathering additional metadata at each framework category level should be driven be form configuration.

  • Consumer should be able to consume the Observation in two ways

    • by browsing taxonomy structure i.e: domain & criteria

    • by browsing list of Evidence Collection Method (ECM)

Rubric is an algorithmic expression which can be used to decide the level of observation consumer.

Approach 1: Creating hierarchy with leafNodes directly

  • The taxonomy structure will be captured and stored at observation root node.

  • The frameworkTemplate metadata will hold the taxonomy structure. sample value is as below:

"frameworkTemplate": {
      "domain": [
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": ""
        }
      ],

      "criteria": [
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria1"
        },
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria2"
        }
      ]
    }

  • list of ECMs will be stored as ecm metadata at root level

  • all children will be stored at level 1

  • additional metadata pageNumber need to be stamped

  • Sample Hierarchy Structure is as below:

{
  "Observation": {
    "name": "observation",
    "description": "test observation",
    "primaryCtegory": "Observation",
    "identifier": "do_1_observation",
    "frameworkTemplate": [],
    "ecm": [
      "ecm1",
      "ecm2",
      "ecm3"
    ],
    "children": [
      {
        "identifier": "do_1_question1",
        "name": "question1",
        "parent": "do_1_observation",
        "domain": "domain1",
        "criteria": "criteria1",
        "pageNumber": 1,
        "ecm": "ecm1" // ecm meta is optional
      },
      {
        "identifier": "do_1_question2",
        "name": "question2",
        "parent": "do_1_observation",
        "domain": "domain1",
        "criteria": "criteria1",
        "pageNumber": 2,
        "ecm": "ecm2" // ecm meta is optional
      }
    ]
  }
}

Pros:

  • This approach is simpler because it provides required views with minimum computation.

  • creation of different needs to perform two operation: filter by metadata and group by pageNumber

  • this approach requires minimal changes in the platform.

Cons:

  • player need to understand pageNumber metadata.

  • player need to perform two operation: filter by metadata and group by pageNumber

  • storing the forms is still not solved with this approach

Approach 2: FrameworkTemplate and View

ObservationType - 'Self' (without ECM)

{
  "Observation": {
    "type": "self",
    "frameworkTemplate": {
      "domain": [],
      "criteria": []
    },
    "sections": [],
    "view": [],
    "children": []
  }
}
{
  "Observation": {
    "name": "observation",
    "type": "self",
    "frameworkTemplate": {
      "domain": [
        {
          "label": "<name_given_by_creator>",
          "name": "domain1",
          "description": ""
        }
      ],
      "criteria": [
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria1"
        },
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria2"
        }
      ]
    },
    "sections": [
      {
        "id": "do_1_section",
        "children": [
          "do_1_question",
          "do_2_question"
        ]
      },
      {
        "id": "do_2_section",
        "children": [
          "do_2_question"
        ]
      }
    ],
    "view": [
      {
        "type": "criteria",
        "domain": "domain1",
        "criteria": "criteria1",
        "section": [
          "do_1_section",
          "do_2_section"
        ]
      }
    ]
    "children": [ // existing structure with new question properties
      {
        "id": "do_1_question",
        "domain": "domain1",
        "criteria": "criteria1"
      },
      {
        "id": "do_2_question",
        "domain": "domain1",
        "criteria": "criteria2"
      }
    ]
  }
}

ObservationType - 'External' (with ECM)

{
  "Observation": {
    "type": "external",
    "ecm": [],
    "frameworkTemplate": {
      "domain": [],
      "criteria": []
    },
    "sections": [],
    "view": [],
    "children": []
  }
}
{
  "Observation": {
    "name": "observation",
    "identifier": "do_obs_1"
    "type": "external",
    "ecm": ["ecm1", "ecm2"],
    "frameworkTemplate": {
      "domain": [
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": ""
        }
      ],
      "criteria": [
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria1"
        },
        {
          "name": "<name_given_by_creator>",
          "domain": "domain1",
          "description": "",
          "criteria": "criteria2"
        }
      ]
    },
    "sections": [
      {
        "id": "do_1_section",
        "children": [
          "do_1_question",
          "do_2_question"
        ]
      },
      {
        "id": "do_2_section",
        "children": [
          "do_2_question"
        ]
      }
    ],
    "view": [
      {
        "type": "ecm",
        "ecm": "ecm1",
        "section": [
          "do_1_section",
          "do_2_section"
        ]
      }
    ],
    "children": [
      {
        "id": "do_1_question",
        "parent": "do_obs_1"
        "domain": "domain1",
        "criteria": "criteria1",
        "ecm": "ecm1"
      },
      {
        "id": "do_2_question",
        "domain": "domain1",
        "criteria": "criteria2",
        "ecm": "ecm1"
      }
    ]
  }
}

children is the existing structure with new question properties such as domain, criteria, ecm etc.

Pros

  1. Creating the views (ECM & non-ECM) for both editor and player becomes easier with the flattened structure.

  2. It addresses all the possible scenarios of sequence/order and presentation of question on the consumption side.

  3. It allows to store the snapshot of the taxonomy with additional metadata.

  4. This design allows to add any framework categories under frameworkTemplate based on the need and views based on any metadata (ex: ECM)

Cons

  1. Every time the editor is loaded, mapping needs to be done between the taxonomy tree and questions in children property.

  2. Proposed structure is different from the current structure supported by the platform.

  3. If a question is deleted, it has to be removed from sections list, but the question does not have any property to hold the section id to backtrack. Hence removing questions from particular `sections` becomes challenging.

Open Questions:

  1. QUESTION - The relation between the criteria and sections ?

Approach 3: Creating hierarchy folder structure as per the taxonomy structure

  • Domain, Criteria & Section will be created as nested folders under observation root node.

  • The hierarchy structure without ECM will be as below:

    {
  "Observation": {
    "name": "observation",
    "description": "test observation",
    "primaryCtegory": "Observation"
    "identifier": "do_1_observation",
    "ecm":["ecm1","ecm2"]
    "children": [ 
      {
        "identifier": "do_1_domain1",
        "name": "<domain name entered by user>",
        "domain": "domain1",
        "parent": "do_1_observation",
        "children": [
          {
            "identifier": "do_1_criteria1",
            "name": "<criteria name entered by user>",
            "domain": "domain1",
            "criteria": "criteria1",
            "parent": "do_1_domain1",
            "children": [
              {
                "identifier": "do_1_section1",
                "name": "section1",
                "domain": "domain1",
                "criteria": "criteria1",
                "parent": "do_1_criteria1",
                "children": [
                  {
                    "identifier": "do_1_question1",
                    "name": "question1",
                    "parent": "do_1_section1",
                    "domain": "domain1",
                    "criteria": "criteria1"
                  },
                  {
                    "identifier": "do_1_question2",
                    "name": "question2",
                    "parent": "do_1_section1",
                    "domain": "domain1",
                    "criteria": "criteria1"
                  } 
                ]
              }
            ]
          }
        ]
      }
    ],
    "view": [
      {
        "type": "criteria",
        "domain": "domain1",
        "criteria": "criteria1",
        "section": [
          "do_1_section1"
        ]
      }
    ]
  }
}

  • The hierarchy structure with ECM will be as below:

{
  "Observation": {
    "name": "observation",
    "description": "test observation",
    "primaryCtegory": "Observation"
    "identifier": "do_1_observation",
    "ecm":["ecm1","ecm2","ecm3"]
    "children": [ 
      {
        "identifier": "do_1_domain1",
        "name": "<domain name entered by user>",
        "domain": "domain1",
        "parent": "do_1_observation",
        "children": [
          {
            "identifier": "do_1_criteria1",
            "name": "<criteria name entered by user>",
            "domain": "domain1",
            "criteria": "criteria1",
            "parent": "do_1_domain1",
            "children": [
              {
                "identifier": "do_1_section1",
                "name": "section1",
                "domain": "domain1",
                "criteria": "criteria1",
                "parent": "do_1_criteria1",
                "children": [
                  {
                    "identifier": "do_1_question1",
                    "name": "question1",
                    "parent": "do_1_section1",
                    "domain": "domain1",
                    "criteria": "criteria1"
                    "ecm": "ecm1"
                  },
                  {
                    "identifier": "do_1_question2",
                    "name": "question2",
                    "parent": "do_1_section1",
                    "domain": "domain1",
                    "criteria": "criteria1",
                    "ecm": "ecm2"
                  } 
                ]
              }
            ]
          }
        ]
      }
    ],
    "view": [
      {
        "type": "ecm",
        "ecm": "ecm1"
        "domain": "domain1",
        "criteria": "criteria1",
        "section": [
          "do_1_section1"
        ]
      },
      {
        "type": "ecm",
        "ecm": "ecm2"
        "domain": "domain1",
        "criteria": "criteria1",
        "section": [
          "do_1_section1"
        ]
      }
    ]
  }
}

Pros:

  • The hierarchy structure is as similar as currently supported by the platform.

  • storing forms for each folder is easy in the category definition

Cons:

  • loading the required presentation (criteria view, ecm view) at consumption requires more processing.

Rubrics at each criteria

{
  "name": "Availability of School Leadership",
  "description": "Availability of School Leadership",
  "type": "auto",
  "levels": {
    "L1": {
      "level": "L1",
      "label": "Level 1",
      "description": ""
    },
    "L2": {
      "level": "L2",
      "label": "Level 2",
      "description": ""
    },
    "L3": {
      "level": "L3",
      "label": "Level 3",
      "description": ""
    },
    "L4": {
      "level": "L4",
      "label": "Level 4",
      "description": ""
    }
  }
}

Behaviour:

  • Creator will see the framework hierarchical structure of domain & criteria for the first time, when creation of observation begins.

  • Once the observation is created, the taxonomy structure will be copied to the observation and same will be shown to the user from next loading of editor.

  • Label and some additional information (description, keywords, etc) can be updated by creator for the copied taxonomy structure.

  • No labels