Unique IDs for Test Questions

This feature request is part of the initiative for an Improved test question sharing.

1 Initial Problem

It is necessary to identify questions over installations to support scenarios where questions are shared or where separate installations are used for preparing and running e-exams. The current question ID is only unique per installation and does not indicate the origin of a question.

2 Conceptual Summary

The existing question ID should be combined with the already existing NIC ID of an installation to get a unique question ID among all ILIAS installations. The notation could be <NIC_ID>-<Q_ID>. Example: 4105-13650.

Dependency of NIC ID

The proposed question ID could be created easily for questions on installations that have registered at the NIC server. For unregistered installations, the NIC-ID is '0'. This makes a clear identification impossible as several unregistered intallations would all use the same NIC-ID. The easiest way to solve this problem is to register these installations, too. A Revision of NIC Registration could help to increase the acceptance of this system by allowing just a simple registration without transfering data about the institution that runs the system and the administrator who is responsible for it.

Alternative using a UUID

To be independent from the NIC ID of an installation a suitable alternative would be to rely on a UUID generated according to the RFC4122.

There is a library on Github called ramsey/uuid that can be installed as a composer depency. This library provides the ability to generate UUID v1/3/4/5. It should get wrapped as a service within ILIAS so UUID can be generated for every purpose and scope.

Wich variant of an UUID should be taken for a unique assessment item identifer is to be discussed. Propably the UUID v4 is the variant to be chosen as it depends on nothing else than random values to guarantee uniqueness accross time and space.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

try {
 
    // Generate a version 1 (time-based) UUID object
    $uuid1 = Uuid::uuid1();
    echo $uuid1->toString() . "\n"; // i.e. e4eaaaf2-d142-11e1-b3e4-080027620cdd
 
    // Generate a version 3 (name-based and hashed with MD5) UUID object
    $uuid3 = Uuid::uuid3(Uuid::NAMESPACE_DNS, 'php.net');
    echo $uuid3->toString() . "\n"; // i.e. 11a38b9a-b3da-360f-9353-a5a725514269
 
    // Generate a version 4 (random) UUID object
    $uuid4 = Uuid::uuid4();
    echo $uuid4->toString() . "\n"; // i.e. 25769c6c-d34d-4bfe-ba98-e0ee856f3e7a
 
    // Generate a version 5 (name-based and hashed with SHA1) UUID object
    $uuid5 = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'php.net');
    echo $uuid5->toString() . "\n"; // i.e. c4a760a8-dbcf-5254-a0d9-6a4474bd1b62
 
} catch (UnsatisfiedDependencyException $e) {
 
    // Some dependency was not met. Either the method cannot be called on a
    // 32-bit system, or it can, but it relies on Moontoast\Math to be present.
    echo 'Caught exception: ' . $e->getMessage() . "\n";
 
}

3 User Interface Modifications

3.1 List of Affected Views

Test > Tab: Questions > Subtab: Page View
Test > Tab: Questions > Subtab: List View
Test > Tab: Questions > Subtab: Print View
Test > Tab: Results > Subtab: All Participants > Test Results (for a participant) > Detailed Results (for a test pass)
Test > Tab: Results > Subtab: Test Results > Detailed Results for a test pass
Test > Tab: Manual Scoring > Subtab: Scoring by Question > Question Filter
Test > Tab: Manual Scoring > Subtab: Scoring by Question > Show Answer (of a participant)
Test > Tab: Manual Scoring > Subtab: Scoring by Participant > Edit Scoring (for a participant)
Test > Tab: Statistics > Subtab: Aggregated Test Results
Test > Tab: Statistics > Subtab: Results By Question

3.2 User Interface Details

3.3 New User Interface Concepts

None.

4 Technical Information

Currently the unique ID for questions does rely on a registered installation, so the installation does have a valid NIC ID. With a Revision of NIC Registration an installation will may offer a valid NIC without any registration in the future.

There are no other technical issues regarding a unique ID for questions. The migration will be done by simply adding a new column to the corresponding database table where the combined ID per question will be initialised for all questions. This way a huge refactoring can be avoided, because the existing database ID won't get replaced.

The features Versioning in Pool and Question Versioning in Test Object depends on a unique ID for questions. While having a unique ID present in the userinterface with the introduction of such an ID, the real benefit of this new ID will come with the introduction of question versioning.

