At the UKOER phase 2 startup meeting the collection strand projects were asked to provide a short introduction saying what their collection was about, who it was for, where the material was coming from and what technical approach was being used. This is roughly what I said about Delores.
We are building static and dynamic collections of open educational resources for Engineering Design.
Engineering Design is the branch of engineering dealing with the design of all engineered products from clothes pegs to Concorde. It deals principally with creating something that will work in a way that satisfies the design need. The design process consists of a number of phases, starting with floating ideas about how the design need might be met, and ending with delivery of a complete and detailed description of the product to be manufactured, based on sound engineering concepts and principles.
The static collection will use a WordPress blog (not this one) to present resources that have been selected for their match to common elements of engineering design curricula from several UK universities.
Resources will come from UKOER projects, OpenLearn, OCWC, Jorum, Xpert, OCWSearch, OER Commons…anywhere we can find them. We will do one blog post per resource, either embedding the resource in the post or linking out to it (depending on nature of resource) and categorise it against topics from the curriculum. WordPress provides web presence, user interface, search + browse, RSS export, and metadata (Dublin core, OAI-ORE) either out-of-the-box or with suitable choice of plug-ins and theme.
The dynamic collection is technically much more interesting. We will draw on the same sources of OERs and use the same curriculum, but this time selection and classification will be automatic.
We will use the output of the JISC Bayesian Feed Filter project to aggregate and select resources. Bayesian filtering is the same process as many spam filters use, but we will be using it to recognise resources about design engineering on the basis of information from RSS feeds. Like a spam filter it needs to be trained with items that it is told how to classify: we will be using the resources from the static collection to show it what design engineering resources look like.
The Bayesian feed filter will produce an RSS feed of items that it thinks are about design engineering. This will be sent to some software developed at Bath called Waypoint.
Waypoint is an integrated search and retrieval system developed for accessing engineering documents (but generalizable to any document corpus) which has two main elements.
In the first element, the documents are organized against a set of classification schemes. This approach is known as facetted classification. The classification is automatic, being carried out using a standard constraint-based classification approach (using carefully selected classification rules) in which pre-coded sets of constraint are used to relate the textual content of each document with the particular topics or themes (characteristically technical and process topics) of interest.
The second element consists of a browsable user interface which provides the user with continuous feed-back of how the search is progressing based on the selections made and keywords used. The user interacts with the system by selecting facet categories of interest. As these are selected the hierarchical display is dynamically pruned to reflect the user’s selection in order to indicate which categories may be used to further refine the selection. This approach is known as Adaptive Content Matching, the effect of which is to present the user at all times with only that part of the classification structure that will lead to a non-null selection.
Waypoint is particularly suited as an interface for students searching for pre-classified educational resources as it allows exploration of the search space in a rewarding way.
It is very intuitive to use, and because of the facetted classification and ACM approaches means that the user is not frustrated by the system merely returning an empty set.
There was some discussion about the relative merits of Blogs and a Wikis as hosts for the static collection. I wouldn’t criticise anyone for choosing to use a wiki for work similar to this, but to my mind the advantage of a wordpress blog: are that the category approach gives good navigation and provides sub-collections (with RSS feeds); the develop community is good, there are plugins for just about anything you might want to do; and the backup/export/migration features are solid. Wikis I think might be better if you want more flexibility in presenting views on parts of your collection (for example wikipedia’s portals) rather than simple list by category and if you want collaborative editting of content, with changelogs, rollback etc.