Infrastructure for Adding Metadata from Controlled Vocabularies

1 Initial Problem

OER ecosystems rely on standardized metadata to make OER searchable and shareable. This includes in particular community-specific controlled vocabularies for data like audience role, educational level, or subject groups, study areas and study subjects of the OER (see also the subjects and organizations in the OERSI git).

Currently, ILIAS offers no way to support these kinds of vocabularies. This makes it hard to fill out the metadata of OER correctly and effectively.

The necessity to support controlled vocabularies to facilitate such ORCA Workflows was worked out in workshops with personnel from the hbz, among others. This request only covers the needed infrastructure, it does not transform and import any specific vocabulary. 

2 Conceptual Summary

Controlled vocabularies can be imported in the Metadata administration, which are then offered to users in the LOM editor. Imported vocabularies are displayed alongside the vocabularies that are already included in the LOM standard. This request only covers the infrastructure to do so, no specific vocabulary (except those native to LOM) will be pre-installed in ILIAS.

Controlled vocabularies can only be imported from xml files in a specific format, they can not be created or edited via the UI in ILIAS. Each xml file contains a single vocabulary. The following information is included in such an import file:

• the LOM Element that the vocabulary should apply to
• the source of the vocabulary
• the list of terms included in the vocabulary, each term optionally with a label

For some elements, vocabularies can be made conditional on the value of a specific other element (see below for details). In this case, the terms in a vocabulary are only offered if that other element has the correct value. In this case, that value also needs to be included in the import file. If that value is not provided, the vocabulary is not conditional. For an example of conditional vocabularies in action, see technical: requirement: orComposite.

Not all elements are eligible for controlled vocabularies. To not make the LOM editor overly complicated, they should be limited to elements of the type 'vocabulary value' as per the LOM standard (for which a dropdown if offered in the LOM editor), and a selection of elements that allow free text input. For the former, the LOM editor will simply offer an expanded dropdown, and for the latter a selection between a dropdown and a custom text input.

Excluded are text elements that either serve to identify a specific object or entity (e.g. general > title), or that exist to hold additional information without a specific semantic purpose (e.g. technical: installationRemarks or any description).

Controlled vocabularies will not be exported along with ILIAS objects. It might then be the case that the metadata of an ILIAS object contains values from unknown (or deleted) vocabularies. ILIAS should handle these values graciously, they should never be hidden or silently deleted. See below for more details.

If the same controlled vocabulary is present on both the installation where the object is exported and where it is imported, the value is assigned properly (and displayed with the associated label if there is one).

Controlled vocabularies can be deleted or deactivated. In both cases, their terms are not offered in the LOM editor anymore. Further, vocabularies for text LOM elements can disallow custom inputs when they are active. The following restrictions apply:

• The vocabularies that are included in the LOM standard (with source 'LOMv1.0') can never be deleted.
• Vocabularies can not be deactivated or deleted if they are the last active vocabulary for their element, except for text elements.

3 User Interface Modifications

3.1 List of Affected Views

• Administration > Search and Find > Metadata > Copyright & OER > LOM Vocabularies
• The full LOM Editor in the 'Metadata' tab of any object

3.2 User Interface Details

In the 'Copyright & OER' tab of the Metadata administration, in a new subtab 'LOM Vocabularies', all vocabularies are displayed. This includes both imported ones and those included in the LOM standard.

The vocabularies are shown in a data table with the following columns:

• Element: Which Element does the vocabulary belong to? If applicable, this includes conditions on other elements.
• Type: Is the element restricted to values from vocabularies as per the LOM standard, or is free text input allowed?
• Source: Source of the vocabulary, 'LOMv1.0' for those included in the standard.
• Values: Shows the first five terms included in the vocabulary. If the terms come with a label, the label is displayed first with the actual value behind it in brackets.
• Active: Are the terms from the vocabulary offered in the LOM editor? The default is 'yes'.
• Custom Input Allowed: If this vocabulary is active, is custom input allowed in addition to it? Only applicable to text LOM elements. The default is 'yes'.

