Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Outcomes: Difference between revisions

From MoodleDocs
m (Moodle metadata moved to Metadata)
 
(25 intermediate revisions by 7 users not shown)
Line 1: Line 1:
'''Feature description:''' Build on the [[Moodle keywords|keywords]] in 1.6 to provide metadata for all activities and courses, linkable to standard lists of metadata such as State-based learning outomes and curricula.
Support for Outcomes (also known as Competencies, Goals, Standards or Criteria) means that we can grade things using one or more scales that are tied to outcome statements.  It is intimately connected to [[Grades]] but is optional to use.


This pages is an initial place to discuss options for storing and managing moodle metadata.  These are just suggestions and are made by a person who does not know moodle internals.
For example, an assignment might be graded according to these three scales (together known as a Rubric).


There are several steps to managing a complex applications metadata:
Content - Poor, Fair, Good
# Document the key "Data Element Concpets" and their structure. This would include high-level concepts such as Course, Student, Teacher etc.
  Organisation - Poor, Fair, Good
# Document data element properties associated with each concept. Properties should always be associated with a concept.
  Grammar - Poor, Fair, Good
# Store this metadata in a metadata "registry", a centrally managed place to store metadata
# Create a system that allows users to modify and update metadata


There are several ways to approach this.
These are the components:


* There are metadata registry standards such as ISO/IEC 11179. This standard has a wide number of interpretations.
==Site vs Course outcomes==
* There are other education metadata standards such as IMS global and the School Interoperability Framework (SIF)
* Once the metadata is stored in a consistant place and format, transforms can be made to extract portions of the metadata using reports or transforms
* A matadata registry can be the heart of a model-driven architecture


Most systems attempt to seperate the semantics from the representation of metadata.
Most outcomes are made available at the site level, which means they can be used by any activity in any course, provided the overall switch is on. This is achieved by leaving the outcome's courseid field empty (in the database).
# Semantics tell us the meaning of a data element but are free from version or constraints
# Represtations of the metadata tell us what table and column metadata appears in each version of Moodle and what the limitations are in a specification


Many metadata managment systems use a 3-part data element name:
In some cases you may want to define a special outcome, specific to a particular course. This is achieved by assigning the course ID number to the outcome's courseid field. Such an outcome is ''NOT'' available outside the context of that course.


ClassPropertyTerm
==Overall switch==


Were Class is the concept, property is a property of that concept and Term is a Representation term such as Count, Date, ID, Indicator, Text
The admin has a site-wide switch to enable/disable outcomes completely for the site.


For example:
==Outcomes management and reporting==


  CourseDescriptionText
A grade report at /grade/report/outcomes is the place where people manage outcomes. There are three tabs to this report, visibility is dependent on your permissions:


==Questions==
===Site management (Admin user)===
* Where can we get a list of key moodle conceptual data elements and their definitions?


* How do we set up a data stewardship role so individuals take responsiblity for maintaining subsets of all the data elements?
The admin can create and edit a list of outcomes using a GUI. 


* What should the highest level data elements be?  Course, Enrollment, Organization, Person, Quiz
Outcomes have these main fields:
* shortname - some code or abbreviated name
* fullname - the full "sentence" describing the outcome
* scaleid - a chosen scale for ratings


