WeekDaze

Timeslot-id Bounds

Defines the closed interval bounding the integral range of timeslot-ids, @ which lessons can be booked in each day. Because this range is defined not merely by its length, but by minimum & maximum bounds, one can arrange to start from one's preferred origin; the choice of integers makes no difference to the solution-algorithm, only the number of time-slots.

The solution-algorithm has neither awareness of the time-span between adjacent time-slots, nor does it assume that these gaps are of equal duration. There are some undesirable consequences of this design-choice; e.g. one may not want to book swimming immediately after lunch; or a double lesson spanning lunch-time, but the duration & purpose of any gap between the two time-slots, during which lunch might occur, is undefined.

Elsewhere in the configuration-file, one can arrange to:

  • avoid this problem completely by defining lunch as a group, of which all people are members, & the Meeting-times of which are then scheduled in periods, rather than invisibly between them.
  • bias the algorithm towards more desirable solutions;

Subsequently one will be able to use the Meeting-time page to define the times when groups regularly meet, & use either the Service page to specify the Ideal-timeslot request or use the Specific Time Request page to specify the precise time, of any lessons of a course; all of which may require correction if these bounds are subsequently changed.

Fields

Min:

Specifies the minimum timeslot-id.

Max:

Specifies the maximum timeslot-id.

Group-catalogue

Identifies the existence of groups, i.e. entities a person can join to meet with other members.

Subsequently one can use the Student Group-membership & Teacher Group-membership pages to define the group-members, & the Meeting-time page to specify when they regularly meet.

Fields

Group-catalogue Id:

Automatically assigned, globally unique, integral identifier for a group.

Group-id:

The unique (within the domain of a project) name of a group.

Location-id:

References a location @ which to meet. Any location referenced must have been defined in the Location-catalogue page. This is optional, because there may be no requirement to meet physically; perhaps because it's a teleconference.

Mandates Attendance:

A boolean switch which defines whether group-members are required to attend all meetings. E.g. one could enrol all teachers in a group for morning-assembly, but if some are part-time, then attendance can't be mandatory; there is no facility to define a group for which only some meetings are mandatory.

Location-catalogue

Specifies the attributes of locations which are available to hold a lesson or a meeting.

Subsequently one may use the Facility page to advertise its attributes.

Fields

Location-catalogue Id:

Automatically assigned, globally unique, integral identifier for a location.

Location-id:

The unique (within the domain of a project) name of a location; perhaps merely a room-number (all that is required is that it is meaningful to the intended observers of the solution).

Availability:

Enumerates those days when the location is regularly available for use; there's currently no concept of a location being available either for fractions of a day or irregularly.

Capacity:

Quantifies the ability to cater for students, & which may correspond merely to the number of desks.

Campus:

A string used to group proximate locations, between which intraday migration is trivial. If the institution for which the timetable is required, has some locations @ its disposal which are sufficiently remote from its centre to require considerable transit time, then one may choose to partition them into separately named campuses.

CAVEAT: the configuration doesn't quantify the distance (or time) between campuses, so no attempt can be made by the application, to minimise the total daily distance travelled (or the journey-time), rather the total campuses visited per day is minimised.

Stream

Names the streams to which student-bodies may be assigned in any specific project;

Subsequently one may use the Student-body Register page to assign student-bodies to a stream.

Fields

Stream-id:

Automatically assigned, globally unique, integral identifier for a Stream.

Stream-name:

A free-format string which may be used to represent their academic year or ability of a student-body; the solution-algorithm is independent of the specific string chosen.

Student-body Register

Specifies the attributes of student-bodies.

Subsequently one must use the Student-body Membership page to define the member-students & the Knowledge-requirements page to register the subjects in which they are interested, & may use the Student Group-membership page to enrol them in groups.

Fields

Student-body-register Id:

Automatically assigned, globally unique, integral identifier for a student-body.

Mnemonic:

The unique (within the domain of a project) name of the student-body.

Stream-id:

References one of the streams defined in the Stream page. This concept is probably redundant, since the subjects, implicitly define a more precise Topic-specific capability. If the streams of student-bodies differ, then those student-bodies can't be merged either permanently into a larger student-body, or even temporarily (for the tuition of a specific subject) into a student-class. If one wants to allow; an able student to learn a subject with students from a higher year; or students of the same year, but different academic ability, to be able to play sports together; it is necessary to render this concept void, by for example accepting the default value (a null string), for all such students. Voiding this concept, won't then explicitly prevent undesirable temporary mergers between students in different years, when playing a sport, but this scenario never arises if they subscribe to sport-related subjects at a Level appropriate for their age.

