We'll start developing a IMS/QTI interface for the quiz module next week, aiming at a QTI-based REST interface that will enable our Flash clients to render the questions (including the more complex question types we'll have to introduce) and interact with Moodle on the server.
If you have any comments, similar plans or objections: please let me know.
Regards,
Hannes
Hi Hannes,
I only just discovered your post. It turns out we have very similar plans. As part of the Serving Mathematics project we are planning to equip the Moodle quiz module with a question type that can have its questions rendered and scored by an external question engine web service. So far it sounds just what you are doing. However we were planning on using SOAP rather than REST.
So far we have started to write a document to explain our current thinking about the protocol (which we call Remote Question Protocol). You can find discussions about it in our RQP forum.
We are however not yet committed to a particular protocol, so it would be very good to compare with your plans. Where can we find details?
Thanks a lot for this remark, sounds i n t e r e s t i n g!
First: There aren't any public documents on our plans, we're just working on a bigger project requiring a highly configurable question engine, and as we're an open source company we decided to use Moodle as the server-side engine, that's all.
Definitions of question set will be read as an IMS manifest with QTI 2.0 assessmentItems, then for the communication of results (all the runtime behaviour) we planned to have several communication modules. In the first phase applied the "simplest thing that could possibly work" pattern and "play browser": Input to Moodle is done as ordinary HTTP-POST sending the variables exactly like your browser does. No XML involved (which is pretty unusual for us
). For the other way they are currently working in the direction as to make Moodle output no HTML, but HTTP-style variables. Doing things in a way requiring the least amount of changes to Moodle is a factor here.
Let me add that I'm not actually managing this thing, we will have to ask Brian King and Gerhard Andrey to explain the current status, but I guess if you guys are incorporating a SOAP interface matching our requirements, the client-side question engine developers here will be more than glad to build a SOAP communication module into their software.
Anyway, what you're doing looks highly interesting, I need to spend some time reading through the posts and I will send the link to our developers right now.
Do I understand it right that you're in a rather early phase of your project, is there running code to look at right now? (I heard our guys were at about 50%)
Concerning SOAP vs. REST: We did really a lot of XMLRPC-based software and were pondering switching to SOAP, too. I like some aspects of the SOAP world, too (just finishing a conference paper about a proposed improvement of WSDL), but I do feel that REST has an edge over it in cases where we're talking about services on top of HTTP anyway.
So.. I will point the people in charge of this project here to this thread, let's see what we can do. I would appreciate a collaboration very much indeed.
Regards,
Hannes
PS: I was just about to think about organising a Moodle sprint.. this would make a faboulous topic for one....
First: There aren't any public documents on our plans, we're just working on a bigger project requiring a highly configurable question engine, and as we're an open source company we decided to use Moodle as the server-side engine, that's all.
Definitions of question set will be read as an IMS manifest with QTI 2.0 assessmentItems, then for the communication of results (all the runtime behaviour) we planned to have several communication modules. In the first phase applied the "simplest thing that could possibly work" pattern and "play browser": Input to Moodle is done as ordinary HTTP-POST sending the variables exactly like your browser does. No XML involved (which is pretty unusual for us
Let me add that I'm not actually managing this thing, we will have to ask Brian King and Gerhard Andrey to explain the current status, but I guess if you guys are incorporating a SOAP interface matching our requirements, the client-side question engine developers here will be more than glad to build a SOAP communication module into their software.
Anyway, what you're doing looks highly interesting, I need to spend some time reading through the posts and I will send the link to our developers right now.
Do I understand it right that you're in a rather early phase of your project, is there running code to look at right now? (I heard our guys were at about 50%)
Concerning SOAP vs. REST: We did really a lot of XMLRPC-based software and were pondering switching to SOAP, too. I like some aspects of the SOAP world, too (just finishing a conference paper about a proposed improvement of WSDL
So.. I will point the people in charge of this project here to this thread, let's see what we can do. I would appreciate a collaboration very much indeed.
Regards,
Hannes
PS: I was just about to think about organising a Moodle sprint.. this would make a faboulous topic for one....
That all sounds very interesting. I am surprised that you are thinking of Moodle as the server-side engine. In our project Moodle is the client that consumes questions rendered and marked by question engine servers. After all Moodle does not have a QTI question engine. Can you explain in what sense you are planning to use it as the server-side engine?
The main purpose of our project is to provide question engines for mathematics questions as web services. However there is another JISC funded project APIS that aims to provide a QTI v.2 engine.
We are indeed at an early stage of our project. We do have working mathematics question engines but have not yet started to give them their web service interface. We also have not yet started to code the client interface for Moodle. However we plan to have prototypes for all that before Christmas.
A Moodle sprint sounds like a very good idea. Do you have any veteran sprinters?
Hi Gustav,
We're considering Moodle the server-side engine, because we're planning to use it as the data store. Actually the questions will be (where possible) entered in the Moodle question-editor. In this case Moodle is also the client interface.
When someone takes a quiz, however, we'll have a flash front-end that they'll interact with. Here Moodle is a server, which handles requests from the client-side flash player. The flash player will request an imsmanifest.xml file from Moodle (for Moodle it'll be a request for an export), and then will request from Moodle any other files or data necessary to present the quiz.
In our first version, we'll have everything (except external files - graphic files, pdf or word docs, etc.) in one big imsmanifest.xml file. The assesment items will be inline, instead of being referenced as external resources (see attached test.xml file for an example).
Our export of questions is rather specialized, and differs from the normal Moodle question export, in that we're exporting all the questions from a particular quiz, instead of all the questions from a particular question category. However, the standard question-category level export will also be available. If that option is chosen, all the qti files will be exported to a directory. In this case, each assesmentItem is in a seperate file.
A word about our timeline: we need to deliver a working version by the end of this month. Because of time/money constraints, we can't deviate too much from our current plans - at least for this first version.
I glanced over your specs doc, it looks like you've put a lot of thought into it. Just wondering - why did you choose to use SOAP?
OK - back to coding ...
We're considering Moodle the server-side engine, because we're planning to use it as the data store. Actually the questions will be (where possible) entered in the Moodle question-editor. In this case Moodle is also the client interface.
When someone takes a quiz, however, we'll have a flash front-end that they'll interact with. Here Moodle is a server, which handles requests from the client-side flash player. The flash player will request an imsmanifest.xml file from Moodle (for Moodle it'll be a request for an export), and then will request from Moodle any other files or data necessary to present the quiz.
In our first version, we'll have everything (except external files - graphic files, pdf or word docs, etc.) in one big imsmanifest.xml file. The assesment items will be inline, instead of being referenced as external resources (see attached test.xml file for an example).
Our export of questions is rather specialized, and differs from the normal Moodle question export, in that we're exporting all the questions from a particular quiz, instead of all the questions from a particular question category. However, the standard question-category level export will also be available. If that option is chosen, all the qti files will be exported to a directory. In this case, each assesmentItem is in a seperate file.
A word about our timeline: we need to deliver a working version by the end of this month. Because of time/money constraints, we can't deviate too much from our current plans - at least for this first version.
I glanced over your specs doc, it looks like you've put a lot of thought into it. Just wondering - why did you choose to use SOAP?
OK - back to coding ...
Any QTI news?
As you know our approach is to use a QTI web service to render and score QTI questions from within the Moodle quiz module. The QTI engine we are using is APIS. We should be able to demonstrate this in a week or so as soon as the web service interace of APIS is updated to the current version of RQP.
Any news?
Am I correct if I say:
- Moodle has only a subset of quizz-types of QTI.
- If you do QTI export, you only have to map this subset on the QTI format.
- If you accept that Moodle only can handle her own subset of QTi, QTI import("lite") is also less difficult.
Do I understand that you are trying to connect the QTI engine APIS to make it possible for Moodle to handle all the possible QTI combinations? Where are these questions createde and stored?
To do that you must build a webservices add-on for Moodle. Are you trying to do that? ( And if so: talking to programmers I understand that this looks the same as the problem to build the (also soap) services-interface for the IMS/LD engine..
Hi Ger,
your analysis is correct.
Moodle can not currently handle all of QTI. This is not just because it doesn't have all the question types but more importantly because the old quiz module code can not handle adaptive items in which the student is led through a serious of responses. The simplest type of this is a question that prompts the student to try the question again in the light of feedback.
Our answer to this problem has been the following:
The non-native QTI questions will be stored in the Moodle question database (as XML). They would not be authored within Moodle, this feature is mostly for being able to use externally authored questions.
The web services client that allows Moodle to consume the question engine web services already exists and works. Unfortunately SOAP support exists in PHP only since version 5 and for PHP4 one has to use external packages like nuSoap which unfortunately have turned out to be rather unreliable. We are however hopeful to receive a follow-on grant from JISC which would enable us to provide a reliable PHP4 version as well.
I am planning to put up demos on the Serving Maths site in the near future.
Are you saying that there are people working on web services interfaces in Moodle for IMS/LD? We should probably exchange expertise in that case.
your analysis is correct.
Moodle can not currently handle all of QTI. This is not just because it doesn't have all the question types but more importantly because the old quiz module code can not handle adaptive items in which the student is led through a serious of responses. The simplest type of this is a question that prompts the student to try the question again in the light of feedback.
Our answer to this problem has been the following:
- we have rewritten the quiz code so that it does allow the handling of adaptive questions.
- QTI questions that Moodle can not handle natively are sent of to a web service that can.
The non-native QTI questions will be stored in the Moodle question database (as XML). They would not be authored within Moodle, this feature is mostly for being able to use externally authored questions.
The web services client that allows Moodle to consume the question engine web services already exists and works. Unfortunately SOAP support exists in PHP only since version 5 and for PHP4 one has to use external packages like nuSoap which unfortunately have turned out to be rather unreliable. We are however hopeful to receive a follow-on grant from JISC which would enable us to provide a reliable PHP4 version as well.
I am planning to put up demos on the Serving Maths site in the near future.
Are you saying that there are people working on web services interfaces in Moodle for IMS/LD? We should probably exchange expertise in that case.
Are you saying that there are people working on web services interfaces in Moodle for IMS/LD? We should probably exchange expertise in that case.
Not yet, I am in the phase of looking for people who are interested in that. (And try to make an inventory of what is needed for an IMS/LD interface..)We are just a poor public school, but thanks to Moodle the best
I think that the combination of a QTI-engine, a LD-engine and the free format design (Gestalt?) of Moodle will become the Killer app for eLearning.
Thanks for your explanation,
Any news on this front?
This thread has become very silent? I know we have the adaptive mode and a plug-in interface for adaptive type QTI questions but do we have adaptive question types being created and available for testing?