==See also==
Later we can also add importing from a CSV file, so that it's easy for sites to import long lists of state-based standards or training competencies.
* [[Thing]] A root data element of a metadata registry
* [http://en.wikipedia.org/wiki/Metadata_registry Wikipedia entry for Metadata registry]
* [http://en.wikipedia.org/wiki/ISO/IEC_11179 Wikipedia entry for ISO/IEC 11179 ]
* [http://en.wikipedia.org/wiki/Data_element Wikipedia entry for Data element]
* [http://en.wikipedia.org/wiki/Representation_term Wikipedia entry for Representation term]
* [http://en.wikipedia.org/wiki/Data_element_name Wikipedia entry for Data element name ]
* [http://en.wikipedia.org/wiki/Data_element_definition Wikipedia entry for Data element definition ]


==Example of a K-12 education metadata registry for ==
===Course management (Editing teacher)===
* [http://education.state.mn.us/datadictionary Minnesota (US) Department of Education Data Dictionary]


[[Category:metadata]]
The editing teacher can choose from this large list to pick a subset of outcomes for the current course.  They can also define new outcomes to be used JUST for this course.
 
===Course reporting (Teacher)===
 
The course report displays all the chosen outcomes for this course along with information about which activities are currently tied to them, or reporting of students according to which outcomes they've achieved "passing grades" in, and which ones they are failing in, as an aid to identify strong/weak points for individuals and groups.
 
Here is a sample report:
 
<table border="1" summary="Outcomes Report">
<tr><th>Outcome name</th><th>Overall average</th><th>Site-wide</th><th>Activities</th><th>Average</th><th>Number of grades</th></tr>
 
<tr><td rowspan="1">intelligence</td>
<td rowspan="1">Idiotic (1.5)
</td>
<td rowspan="1">No</td>
<td>Philosophy in France</td><td>Idiotic (1.5)</td><td>2</td></tr>
<tr><td rowspan="2">Wisdom</td>
<td rowspan="2">Smart (4.29)
</td>
<td rowspan="2">Yes</td>
<td>Ancient Gaul</td><td>Stupid (2.6)</td><td>5</td></tr>
 
<tr>
<td>French Kings and Queens</td><td>Clever (5.97)</td><td>2</td></tr>
<tr><td rowspan="1">honesty</td>
<td rowspan="1"> - </td>
<td rowspan="1">Yes</td>
<td> - </td><td> - </td><td> 0 </td></tr>
 
<tr><td rowspan="1">Arrogance</td>
<td rowspan="1"> - </td>
<td rowspan="1">Yes</td>
<td> - </td><td> - </td><td> 0 </td></tr>
</table>
 
==Activity editing==
 
A new grading section added to the course mod update form using a single function (similar to standard_coursemodule_elements()) which offers a choice between:
* basic grading (as now) OR
* outcomes
 
The course outcomes are shown in a multi-select list and any number can be chosen.
 
For Moodle 1.9 we should not offer both, to keep things simple.
 
The result of these forms goes to course/mod.php which is able to process them without any further functions from the module itself.  Roughly it would use grade_get_items to find out what items were already set, and then compare to the new form input to work out what calls to grade_update() need to made to create/update/delete existing grade_items.
 
Note that not all activities could be upgraded to support this.  Assignment is a natural first one to implement for 1.9, then we can see after that. 
 
Potentially even modules without grading could still support outcomes, the columns in the gradebook would just have to be filled in manually, that's all.
 
==Activity grading==
 
Activities that support grading (like Assignment) need to be upgraded to support:
===Multiple grading interface===
grade_get_items() would get the items and make the interface fairly easy to do.  Where there was one popup menu there would now be multiple popup menus.
 
===Storage of multiple grades===
This is a bit more tricky, because we want to avoid adding lots of grade1, grade2, grade3 fields to every module's tables.
 
I can see three potential ways forward here:
 
# We add new fields to every module and just live with the hardcoded limits (eg max of 5 outcomes per activity).
# We add a new generic table where modules can store their grades (outside of the gradebook).
# We open up the API slightly to allow modules to store their grades directly into the gradebook.  This sort of binding was something I have been always trying to avoid but perhaps it's unavoidable.
 
We need to discuss these options and think about them some more.
 
 
 
Some example scenarios: [[Outcomes_examples]]
 
[[Category:Project]]

Latest revision as of 08:20, 10 June 2011

Support for Outcomes (also known as Competencies, Goals, Standards or Criteria) means that we can grade things using one or more scales that are tied to outcome statements. It is intimately connected to Grades but is optional to use.

For example, an assignment might be graded according to these three scales (together known as a Rubric).

Content - Poor, Fair, Good
Organisation - Poor, Fair, Good
Grammar - Poor, Fair, Good

These are the components:

Site vs Course outcomes

Most outcomes are made available at the site level, which means they can be used by any activity in any course, provided the overall switch is on. This is achieved by leaving the outcome's courseid field empty (in the database).

In some cases you may want to define a special outcome, specific to a particular course. This is achieved by assigning the course ID number to the outcome's courseid field. Such an outcome is NOT available outside the context of that course.

Overall switch

The admin has a site-wide switch to enable/disable outcomes completely for the site.

Outcomes management and reporting

A grade report at /grade/report/outcomes is the place where people manage outcomes. There are three tabs to this report, visibility is dependent on your permissions:

Site management (Admin user)

The admin can create and edit a list of outcomes using a GUI.

Outcomes have these main fields:

  • shortname - some code or abbreviated name
  • fullname - the full "sentence" describing the outcome
  • scaleid - a chosen scale for ratings

Later we can also add importing from a CSV file, so that it's easy for sites to import long lists of state-based standards or training competencies.

Course management (Editing teacher)

The editing teacher can choose from this large list to pick a subset of outcomes for the current course. They can also define new outcomes to be used JUST for this course.

Course reporting (Teacher)

The course report displays all the chosen outcomes for this course along with information about which activities are currently tied to them, or reporting of students according to which outcomes they've achieved "passing grades" in, and which ones they are failing in, as an aid to identify strong/weak points for individuals and groups.

Here is a sample report:

Outcome nameOverall averageSite-wideActivitiesAverageNumber of grades
intelligence Idiotic (1.5) No Philosophy in FranceIdiotic (1.5)2
Wisdom Smart (4.29) Yes Ancient GaulStupid (2.6)5
French Kings and QueensClever (5.97)2
honesty - Yes - - 0
Arrogance - Yes - - 0

Activity editing

A new grading section added to the course mod update form using a single function (similar to standard_coursemodule_elements()) which offers a choice between:

  • basic grading (as now) OR
  • outcomes

The course outcomes are shown in a multi-select list and any number can be chosen.

For Moodle 1.9 we should not offer both, to keep things simple.

The result of these forms goes to course/mod.php which is able to process them without any further functions from the module itself. Roughly it would use grade_get_items to find out what items were already set, and then compare to the new form input to work out what calls to grade_update() need to made to create/update/delete existing grade_items.

Note that not all activities could be upgraded to support this. Assignment is a natural first one to implement for 1.9, then we can see after that.

Potentially even modules without grading could still support outcomes, the columns in the gradebook would just have to be filled in manually, that's all.

Activity grading

Activities that support grading (like Assignment) need to be upgraded to support:

Multiple grading interface

grade_get_items() would get the items and make the interface fairly easy to do. Where there was one popup menu there would now be multiple popup menus.

Storage of multiple grades

This is a bit more tricky, because we want to avoid adding lots of grade1, grade2, grade3 fields to every module's tables.

I can see three potential ways forward here:

  1. We add new fields to every module and just live with the hardcoded limits (eg max of 5 outcomes per activity).
  2. We add a new generic table where modules can store their grades (outside of the gradebook).
  3. We open up the API slightly to allow modules to store their grades directly into the gradebook. This sort of binding was something I have been always trying to avoid but perhaps it's unavoidable.

We need to discuss these options and think about them some more.


Some example scenarios: Outcomes_examples