For all rows, the table offers a single action to 'Show All Values', which leads to a modal where all terms are displayed in a listing. Where applicable, the table also offers single actions to delete vocabularies, (de-) activate them, or (dis-)allow custom input.

'Delete' shows a confirmation modal, where the first five terms of the to be deleted vocabulary are listed as interruptive items, and the following text is shown: Are you sure you want to delete this vocabulary for the element {ELEMENT} from source {SOURCE}? Note that this does not delete already existing values in the learning object metadata of ILIAS objects.

Above the table, an 'Import' button is offered. It opens a modal with a file input, where additional vocabularies can be imported.

In the LOM editor, importing a controlled vocabulary changes the offered input elements as follows:

• For elements that normally offer a dropdown: The values offered in the dropdown are those from all active vocabularies. They are shown by their value, if available.
  If an element carries a value from an unknown, deleted, or inactive vocabulary, that value is also offered with the token 'unknown vocabulary' appended in brackets (but not any other values from e.g. the same inactive vocabulary).
• For elements that normally offer text input: Two radios 'From Vocabulary' and 'Custom' are offered. The latter offers a text input, the former a dropdown with the values of all active vocabularies.
  If an element carries a value from an unknown, deleted, or inactive vocabulary, that value is simply treated as custom input, and shown in the corresponding text field.
  If at least one vocabulary of the element is does not allow custom input, only a dropdown is offered. In this case, the behavior is identical to that of elements that normally offer dropdowns.

3.3 New User Interface Concepts

No new interface concept. 

3.4 Accessibility Implications

The use of KS elements is assumed to ensure full accessibility 

4 Technical Information

The database tables of MetaData need to be expanded such that the source of a vocabulary value can be persisted properly. Also, columns for the values themselves need to allow a higher length: right now, they are pretty much exactly the length they have to be for the native LOMv1.0 vocabularies. It might be necessary to restrict the length of values in controlled vocabularies on import.

The token 'LOMv1.0' should be forbidden as the source of vocabularies on import, because it is reserved for the pre-installed, native vocabularies.

Some elements have special requirements, they e.g. can't be deleted or come pre-filled with a specific value. These requirements must be reflected in the corresponding input elements, regardless of whether any additional vocabularies are active or not.

The xml files for importing vocabularies must be created with the following format:

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

<appliesTo>
    <pathToElement>
        <step>lifeCycle</step>
        <step>contribute</step>
        <step>entity</step>
    </pathToElement>
    <condition value="publisher">
        <pathToElement>
            <step>lifeCycle</step>
            <step>contribute</step>
            <step>role</step>
            <step>value</step>
        </pathToElement>
    </condition>
</appliesTo>
<source>https://ror.org</source>
<values>
    <value label="Rheinisch-Westfälische Technische Hochschule (RWTH) Aachen">https://ror.org/04xfq0f34</value>
    <value label="Universität zu Lübeck">https://ror.org/00t3r8h32</value>
    <value label="Hochschule Weihenstephan-Triesdorf">https://ror.org/00gzkxz88</value>
    <value label="Universität Kassel">https://ror.org/04zc7p361</value>
    <value label="Technische Universität Clausthal">https://ror.org/04qb8nc58</value>
    ...
</values>

5 Privacy

Compared with normal LOM Metadata no additonal personal data is stored.

6 Security

No security issues are foreseen. 

7 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Meyer, Stefan [smeyer]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

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

• FH Dortmund

9 Discussion

Schmitz, Tim [tschmitz], 13 MAR 2024: I overhauled the article based on the OER Feature Workshop on 06 MAR 2024.

JourFixe, ILIAS [jourfixe], 29 APR 2024: We highly appreciate this suggestion and schedule the feature for ILIAS 10 / trunk.

10 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}.