Availability:

Enumerates those days on which each member of the student-body is regularly available; there's currently no concept of a student-body being available either for fractions of a day or irregularly. Typically they'd have no choice, but some students (perhaps with special needs) may occasionally be unavoidably unavailable.

Teaching-ratio:

Defines the floating-point ratio in the semi-closed unit-interval (0,1], of available time, which can be allocated to tuition. The remaining time, can by inference, be allocated to either meetings or free-study. A student-body's work-load associated with; core Knowledge-requirements shouldn't overflow, & all Knowledge-requirements shouldn't underflow; this ratio.

CAVEAT: if the required ratio can't be represented precisely as a decimal, then one ought to specify sufficient precision to limit the rounding-error to less than one lesson per week, & round the remaining error up. If for example a student-body requires 13 timeslots according to their Knowledge-requirements, there are 3 timeslots per day, 5 working days, then the minimum compatible Teaching-ratio can't be expressed precisely as a decimal. If you specify their Teaching-ratio as 86.666%, then the application (which uses precise arithmetic) won't be able to book the 13th lesson, since this decimal is fractionally smaller than the required ratio (13/15), & the ratio is there to prevent student-bodies becoming overloaded; the correct action would be round this up to anything less than 14/15, e.g. 87%. This example places the cart before the horse, since typically one would decide the Teaching-ratio before the Knowledge-requirements, but typically there's some debugging to perform.

Free-period Preference:

Optionally defines a preference, for the position within each day when the student-body is available, of unallocated time-slots, i.e. those which are neither booked with a lesson nor reserved for a meeting. Students would not normally be allowed to arrive late or depart early, so this feature is of little practical value. The values are the same as for teachers; see below.

Teacher-register

Specifies the attributes of teachers.

Subsequently one can use the Service page to define the courses they offer & the Teacher Group-membership page to enrol them in groups.

Fields

Teacher-register Id:

Automatically assigned, globally unique, integral identifier of a teacher.

Teacher-id:

The unique (within the domain of a project) name of a teacher. Whilst one could pseudonymise this by using an employee-id, it must be meaningful to the intended observers of the solution.

Location-id:

References a location which is considered to be theirs. Any location referenced must have been defined in the Location-catalogue page. This attribute is optional, because the teacher may not have any such location.

Availability:

Enumerates those days on which the teacher is contracted to be regularly available; there's currently no concept of a teacher being available either for fractions of a day or irregularly.

Maximum teaching-ratio:

Defines the maximum floating-point ratio in the closed unit-interval [0,1], of available time, which can be allocated to teaching. The remaining time, can by inference, be allocated to either meetings or administration.

Free-period Preference:

Optionally defines a preference, for the position within each day when the teacher is available, of unallocated time-slots, i.e. those which are neither booked with a lesson nor reserved for a meeting. The position of free time-slots in a teacher's timetable, is dependent on those in student-bodies' timetables; e.g. if the latter are required to attend morning assembly, then those teachers who don't, will either have a staff-meeting @ that time, or a free time-slot. Valid values are:

Pre:

A preference for unallocated time-slots to precede the first lesson or meeting of the day.

Terminal:

A preference for unallocated time-slots either to precede the first or to follow the last, lesson or meeting of the day.

Post:

A preference for unallocated time-slots to follow the last, lesson or meeting, of the day.

Meeting-time

Specifies the times when a group regularly meets; there is no facility to model a group which meets irregularly.

Subsequently one can use the Student Group-membership & Teacher Group-membership pages to define the group-membership.

Fields

Group-catalogue Id:

References the group, a meeting-time for which is to be specified.

Day:

Identifies a day on which this group meets.

Time-slot:

Identifies a time-slot within the specified Day, when this group meets.

Student Group-membership

Defines the student-bodies in a group.

Subsequently one can use the Meeting-time page to specify when the group-members regularly meet.

Fields

Student-body-register Id:

References a student-body in the current project.

Group-id:

References a group in the current project, of which the referenced student-body is to become a member.

Teacher Group-membership

Defines the teachers in a group.

Subsequently one can use the Meeting-time page to specify when the group-members regularly meet.

Fields

Teacher-register Id:

References a teacher in the current project.

Group-id:

References a group in the current project, of which the referenced teacher is to become a member.

Facility-type

Names arbitrary types of facility which may be available in any specific project; e.g. Desks, Blackboard, Gas-taps, Fume-cupboard, …

Subsequently one may use the Facility page to advertise the presence of this type of facility at various locations.

Fields

Facility-type Id:

Automatically assigned, globally unique, integral identifier for a type of Facility.