Handling of an unique ITEM ID on Export / Import

For a conistent handling of assessment items with their unique ID during export and import the following requierements need to be fullfilled:

• Versioning in Pool needs to get implemented
• Question Versioning in Test Object needs to get implemented
• A unique ID must be generated that involves the NIC ID of the installation
  • This is required to be able to detect wether an installation is the original home of an assessment item
  • The unique id combined from the NIC and the uniqe ID per question can be stored in different talble columns
  • To get rid of the depency to a registered installation the UUID might be useful to generate NIC IDs in the future

• During export/import an assessment item does not change its unique id anymore
  • When an assessment item gets imported to another installation than the original home it remains not changeable with its unique id
  • The assessment item can be decoupled from the origin by getting a new unique id to make further changes possible again
  • Therefore an assessment item can be imported to the same target installation (other than the origin) multiple times without any problems
• A reimport of assessment items within the original home installation keeping the same unique ids will be avoided
  • When objects (pool/test) containing such assessment are imported a confirmation asks wether the import should actually be done
  • When the import is actually done, all relevant assessment items get a new unique id.
• An export of assessment items from an installation other than the original home installation is also possible

5 Contact

• Author of the Request: Kunkel, Matthias [mkunkel]
• Maintainer: Heyser, Björn [bheyser]
• Implementation of the feature is done by: Heyser, Björn [bheyser]

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• ...

7 Discussion

Neumann, Fred [fneumann], March 31, 2017: A workaround for getting a unique NIC-ID without calling the NIC server is to take a random number bewteen 1.000.000.000 and 1.999.999.999. This may be supported in the ILIAS setup or with a simple database query.

Neumann, Fred [fneumann], April 7, 2017: To me it is not yet clear, where the new combined id should be used. I think it would be a huge refactoring to replace the simple integer question_id in all tables/classes with a combined one. The table qpl_questions has already an integer original_id for pointing to the question in a pool from the question in a test.And it has an external_id which is sometimes like'56337b6e781d49.25356308' or like 'il_0_qst_130078'.
So, it seems we already have something to identify shared questions at least in the data.

Heyser, Björn [bheyser], 18 November 2018:

• Without any NIC registration the current concept would simply take the "0" value that is stored in the database. I agree that the workaround of taking a random number in the upper range of the integer datatype will work. The Revision of NIC Registration should be pushed to get rid of the need for this workaround.
• I fully agree that a huge refactring needs to be avoided. I have addressed your question within the chapter for technical information. An additional column will be added to qpl_questions.
• The currently existing external_id is something that is curiously implemented. Therefore I do not want to take this ID from an obviously unfinished technical concept of the past. I prefer to hopefully get rid of this implementation in the long run.

JourFixe, ILIAS [jourfixe], 19 NOV 2018 : We discussed the suggestion made by Björn and would like to have a clear idea what happens with the ID when the same question is imported twice? According to the existing concept, the question ID would still be the same (NIC ID + Question ID from source installation). But that would cause a problem. How about using this ID as a kind of "Origin ID" that allows to get a relation to the origin of the question but to keep an independant question ID for the existing installation?

Heyser, Björn [bheyser], 01 December 2018: I have addressed the questions about export/import by providing a rule set within the technical information chapter. I also provided a suggestion for a UUID as this kind unique ID was also suggested during the last presentation, but I came across some aspects that would not be fit by a unique ID not depending on an installation NIC ID.

JourFixe, ILIAS [jourfixe], 03 DEC 2018 : We had a long discussion about this suggestion and schedule the feature under the following condition. A unique ID is consists of three IDs which are composed as follows:

• Question ID is composed randomly as UUID. For every change / version, a new ID is generated.
• NIC ID is taken as it is.
• Heritage ID is the UUID of the original question. In case of a new question, the HID is the QID.

Kunkel, Matthias [mkunkel] @ SIG EA, 13 NOV 2019 : The separation of the Test&Assessment has been postponed to ILIAS 7 because the project cannot be finished satisfactorily until 'Coding Completed' at NOV 29. Therefore, this feature won't make it into ILIAS 6 but is now suggested for ILIAS 7. Please add it to the JF agenda to schedule it again.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.