Re: EDUML v0.4 (already!)

[Bruno Vernier <vernier@vc.bc.ca>]

On Fri, Dec 11, 1998 at 05:01:00PM -0600, Eric Sandeen wrote:

> <stakeholder>
> A daytime number (for the school nurse) and an evening number (for parent
> conferences).  I had mentioned that it's possible that a student may have 2
> interested parties, for example, separated parents....  I guess this would be
> covered by repeating the tag?  Would a <comment> tag in here help to differentiate
> between 2 stakeholders?

OK, I added a <note> tag for v0.5 (reserving <comment> for assessment
anecdotes). Thanks.

> I'm trying to understand why the <test> section is within the <attend> section.
> Is this to associate a date with the assignment?  At first glance, it seemed to me
> that attendance and assignments were not that closely related, and that <attend>
> and <test> would both be directly under <learner>

Indeed: this is where I had to make a decision: given than educational
activities necessarily have a date association (ex: date attempted, date
done, date handed in or date marked) ; should that date be a detail of test
or test be a detail of the date?  Are there any programming or logical
reasons favoring one over the other?  The Attendance tag is really an
activity log date tag... I propose to change <test> and <lesson> into simply
<act>?

I also wanted to avoid a redundancy between the attendance thread and the
educational activities thread; after all the later has to happen within the
timeframe of the former (one way or another even if done remotely)... if you
read the stuff between <course> and </course> as a sort of history, it
might make more sense.

Or better yet; lets make attendance be an act ; i.e. showing up to class
would be considered an educational act, and <date> would be a detail of
<act> rather than vice-versa. (remember most tags are optional)

I hope the following allows relatively smooth conversion of existing
commercial gradebook data into EDUML:

<act id="unique act (lesson, quiz, test, lab, attendance...) identifier">
   <date> YYYY/MM/DD </date>
   <comment> anecdote about this educational act </comment>
   <scale id="unique scale identifier"> performance code </scale>
   <mark>  mark based on course's default performance coding system </mark>
   <time> time spent </time>
   <marker> marker's id </marker>
   </act>

> There are some attributes of a test/assignment  that I don't see here - are they
> appropriate for this document?
> Perfect Score - or, number of points this assignment is worth.
> Category - homework, project, quiz, test, etc.  For each category, the relative
> weight or percentage that this category counts in this course.  Would these be
> defined in the <course> section?
> Relative weight of this assignment (1x, 2x, 3x) to other assignments in its
> category

which leaves only the thorny problem about how to deal with the various
algorithms for <scale>.  There are several problems to consider:

1. the commercial gradebooks (I know of) assume a single scale system for
   the entire course the same for all students. This assumption is no longer
   appropriate since many teachers believe that "there is no greater
   inequality than the equal treatment of unequals".  EDUML must continue
   to deal with data sets written in the old paradigm, while flexible enough
   to deal with all sorts of permutations of the new paradigm.

2. With the popularity of "learner-centered" education philosophies, we can
   no longer define a fixed sequence of educational acts nor can we even
   always know ahead of time what some of the acts might be.  

For legacy course-based data sets like the one you mention, the scale
details should probably appear in the <course> tags subset;

 <course id="unique course-id">
   ...
   <path id="unique sequence identifier">
     <plo id="unique plo identifier">
       <high> highest score possible (default 100%) </high>
       <weight type="relative or absolute"> factor or percentage </weight>
       </plo>
     <plo id="unique plo identifier">
       <high> highest score possible (default 100%) </high>
       <weight type="relative or absolute"> factor or percentage </weight>
       </plo>
     <plo id="unique plo identifier">
       <high> highest score possible (default 100%) </high>
       <weight type="relative or absolute"> factor or percentage </weight>
       </plo>
     </path>
   </course>
   
together with a minimal description of scales:

<edu:scale id="unique scale identifier">
  <description> a paragraph explaining this marking schema </description>
  <high> default highest mark </high>
  <list> an array of permissible marks if finite </list>
  </edu:scale>
	       
I think we should leave the implementation of the math of the scale
algorithms to the programs that will use this data.  Gradebook programs can
include all sorts of options for showing the data with weighed aggregates
of quizzes etc ...  I don't we should clutter EDUML with that because it
is just a matter of number crunching. 	       

Bruno