Institute for Learning and Research Technology
A technical report: Re-packaging tutorials from the RDN Virtual Training Suite to create new VLE compliant learning objects
Author Paul Smith
Date 21 October 2003
Document Name wp3_technical_report.doc
Summary
This report presents research into repackaging of tutorials from the RDN Virtual Training Suite as re-usable learning objects suitable for use in virtual learning environments and learning object repositories.
It describes the methodologies used to create the objects, including discussion of the appropriate technical specifications and standards; issues of maintaining currency, intellectual property and copyright; issues of presentation and use within virtual learning environments; and the technical processes used to create the objects.
The report discusses the results of testing the resulting learning objects with the X4L Strand B repositories and tools, and the results of testing with a number of virtual learning environments.
This report details work carried out as part of a JISC X4L project that investigated how the RDN Virtual Training Suite could be repurposed to optimise use in taught courses and Virtual Learning Environments (VLEs). The project Web site contains an overview of the project:
http://www.vts.rdn.ac.uk/x4l/
The main aim of this work was to investigate the repurposing of the Virtual Training Suite (VTS) to create learning objects, suitable for reuse within Virtual Learning Environments. As part of this work, we would be looking to:
Investigate the 'chunking' and re-packaging of existing VTS tutorials to create new VLE compliant learning objects (in line with existing and emerging standards/specifications/profiles such as IMS / SCORM / LOM)
Investigate the best way to 'plug-in' VTS tutorials into different VLE software packages
Share the technical and pedagogic solutions developed with the wider community
Other X4L projects (in Strand B) would be creating tools and toolkits to enable the creation of learning objects, and it was our intention to make use of these tools during our project lifetime, and feedback in to the development of the JORUM repository and its tools as much as possible from the experiences and requirements emerging from our own research and developments.
The RDN Virtual Training Suite has been in existence since June 2000, and currently consists of 61 'teach yourself' tutorials on the Web, designed to teach Internet information skills for different subjects taught in universities and colleges. The suite contained purely HE targeted tutorials until June 2002 when 11 new tutorials were published, each designed to meet the needs of FE and in particular to support the development of key skills in ICT. This group of 11 FE tutorials has now been augmented with the addition of 5 new tutorials, resulting from the re-purposing of 5 HE subject tutorials as part of this project.
Web statistics and user feedback indicate that the RDN Virtual Training Suite is a highly popular JISC resource, yet its uptake in teaching programmes and VLEs is still in the early stages. A further aim of this project was to maximise the investment placed in the development of this resource by offering teachers and lecturers tools and techniques to embed the VTS that could be quickly and easily adopted in a range of courses and VLEs, and to promote speedy and widespread adoption in FE and HE courses across the country.
The whole subject of 'learning objects' is a minefield of misunderstanding and confusion. The most common question throughout this project has seemed to be "Yes, but what is a learning object?" It is a very difficult question to which you cannot give a succinct answer; a point emphasised by the fact that the question is still being asked, and outside of the boundaries of the X4L project as well.
The Learning Object Metadata (LOM) standard from the Institute of Electrical and Electronics Engineers (IEEE) states that a learning object is defined as:
"any entity, digital or non-digital, that may be used for learning, education or training."
Rather than clarifying, this definition is (deliberately?) vague allowing full scope for anything to be defined as a learning object, be it a page from a book, a Web site on 14th century Economics in Norway, a photograph of a tree, an actual tree, or a snippet of Java code.
Another definition of learning objects is:
"A learning object is simply a collection of resources that are combined with a learning design to meet a small and well specified set of learning objectives."
(http://www2.warwick.ac.uk/services/its/elab/research/elearning/lob/)
This definition, rather than suggesting that a learning object is a single "entity", introduces the concept of a collection of resources, or entities combined with a design. This is the first step towards the aggregation of entities to form learning objects - a theme we will address again later. This definition also describes what you can do with a learning object, in addition to what it actually is. This suggests that the emphasis should be placed more on not actually what the learning object actually is, but what you do with it; or more accurately, the intended use of the object.
But for the purposes of this project, we will be using the definition put forward as part of the (currently draft) UK LOM CORE application profile:
"An aggregation of digital assets that represents an educationally meaningful stand-alone unit."
The "educationally meaningful stand-alone unit" element is the important bit here. This suggests that learning objects should be functional groups of assets that could be used on their own, or could be used within a different context, without jeopardising the usefulness of the material. These learning objects could also be aggregated together to form further learning objects; again which could be used in isolation, or aggregated still further.
The following list is a distilled list of the problems and issues we would need to address throughout this work, and maps to the various approaches discussed in more detail within Section 3. We had pretty much decided at the start of the project that we were going to produce our own pre-packaged materials directly from the Virtual Training Suite, rather than relying on the tools resulting from Strand B of the project. The reasons for this are discussed in section 3.3.3.
Research and discovery in to the various standards, specifications and implementations of educational metadata and content packaging.
Deciding on which elements of the LOM to implement.
Deciding on our approach to granularity levels and aggregation of the learning objects we would produce.
Exposing, and (where necessary adding to) the metadata already held within our tutorial content management system, with a view to creating a local 'repository' of learning objects/content packages.
Addressing various technical and navigation issues resulting from potential disaggregation of tutorial materials
Ensuring that the learning objects we produced would be interoperable with the respository tools being created in parallel as part of the Strand B projects.
Testing interoperability between our learning objects and the various VLEs we intended to test against as part of this project.
We began our project by trying to bring together as many interested parties as possible for a consultation exercise, in order to gain expert advice on what we should be looking to achieve. We were new to the whole idea of creating learning objects, and therefore were looking for help in identifying how we should be approaching the task of repurposing the existing tutorial materials for use within VLEs and the Strand B repositories.
The notes from this meeting are available from our project Web site at:
http://www.vts.rdn.ac.uk/x4l/consultation_day_notes.doc
but the following is a brief summary of questions raised, and the resulting decisions.
The main question here was 'how can the embedding of the VTS into VLEs support teaching and learning?'.
Discussions ranged from how we can encourage the use of the VTS within VLEs, and to what extent granularity of the tutorials would affect uptake and use within these environments. The issue of dynamic vs. static materials surfaced during this discussion in relation to quality control, and also how we could encourage the uptake of materials, which were volatile in their nature.
The main outcome from this discussion was that we would use this area of the project to experiment with trying different levels of 'chunking' or disaggregation of the tutorials, and seeing how these various learning objects behaved within VLEs.
The main thrust of this discussion was how we should (if at all) disaggregate the tutorials for use within VLEs: should we be 'chunking' at the tutorial, chapter, page or other level. Related to this, however, was the technical issue that the tutorials will be updated on a fairly regular basis, and as such it would make more sense not to create off-line versions of materials that will change frequently over time.
It was agreed that low granularity would give most flexibility in terms of allowing teachers to aggregate small sections (individual pages) of the VTS with other materials to create more complex learning objects. However, it also became obvious that this type of approach would carry overheads in terms of maintaining additional versions of the materials. There was a suggestion that we experiment with creating both offline and live objects, which could subsequently be tested within VLEs.
The main question was whether we should be aiming to use standards/specification which were current at the time of starting the project, or whether we should attempt to accommodate emerging standards as well.
It was decided that we should really be using standards as they are now, and that we should use IMS Content Packaging and associated metadata. Strand B projects would be adhering to these standards too, but these tools would not be available until well into the lifetime of our project.
The main concern expressed here, was that VLEs tend to embed third party materials within frame sets, which can affect the appearance and functionality of the embedded resource. Our question, was whether we should consider forcing our materials to not work in framed environments, or should we redesign our materials so that they would work happily within any third party hosting environment.
There was no real consensus on this, except to say that we should not try and determine how our materials should work within other environments - in fact we should try and accommodate use in VLEs and equivalent tools so that we are not imposing our structure on them.
As the VTS was created without thought for creating reusable learning objects, there is no facility inbuilt for branding, or IPR, and we had concerns that (despite copyright being held with the University of Bristol) authors of the tutorials may be unhappy that we simply make their materials available as learning objects for other people to modify for their own use.
It was decided that by use of metadata, and an acceptable use policy that we could (at least on paper) safeguard the use of the tutorial materials. There was also discussion of a charging policy for non UK academic use, or some authorisation/registration facility at the Research Discovery Network (RDN) level (the organisation of which the VTS is a service).
This discussion was intended to elicit opinion on the best targets for disseminating information about the results of this project.
Several mailing lists, and other avenues of dissemination were suggested, including the option of making any guidelines into learning objects for upload to the Strand B repositories for further exposure.
To extend knowledge and to make use of all available expertise, our technical team attended various meetings and seminars, including IMS Special Briefings, CETIS Special Interest Groups, and also signed up to appropriate CETIS mailing lists (ECSIG, and MDSIG). During the project, one of the team also attended the WWW2003 Conference, Budapest, Hungary (as part of another project) at which several sessions on learning objects were attended.
The knowledge and experience gained helped decide on the direction we would take with reference to granularity levels of the learning objects we would produce, and also the technical architecture supporting them.
One of the main objectives was to produce reusable learning objects. Much thought had gone into achieving this goal, and the following is a description of the processes and justification for much of the work that was to follow.
The decision on how to package the Virtual Training Suite (VTS) for the X4L project was a long time in the making. The original intention at the start of the project was to create highly granular 'chunks' of the tutorials so that learning objects could be made from the smallest granular element of the tutorials, say, a single quiz question or a paragraph of text, or at the other extreme, entire tutorials could be used.
It soon became obvious, however, that there were several reasons why this approach would not be possible, or indeed sensible. The following describes the thoughts and reasoning behind the ultimate decision not to chunk the tutorials at all, but create resource 'stubs' which instead of packing the actual tutorial content, would create a metadata package for each of the tutorials, which would remain on the hosting server - we term this metadata packages metadata 'stubs', or Web objects. Each 'stub' would fully describe each tutorial, and maintain a link to that resource.
The tutorials are maintained and regularly updated by a distributed team of the RDN hubs in order to prevent content and especially Web links becoming outdated. This means that any tutorial materials packaged and published separately could soon become outdated, and with the nature of the Internet, publishing out of date information or advice would devalue the material, and reduce the effectiveness of the tutorials.
There are several technical reasons that make producing granular, or chunked tutorials difficult. The content management system (CMS), which is the engine behind the VTS, was not designed to accommodate the requirement of being able to segment the tutorials and deliver individual sections for repackaging/reaggregation. All the tutorials are built dynamically on demand from database requests, and so a tutorial does not exist natively in an easily packageable form. Coupled with this, the navigation is built dynamically from the tutorial content structure, and so it would not be easily disassociated from the content itself. As the content is stored completely within a database, therein also lies the problem of creating packaged content in the first place. A new software system would have to be designed and implemented in order to create content files, which could subsequently be saved and packaged. This sort of technical development was beyond the scope and resources of this project.
VTS content is owned by and is the copyright of the University of Bristol. This means that without explicit sign off for each and every instance of change, we would be unable to redistribute the materials as small chunks, which could then be easily changed and re-branded.
Even though the metadata schemas and application profiles support and include copyright information, by putting these materials into the public domain, we would not be able to easily track the usage and proliferation of materials originating from the Virtual Training Suite.
The pedagogic design of the tutorials was done prior to X4L and so did not cater for division into discrete learning objects. The tutorials are predominantly composed of four main sections, or chapters, and at first glance, it would appear that the tutorials can be easily 'chunked' to at least these four sections. This would mean that taking a section from multiple tutorials, or putting together multiple chapters of the same type could make up 'new' tutorials. However, it became obvious that this was not possible without much reworking of the tutorials as many of the sections make reference either to material the user will come across in further or preceding sections. So, whilst the tutorials do on the surface appear to have a reasonably non-linear and granular structure, in reality many of the sections are tightly integrated with other sections, and as such are not suitable to be separated.
In addition, it was realised that the notion that the quiz questions could be used outside of the context of the tutorials was erroneous. Many of the quiz questions are explicitly included to reinforce learning objectives from the preceding sections of the tutorials. Therefore, prior exposure to material from that section, or very similar to it would be required in order to prepare the user to answer the questions. The context-sensitive and pedagogical dependence of the quiz questions does not make them particularly good candidates for use as standalone learning objects or ‘granules’.
One of the main features of the tutorials is the 'Links Basket' feature, which again is tightly integrated into the content. It would not be possible to utilise this feature in any externally packaged content.
So, in the end, we decided not to attempt to disaggregate the tutorials at all; instead, treating each tutorial as an individual learning object. This does not break the model of a learning object, which as defined above is:
"An aggregation of digital assets that represents an educationally meaningful stand-alone unit."
By creating metadata packages, which, rather than containing the content itself, are linking directly to that resource, we are creating learning objects which fit this definition. The only slight discrepancy is that by suggesting that a learning object should be an aggregation of assets, by implication, it should be able to be disaggregated. However, as we are creating Web objects this is not so relevant.
At the start of the project, we were completely bemused by the possibilities as far as standards, specifications, reference models and application profiles - each of which would appear to have some relevance to the work we were planning. The options included implementing the Sharable Content Object Reference Model (SCORM) for runtime integration with VLEs; Question & Test Interoperability (QTI) to provide some integration for the quiz sections of the tutorials; and of course the LOM standard from the IEEE. With rumours of a UK education-specific implementation of the LOM being developed (soon to be revealed as the draft UK LOM CORE), it seemed sensible to try and make our objects work with the LOM, thereby inherently working with any profile of the LOM.
The VTS is managed from within a bespoke content management system (CMS), which maintains all the relevant data within a database, and the tutorials are subsequently served dynamically on demand. Because of this, metadata describing each tutorial is already in existence, and it seemed a waste of effort to duplicate this metadata in order to create the content packages. Therefore, it was decided that rather than use one of the Strand B tools (namely RELOAD - still in development at this stage of our project, or direct entry into the repository tools - again, still in development at the time of writing) we would create packages directly from the data we held within our CMS.
About one third of the metadata was already held within the VTS system, and so we developed the CMS to annotate the tutorials with the rest of the metadata unique to each of the tutorials. A smaller percentage of the metadata would be the same across all of the tutorials, and so this could be added during the package building phase, rather than embedding this within each tutorial - again, to avoid duplication. A breakdown of the metadata and its source is included in the appendices.
When the first draft of the UK LOM CORE became available, discussions on the CETIS Metadata Special Interest Group suggested that the proposed mandatory elements within the UK LOM CORE actually mapped directly to Dublin Core. So, one of the first things we did, was to append Dublin Core metadata to our tutorial pages in the few places where it missing, so at this point, we were complying with the mandatory fields of the UK LOM CORE. However, our intention had been to comply with the complete LOM standard, so this required adding some additional metadata to the tutorials, but mainly adding generic metadata at the time of package creation.
As already mentioned, the metadata with which to create the LOM data was either already contained within the tutorial database, or was generic data applicable to all tutorials, or would be created dynamically by the repository on the final upload of these materials.
Building the appropriate manifests for the LOM was relatively easy, but turning this into a valid content package involved more work. In order to create electronic content packages, a binding was required. As we were using the LOM, it made sense to look for a LOM XML binding, but it soon became evident that this was not ready, and indeed was far from being in a state that would be useful to our project. Instead, we opted to use the IMS Content Packaging XML binding, which although not being exactly the same, was good enough to map to the metadata we had, and would also be supported by the repositories. So, we pressed on with creating IMS manifests using the IMS Content Packaging XML binding. This was aided by use of various sets of documentation from IMS, including the 'IMS Content Packaging Best Practice Guide'; the 'IMS Content Packaging XML Binding'; and the 'IMS Content Packaging Information Model' booklets.
We also made use of tools that were available to create sample content packages in order to get hints on implementation issues, including fledgling versions of the RELOAD tool.
According to the UK LOM CORE, each learning object should have two identifiers, one for the object (1.1 general.identifier) and one for the metadata record (3.1 metaMetadata.identifier) and each will have their own catalog name and entry. This is a problem, because exactly what kind of identifiers will be used is an unresolved issue that is currently being discussed by various people including UKOLN and the CETIS Metadata SIG. As we made the decision to produce our packages directly from our CMS, it is our responsibility to produce unique identifiers, whereas had we been creating our packages within one of the Strand B tools, this would have been taken care of automatically by these tools.
We had originally interpreted the repository guidelines for Strand B tools to suggest that they would provide unique identifiers on upload of materials to the repository, but a paper by Andy Powell of UKOLN ("Identifiers for learning objects - a discussion paper" - http://www.ukoln.ac.uk/distributed-systems/lo-identifiers/) suggests:
" assignment [of an identifier] should be independent of the process of depositing the learning object in a repository. For example, if a person creates a learning object on their PC [they don't] want the repository to assign a different identifier to the object and metadata when they deposit them: nor do they want to have to wait until the point of deposit before they can assign an identifier."
As this work is still under discussion, and no clear guidelines are in place at the time of writing, or timely for this project, we have sidestepped this issue.
Package generation was the quick part! Simply running the script against the database quickly trawls all the tutorials, and creates individual, Zip archives in a few seconds. These packages are then ready for upload into a target repository or VLE.
The X4L programme commissioned two trial learning object respositories.
intraLibrary was the first repository to come online, and so was used the most during the lifetime of our project. There was initial concern that we would be unable to upload our metadata-only content packages, but support was available with the ability to upload packages to the system. Initial teething problems, however, such as being unable to access the 'advanced metadata editor' made verification that our content packages were actually correctly uploaded impossible, so until this was addressed, we could not judge our success.
As our learning objects / content packages are pre-built using our own 'toolkit', the interaction with intraLibrary is minimal. There is no requirement to use the supplied metadata editor for data input. We simply upload the packages using the ‘Upload Area’; a process that takes about 10-15 seconds per tutorial. The generation of all tutorial packages (61 tutorials) takes under 1 minute, so potentially all tutorials could easily be uploaded within 1 hour. Comparatively, it takes at least 10-20 minutes to enter all the data into IntraLibrary using the metadata editor screens (we did do a few tests for comparison), assuming you have appropriate data available beforehand. Therefore, our ‘ready made’ packages save a lot of time!
However, having loaded the packages, you are then required to catalogue each of them before they can be published, which is a further time consuming task. As the packages already contain metadata based on the Dewey classification system, it seems like repetition of effort to assign further metadata to these packages within a proprietary catalogue such as that supplied with intraLibrary. This is discussed in more depth in the "Results and Discussion" section of this report.
Much like intraLibrary, interaction with Xtensis for our project was minimal - limited to simply uploading materials into the repository.
Some problems were found in that Xtensis was very explicit in its distinction between what it terms Content Objects and Web Objects. Technically, we are producing Web Objects, but by producing objects that were 'unique' to Xtensis, we found that these would not work in Intralibrary. This non-interoperation issue was a worry, and as we wanted to produce objects that would work in any repository or VLE, it seemed a problem that objects that were created in line with IMS specifications would not import successfully into one of the test repositories.
Despite the fact that we were not intending to use RELOAD for the creation of our learning objects, it seemed a worthwhile exercise to ensure that the content packages we were producing did at least load successfully into the RELOAD tool, in case future users were intending to use the 'Annotation' feature of the learning objects. Obviously, with RELOAD being in a 'beta' state for the lifetime of our project, it was hard to judge the success, but on the whole materials produced from the VTS content management system could successfully be imported into RELOAD.
RELOAD also turned out to be a great tool for creating blueprints of the manifests we were attempting to create from our CMS. By creating sample manifests, and then using these as a template for the XML we were automatically creating, we were able to ensure that we were producing valid manifests that should adhere to relevant specifications.
Our intention with this part of the work package was where possible, to import our content packages into a VLE, and then test the resulting materials.
We tested against two instances of BlackBoard 5 - one with and one without the SCORM Building Block in place. We also tested with BlackBoard 6, both using the 'upload package' tool, and also by uploading our packages as Microsoft LRN packages.
We were able to test with WebCT 4.1 with help from Mark Power of CETIS.
Although intending to test against the FD Learning and Granada systems, we were unable to secure access to a suitable system and so these were not tested.
This section will describe the results of attempts to upload our 'content packages' to various VLEs available to us during this project. The appendices include more detailed reports of each of the attempts.
We made several attempts at uploading our packages to three different versions of Blackboard.
BlackBoard 5 - no additional 'plug-ins'
We were able to load the packages into BlackBoard, but viewing the materials resulted in an attempt to render the imsmanifest.xml file within the browser window. This is not surprising, with no IMS import filter built in, there was no chance that BlackBoard would know what to do with these packages.
BlackBoard 5 - SCORM Building Block installed
This was marginally more successful. The package could be imported as a SCORM compliant object, and an appropriate link was then created within the course. However, following this link resulted in the user being told that they had completed the course. No content was displayed (in this case, no tutorial was linked to).
Theories on the reasons for lack of content display were developed during this testing, but mainly during the testing in WebCT. These theories are discussed and elaborated upon in the section on WebCT (4.1.2)
See Appendices for a step by step account of this testing.
BlackBoard 6 - attempt to load packages as Microsoft LRN packages
It had been suggested that BlackBoard could successfully import and display IMS packages if they had been first prepared as Microsoft LRN packages - a function supported within BlackBoard. So, using the LRN Toolkit, we converted our materials to LRN packages (which could be successfully viewed and used within the LRN Viewer). We then attempted to load these packages into BlackBoard as LRN packages. The import was successful, but attempting to view these resulted in errors (file unavailable). After some further testing, and consultation of BlackBoard support Web site, it was concluded that this feature was currently broken in BlackBoard 6, and would be fixed sometime. Due to this, we were unable to conclude whether our packages could successfully be imported and subsequently used within BlackBoard 6.
During intial testing of our packages with WebCT and BlackBoard, we had not used the ORGANISATIONS structure within our manifest files. Initial testing with WebCT allowed importing of packages, but no links to content were evident. Using RELOAD, Mark Power (who was testing on WebCT for us) added ORGANISATION detail to our manifests, and retried importing the packages to the WebCT server. This time, a link to the content was available, but clicking on it did nothing - similar behaviour to that seen in BlackBoard 5 with SCORM capability.
See Appendices for a step by step account of this testing.
It appears that by not having any physical content within the package, and simply holding metadata linking to external resources - ie creating a "resource stub" or "web object" - is not supported within the VLEs we tested against.
In a way, this makes sense - why would you go to the trouble of importing such a package into a VLE when you could simply cut and paste a URL as a Web link within your VLE and achieve the same result. Having metadata within a repository for such resources is useful, if you want to search on first level metadata such as author, subject, etc, but we would suggest that there is a fine line here, as to whether these repositories are to become simply metadata repositories, or repositories holding useful resources in terms of learning objects - actual physical objects; aggregations of other resources and assets which can be reused and shared, rather than a collection of well described links - a facility already provided by already established services within the RDN and LTSN initiatives.
As a general comment, results of using the repositories with our content "stubs" was successful, in terms of the packages could be uploaded to them. However, the fact that we did not have any actual content within them led to similar problems found with the VLEs - the package would upload, but display within the repository was not always correct, and some metadata, whilst supplied would not be exposed with the repository, and would also not be exported properly.
Intralibrary would accept our packages without problem if we built them to the template of an object initially defined within Intralibrary - these had to be created as Virtual Objects. If we used packages created by using the template derived from RELOAD - created as universal content packages, then the package would import apparently correctly, but metadata would be missing.
Again, Xtensis would successfully import our objects, but would exclude certain metadata. Metadata created using a template derived from native Xtensis objects would import correctly (these were created as Web Objects).
As with the VLE testing, it appears that trying to create generic IMS content packages that do not contain anything other than metadata makes for problematic importing into these repositories. Neither repository appears to support the import of virtual or web objects, although both support their creation.
It would therefore appear, that whilst it is completely possible to create a content free content package, the reuse of such a package is severely limited.
Another issue is that both repositories require the user to be online in order to do anything with either package. Whilst most users can arrange Internet access, not everyone can arrange time to do this sort of work online for long periods of time. The big plus point in favour of RELOAD is that it can be run offline, and then uploaded into a repository at a later time. In conflict with this, however, is the re-cataloguing requirement of Intralibrary.
There was a deliberate initiative within this project to try and automatically create content packages from existing metadata, and without the need for additional tools, such as those within the JORUM repositories, or with the RELOAD tool. The reasoning behind this was twofold:
We already had the data in a machine-readable format, and it seemed slightly pointless to recreate this all manually when it was could be easily repurposed.
We were expanding upon a theory that most non-technical, or catalogue trained staff would be unlikely to spend time entering metadata against their learning objects, and so we decided to test how easy it would be to create metadata from existing resources, and bypass the "electronic form" in creating descriptive resource metadata.
On the whole, we were successful. We were able to create metadata packages by exposing our existing metadata, and by adding a few additional key fields. Our intention to implement the complete set of LOM compliant metadata was also successful, although as stated previously, we did not attempt to create unique identifiers due to the lack of central direction on which schema to use, and it did not seem as important to this part of the project.
One of the main conclusions to come out of this part of the project is that it is very hard to produce learning objects from existing, established materials that were not designed with reuse in mind from the outset. This was ultimately the main reason behind not attempting to disaggregate the tutorials - the time and effort required to rework the tutorial CMS in order to create "chunks" suitable for aggregation was prohibitive (aside from the issues of IPR and maintenance). From talking to other 5/99 projects, it appears that this is a common theme, and that most if not all have gone for the same "content stub" or "Web object" approach.
However, our findings would suggest that these stubs are not the best solution. The stubs we created, when tested against two of the more popular VLEs, proved not to work (or at least no content was displayed within the VLE pages). If the creation of web / virtual objects is to be promoted, further effort would appear to be needed in their support at the repository level - be the repository VLE or other such storage platform. However, from our experience, the best and most used 'repository' for the VTS is Google, and other RDN services are also great sources for linking to and from the VTS. Resource discovery should not be seen as a sole reason for inclusion in learning object repositories (although it would obviously be very useful for specific materials which are not suitable for discovery by tools such as Google).
It is debatable as to whether the creation and distribution of learning objects is required to extend the use of resources such as the Virtual Training Suite. Our usage statistics and feedback forms suggest that the tutorials are very widely used in a variety of environments and systems, and indeed many institutions are already embedding the VTS tutorials into their VLEs and course materials. Requests to reuse materials from the tutorials are received very rarely, which also supports the decision to not break up the tutorials. When requests are received, it is usually to repurpose a complete tutorial for reasons of language, which would involve rewriting the complete tutorial - something not particularly suited to learning object technology. The document "Guidelines for including the RDN Virtual Training Suite within Virtual Learning Environments (VLEs)" (available from http://www.vts.rdn.ac.uk/teachers/) which was a further deliverable for this project gives instructions and suggestions on how to embed the VTS within a VLE from a pedagogic perspective, so hopefully this will encourage more users to do exactly that.
Finally, the success of our auto-creation of objects proved that using a toolkit such as RELOAD that relies on interactive metadata creation is not always required. Despite the fact that it required quite a heavy technical involvement to create our objects from scratch, the resulting technology for creating the manifests is actually fairly reusable - all it requires is a data source, which means that this system could potentially be usable on any resource where suitable metadata is already held within the resource. This would mean (with substantial further development!) that ultimately users could create objects from their materials without having to recreate all their metadata from scratch.
The work for the two work packages was done by:
Paul Smith, ILRT, University of Bristol. Responsible for:
Co-planning the Consultation Day in WP3
Technical work in chunking VTS into learning objects as per functional specification decided at the consultation day
Supporting LTSS at Bristol on test bed implementation of VTS learning objects in Blackboard in WP 4
Collating/writing technical guidelines on embedding VTS into VLEs for WP 5
Mark Williams, Reading College (+ Reading staff). Responsible for:
Co-planning the Consultation Day in WP3
Technical work in chunking VTS into learning objects as per functional specification decided at the consultation day
Test bed implementation of VTS learning objects in Fretwell Downing, WebCT and Granada LearnWise in WP 4
Collating/writing technical guidelines on embedding VTS into VLEs for WP 5 (With Paul Smith)
Dissemination of project outputs with ILRT staff
Andy Ramsden, LTSS, University of Bristol. Responsible for:
Test bed implementation of VTS learning objects in Blackboard in WP 4
Mark Power, CETIS, Bolton Institute:
Test bed implementation of VTS learning objects in WebCT in WP 4
Reading College is not currently using a Scorm Compliant VLE. Therefore the content packages ICT, Medic and Physics were tested on Thames Valley University’s Blackboard VLE which has the Blackboard Scorm plug-in installed (free for licensed users). All packages were uploaded with the same outcome.
The process for uploading:
Log in to Blackboard as a Course Author Tutor.
Choose a course
Choose Control Panel
Choose Course Documents
Choose Add Other
Select Scorm Content
Enter a Title
Browse for .zip content package file
Choose Options as below:
Click Submit - content is successfully added.
To View Materials:
Choose the course
Choose Course Documents
Choose Click for Course
The outcome is shown below:
(testing and report by Mark Power, X4L Support, Centre for Educational Technology Interoperability Standards (CETIS), Bolton Institute
WebCT 4.1 has an option for users to import IMS Content Packages using the ‘manage course’ page in Designer View.
There were several findings that came out of importing the VTS medic package that I’ve covered below, including screenshots
1. The original Content Package
The original package contains one resource (externally referenced) with no Organizations.
Opened in RELOAD it looks like this:
2. Importing the package
In Designer View, the user clicks on the link for ‘Manage Course’ and sees the following screen:
then.
‘Import a Content Package’ is selected, title added, etc.
‘Package type’ is selected as ‘Other’ as the content package has been created using a 3rd party packaging tool. The other option on this drop-down list is ‘WebCT’
Selecting the file to import goes as follows:
Once the zip file is selected and imported we get the following confirmation screen:
NOTE: Every package I’ve created an imported throws up the warning about the package type not being determined so imported as WebCT package type.
3. Viewing the content
Now this is the fun bit.
Homepage displays as:
So the icon for VTS Medic test 1 displays (you can also select to display it on the left hand Course Menu) but clicking on the icon gives you:
As WebCT obviously reads the Organizations to create the table of contents but this package doesn’t contain organizations there is no way to actually view the tutorial. So basically, plugging a [virtual] package of this type into WebCT is pointless really as the student won’t be able to access the resource.
Following on from this I rejigged the package in Reload so that it contained an item within an organization that referenced the resource (shown below).
I then imported this following the same steps as above calling it VTS Medic test 2.
Excellent stuff. The link to the resource now appears on the Table of Contents page.so..
So WebCT doesn’t like ‘virtual’ packages then. Hardly surprising really as there isn’t actually any content being imported and because WebCT, like most VLEs tracks the student’s progress through the course it classes the pages it tracks as ‘Content Modules’ which must be files on the server (I think it’s something along these lines anyway!).
Seeing as importing a content package of this type to WebCT isn’t really going to do the job you want the way I see it is that the person downloading your resource from the repository wouldn’t export the content package and import that into the VLE in the way that I’ve just done but export the URL for the resource (NOTE: I have just gone into intraLibrary to do this - and get a screenshot - but the option of ‘export as URL’ is no longer there when you select to export a learning object) and then put the URL of the tutorial into the VLE like thus
(the icon can be changed to either look the same as the others - rucksack - or customised ones)whatever it is the result is the same..
