Talk:Repositories

Hi Jerome, you asked for comments on this last week, about: 'They are set hidden by default, so you can edit them without impacting users.'

I find this really unfriendly - especially if there are no settings to change. I think a nicer workflow is needed. --Dan Poltawski 22:13, 6 May 2009 (UTC)

Any chance of any help on what the different repositories do? Especially the "built in" ones. They are not obvious. What's the difference between Server files and Upload files for example? --Howard Miller 14:30, 30 July 2010 (UTC)

Hi, I work on the ICE system at USQ (http://ice.usq.edu.au) and for the CAIRSS Institutional Repostiories Support service.

I think the idea of having repository plugins is great, but I have two main concerns about how this will work, both really about the notion of compound documents.

1. Typical Institutional Repositories (IR) like ePrints or DSpace are not really based on files, rather they have digital objects which consist of some metadata and a number of data streams, the typical entry point is a metadata summary page with links to datastreams (files). Too often for IR systems just contain a set of PDF files, but they could have HTML and associated images etc. I am wondering how this model would be supported in Moodle? When linking to a DSpace item, say a research paper would Moodle show a metadata page with links back to the repository? If the metadata page is a node is there some notion of being able to import sub-nodes?

2. Our work with ICE is all about providing multiple renditions of the same content item. At USQ we work with long-form distance education materials, so we usually start with a word processing document which we convert to HTML (plus images etc) and PDF, and sometimes other renditions such as an HTML slide-presentation automatically derived from the main points of the document. Thus a single ICE document could consist of a bundle of dozens of files. What would be the best way to hook this into Moodle? One way that occurs to me would be to package compound documents as IMS content packages which Moodle could unpack and serve-up (preferably with each different part being addressable by a URL.) ICE also bundles entire sets of courseware as IMS packages.

There is a formal way describe compound documents using the Object Reuse and Embedding standard from OAI (OAI-ORE), but that might be a bit complex for the kind of integration you want here, using IMS packages would mean complex objects can be treated as files, and when unpacked the Organization file in the package would describe the entry-point.

Peter Sefton - University of Southern Queensland

First, can I just point out that you seem to be someone who spends all his time thinking about 'Repositories', so for you the word repositories probably comes with an awful lot of existing baggage. Please may sure you are correctly understanding what Moodle repository plugins are, and are not. (I hope that was not patronising.)

OK, so to start with, Moodle can cope with aggregates, for example SCORM packages, IMS packages, and so on. The basic convention is to use a zip file to bundle them, with some sort of metadata (e.g. imsmanifst.xml) in the zip. Moodle can cope with that. For example, if you add a 'File' to a Moodle 2.0 course, it can be a set of linked HTML documents with images. You can upload them all, either by uploading a zip, and then unzipping, or by uploading them one at a time. You then designate one of the files as the 'main' file, that is, the entry point.

So, basically, you can say that Moodle the core Moodle files API and repository API provides a relatively low level of infrastructure for handing files and groups of files, and then various higher level things can use that, like the SCORM module, and IMS content package resource, can build on that. Rather line the internet is built on DNS and TCP/IP, and then various higher-level services like HTTP, FTP, email, instant messaging, and so on, build on top of that. (I'm not sure that this is a great analogy.)

So, coming on to your second point, you seem to be describing a fairly sophisticated, high-level approach to content management, and you should not necessarily expect Moodle to support that out of the box. There are really two approaches you could take. Either you could work at the repository end, and reformat the data there so that it fits into one of the functionality that Moodle already supports; or you could write a plugin at the Moodle end that takes your data as it is, and displays it the way you want in Moodle. Either way, one would hope that you only need to write a small amount of glue code, built on top of what is already there. For example at the Open University UK, we author in an XML format (with associated assets like images) and we wrote a Moodle module that displays that content in a way rather like the Moodle Book plugin, but with a very streamlined upload process linked to our other production systems.

P.S. I wonder if this conversation would be better in http://moodle.org/mod/forum/view.php?id=1807 ?--Tim Hunt 11:23, 8 November 2010 (UTC)