Methodology
The project was divided into two parts: an analysis phase
followed by an implementation phase.
Analysis
The purpose of the analysis was to gather information from different sources about units and courses and to identify the terminology used in these descriptions. A major task in the description of units is to correctly define their relationships in terms of dependencies between units. In order to find out what the authors of unit descriptions wanted to express in the prerequisites, corequisites and prohibitions entries of a unit description, which contain information about the dependencies between units, a program was developed which accesses the online unit catalogue and analyzes the single unit descriptions. The main result of this analysis is that a mixture of notations (boolean expressions and mainly natural language sentences) is currently used, often leading to ambiguities and inconsistencies due to wrong usage (e.g., missing parentheses in boolean expressions). Another problem is the existing tradeoff between inclusive or and exclusive or when both notations are mixed.
As the course descriptions do currently not have a common
document structure, an automatic analysis with the help of a
program could not be performed. The outcomes of a manual
analysis are that course descriptions define the framework
which describes how the building blocks of courses, the
units, can be combined. As well, a course description must
list the compulsory units of a course, elective units and how
these must be chosen in the context of the course, and also
rules for specialization in specific areas as well as general
rules for course completion.
The following implementation phase was based on the results of the analysis.
Implementation
The idea in our approach to formally specifying unit and
course structures is to capture a fact - or a set of facts -
by an XML construct or document. This XML document can then
be validated using an XML Schema to ensure that the syntax is
correct. Furthermore, the validation ensures that the
validated XML document contains a certain degree of
information. From the XML document, a number of other data
formats can be generated by performing XSL transformations.
Figure 1 shows this general relationship between the XML
documents (or constructs), XML Schemas and XSL
transformations. Note that this apporach is open to future
developments.
Figure 1: General approach
For the central XML constructs and documents, two possible
XSL transformations were developed:
- Transformation of a specific construct to an HTML document.
- Transformation of a specific construct to a Prolog fact
or term.
The result of the first transformation, an HTML document,
is obviously for online presentation purposes. The result of
the second transformation, the Prolog fact, is intended to be
used in Prolog programs which compute answers to interesting
questions. The definition of facts at a central point, i.e.,
for each fact a single XML construct or document, has one
major advantage: There will be no inconsistencies among the
different usages of this fact, because the usages are
derivations, by XSL transformations, from the central
definition of the fact.
For details on the implementation of the single constructs and documents see Implementations.
Copyright © Patrick Frey