Facility-name:

A free-format string representing a type of facility which might support the tuition of a course.

Facility

References an attribute of a location, which may facilitate teaching.

Subsequently one may use the Required Facility page to mandate that a course is held in a location advertising specific Facility-types.

Fields

Location-catalogue Id:

References the location which offers this specific facility.

Facility-type Id:

References one of the types of facility defined in the Facility-type page.

Required Facility

References any equipment necessary to support a course.

Fields

Teacher-register Id:

References the teacher, who requires this Facility for one of their courses.

Topic:

References a topic offered in a teacher's Service.

Level:

References the Level of a Topic offered in a teacher's Service.

Facility-type Id:

References one of the facility-types defined in the Facility-type page, & therefore constrains the set of suitable locations for this course.

Student-body Membership

Defines a set of students, whose requirements are identical.

Fields

Student-body-register Id:

References the student-body of which this Student-id is a member.

Student-id:

Names one of the student-members of this student-body. Whilst one could pseudonymise this by using a matriculation-number, it must be meaningful to the intended observers of the solution.

Knowledge-requirement

Specifies a subject that the student-body is required to learn.

Fields

Student-body-register Id:

Identifies the student-body who has this knowledge-requirement.

Priority:

Either core or optional, depending on whether the student-body (teacher doing the configuration) considers this requirement to be critical.

Topic:

Level:

Must, when combined with the Topic, match one of the subjects defined in the courses, offered as a part of a teacher's service.

Service

Advertises the courses that each teacher offers.

Subsequently one can; use the Required Facility page to itemise any course-requirements, qualify it using the Specialty Topic page, or use the Knowledge-requirement page to add it to the set of subjects a student-body needs to learn.

Fields

Teacher-register Id:

Identifies the teacher from the current project, who offers this service.

Topic:

A free-format string representing the Topic to be taught. This value may subsequently be referenced in the Knowledge-requirements page for student-bodies.

Level:

A string representing the Level of the Topic to be taught. It's free-format, but may represent both the academic year & the learning-capability expected of students before they express interest. This value may subsequently be referenced in the Knowledge-requirements page for student-bodies.

Continuity of the teacher-student relationship, for the tuition of a specific course, may need to be guaranteed in the years leading up to examination. This can be implemented simply by requiring that those teachers offering such a course, specify a Level which includes a unique code. Student-bodies requesting this subject can then specify the unique Level corresponding to their teacher from the previous year.

Required Lessons-per-week:

The number of lessons regularly required per week for the tuition of this course; there is no facility to vary this from week to week (should it do so, a different timetable must be generated for each variant). Typically an integral multiple of Minimum Consecutive Lessons.

Ideal-timeslot request:

Optionally defines the ideal timeslot-id within any day, @ which to book a lesson in this course. This is a soft constraint, since no guarantee is given that it will be observed precisely.

Minimum Consecutive Lessons:

Optionally defines the minimum number of consecutive periods which must be booked for this course. This allows one to constrain the booking of lessons in Topics which either can't be conducted in a shorter time-span, or for which either long preparation or long clean-up makes short sessions infeasible. The specified value also represents an ideal duration, but if Required Lessons-per-week isn't an integral multiple of this value, then on @ least one occasion, this value must be exceeded.

Maximum Class-size:

Optionally defines the maximum number of students with whom the specified teacher can cope when teaching this course. In the absence of this attribute, the Capacity of the location in which the class is held, is the only limiting factor on class-size (given unlimited interest in this course).

Synchronisation-id:

Optionally identifies by means of a shared string, a set of courses offered by different teachers. whose lessons must be synchronised. In the absence of this attribute, the lessons for this course need not be synchronised with those of any other. Student-bodies may select only one member from such sets, but may migrate to a different member without disrupting the structure of the timetable, as required to implement an elective line.

Specialty Topic

Optionally defines the Topic amongst those to be offered in their Service, with which a teacher is most familiar.

Fields

Teacher-register Id:

References a teacher in the current project.

Topic:

References a topic offered in the above teacher's Service, in which they're considered a specialist.

Specific Time Request

Specifies a regular time each week, @ which one of the lessons of the referenced course should be booked. In contrast to Ideal-timeslot request, this is a hard-constraint which will only be ignored if zero lessons in this course are booked.

Fields

Teacher-register Id:

References a teacher in the current project.

Topic:

References a Topic offered in the above teacher's Service.

Level:

Specifies the Level of Topic.

Day:

The day on which a lesson of the course should be taught.

Time-slot:

The time-slot in the specified day @ which a lesson of the course should be taught.