Show Advanced KnowledgeHide Advanced Knowledge

Custom Metadata Extensions

1 Description

The advanced metadata feature should get the following extensions:

• Support for multiline text input fields
• Support for keyword lists input fields
• Two-Level Selection lists (independent and dependent values)
• Repetitive Inputs
• Alle new input fields should be embedded into the search funtionality
• The metadata administration screen should be improved (avoid multiple tables/forms on same page)
• Support additional object types: ILIAS/HTML/SCORM Learning Modules, Test and Surveys, Test and Survey Pools, Files, Web Feeds, Web Links, Glossaries, Groups and Exercises
• Presentation of additional field types and their values in object lists
• Import/Export integration into all object types listed above.
• Copy function integration into all object types listed above

2 Status

• Scheduled for: not scheduled yet (originally scheduled for 4.3 and postponed to 4.4)
• Funding: Partly funded by Bundesagentur für Arbeit - additional funding is required for trunk-integration
• Development: Feature is developed by Fred Neumann (without Trunk-integration)

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: Fred Neumann <fred.neumann@gmx.de>

First implementation will be done as a local patch for BA in ILIAs 4.2. The following sub sections give an overview of how the tables and application classes of advanced metadata will be modified.Goal is to keep the API backward compatible for already existing types.
Please comment any problems you see for a later trunk integration, especially in conjunction with the use of advanced meta data by the ECS server!

3.1 Support for multiline text input fields

The edit GUI will provide a textarea for inputs. Showing this field on the info screens of an object will replace manual line feeds by <br />. Showing this field in object lists will do that only if “newline” selected for the object type in the advanced metadata administration.
 
Class ilAdvancedMDFieldDefinition

• New field type TYPE_TEXTAREA

3.2 Support for keyword lists input fields

The edit GUI will provide a textarea for input, separating the values by comma. Values are stored separately in adv_md_values. Display and re-editing of values will sort them alphabetically.
 
class ilAdvancedMDFieldDefinition

• New field type  TYPE_KEYWORD_LIST

This type uses the extensions for repetitive inputs (see below).

3.3 Repetitive Inputs

Administration GUI will provide a sub option “Allow multiple selections” for fields of TYPE_SELECT and  TYPE_COMBI_SELECT.
 
Table adv_mdf_definition

• New field “multiple” (integer, length 1)

Table adv_md_values

• Change old primary key obj_id+field_id to non-unique index
• New field  “value_id” (integer) as primary key
• Add sequence for value_id

Class ilAdvancedMDFieldDefinition

• New function enableMultipleValues (true/false)
• New function allowsMultipleValues() returns true or false

Class ilAdvancedMDValue

• Initial proposal: To keep backward compatibility, the type "string" used by getValue() and setValue() will not be changed.
  Discussion result:a new function allowsMultipleValues() determins the return type
• Initial proposal: getValue() will return a string with multiple values separated by LF.
  Discussion result: getValue() returns array if allowsMultipleValues() is true
• Initial proposal: setValue() will accept a string with multiple values separated by LF or CR+LF. Values are splitted for storage.
  Discussion result: setValue expects array if allowsMultipleValues() is true
• Initial proposal: New function getValuesArray() will return an array with all values.
  Discussion result: not needed due tu mixed retun type of getValue()
• Initial proposal: New function setValuesArray() will accept an array with the values.
  Discussion result: net needed due to mixed input type of setValues()

Fields of TYPE_TEXT, TYPE_TEXTAREA, TYPE_DATE and TYPE_DATETIME can’t be multiple. enableMultipleValues(true) will be ignored, allowMultipleValues() will return false.
Fields of TYPE_KEYWORD_LIST will always be multiple. enableMultipleValues(false) will be ignored. allowMultipleValues() will always return true.

3.4 Two-Level Selection lists (independent and dependent values)

The Editor GUI will present these fields as two select fields beneath each other. If multiple values are allowed, then multiple rows of combined  select fields are provided and extended if needed. In case of dependent fields the Editor GUI will have no selection for the second field as long as the first field has no value. If the first field is selected , the selection list for the second field will be filled by an ajax request.
 
Internally the second field will be represented by a separate metadata field with TYPE_SUBSELECT or TYPE_SUBSELECT_DEPENDENT and the field_id of the first field as parent_field_id. Fields of these types cannot be defined in the administration GUI on their own. They will be created automatically if a field of TYPE_COMBI_SELECT is created and deleted automatically if their parent field is deleted.
 
Values of subselect fields will be stored with the value_id of their combined parent value as parent_value_id. The possible values of the field definition are stored as a serialized array. The array structure of TYPE_SUBSELECT is the same as of TYPE_SELECT. The structure for TYPE_SUBSELECT_DEPENDENT is nested:
array(parent_value1 => array (value1, value2, …), parent_value2 => array(value3, …), …).
 
Table adv_mdf_definition

• New field “parent_field_id” (integer)

Table adv_md_values

• New field  “value_id” (integer) as primary key (see “repetitive” inputs)
• New field “parent_value_id” (integer, indexed)

Class ilAdvancedMDFieldDefinition

• New field type TYPE_COMBI_SELECT
• New field type TYPE_SUBSELECT
• New field type TYPE_SUBSELECT_DEPENDENT
• New function setParentFieldId(field_id)
• New function getParentFieldId()
• New optional parameter $a_parent_value for function appendFieldValue() will set $a_value as dependent from $a_parent value
• New optional parameter $a_parent_value for function setFieldValues() will set the values in $a_values as dependend from $a_parent_value
• New optional parameter $a_parent_value for function getFieldValues(), getFieldValuesForSearch() and getFieldValuesForSelect() will only get the values defined for a parent value

Class ilAdvancedMDValue

• New function getValuesWithId() will return an associative array(id => value)
• New optional parameter $a_parent_value_id for function setValue() and setValuesArray() will set the value(s) of $a_value as combined with a specific parent value
• New optional parameter $a_parent_value_id for function getValue() and getValuesArray() will get the value(s) for a specific parent value

Administration GUI will allow to enter a separate title for the second field and to set a switch whether the second field is dependent or not. Possible values for the second field are entered on a second screen or form which is available by a link “Edit combined values” either for the parent field as a whole or for each parent value separately.

3.5 Allow title and description as advanced metadata

This is very specific to the BA. To allow editing of all relevant information on one screen, the title and description should be editable together with the other meta data.  Values for these types will not be stored in adv_md_values, but in the object data directly.
Class ilAdvancedMDFieldDefinition

• New field type TYPE_TITLE
• New field type TYPE_DESCRIPTION

3.6 Allow to configure visibility on the info screen

It should be possible to specify whether a field is shown on the info screen of objects or not. It is enough to specify this for a field independently from the objects where it is used/assigned. AdministrationGUI will have a new option “Show in info screen” in the form “Edit field”.
Table adv_mdf_definition

• New field “displayed” (integer, length 1, default 1)

Class ilAdvancedMDFieldDefinition

• New function isDisplayed (true/false)
• New function setDisplayed() return true or false

3.7 Allow to configure the date presentation

The administration GUI should allow to specify a date format additionally to “position“, “bold”, and “newline” for “Presentation in the Repository/Personal Desktop”. Fixed formats may be available for selection. At least the format 02/2012 without day should be possible additionally to the default format.
 
Table adv_md_substitutions

• Initial propsal: New associative key “date_format” in serialized array of field “substitution”.  The value is a format string for the php function strftime.
  Discussion result: replaced by new associative key "date_precision" in serialized array of field “substitution”. The value is a string with the following possible values: "year", "month", "day" for TYPE_DATE and additional "hour", "minute", "second" for TYPE_DATETIME. No key or an empty value will result in default behaviour.

Class ilAdvancedMDSubstitution

• Initial proposal: New optional string parameter $a_date_format for function appendSubstitution(). If empty,date will be presented in default style.
  Discussion result:New optional string parameter $a_date_precision to get a specific date precision.
• Initial proposal: New function getDateFormat($a_field_id) to get a specific date format.
  Discussion result: New function getDatePrecision($a_field_id) to get a specific date format.
• Intitial proposal: Apply a defined date format in parseValue()
  Discussion result: Apply a defined date precision in parseValue(). Use new function(s) or precision parameters in class ilDatePresentation for this purpose.

4 Discussion

Alex, Stefan, Jörg, 24 Apr 2012
 
The ilAdvancedMDValue handling for multiple values ("getValue() will return a string with multiple values separated by LF") is a very uncommon way to implement this need. If the FieldDefintion class already has a enableMultiple flag, wouldn't it be possible to use a similar flag in the MDValue class? If set to true then get/setValue would use arrays, otherwise single values.
 
[JL: The form service now allows multiple values in the trunk for some field types, e.g. text input. This will add +/- icons to that field and handle the array values accordingly. The javascript methods should work with most of the field types with just a little effort. If you have any questions about this feel free to contact me. A basic example can be found in Services/Membership/AttendanceList which e.g. is used in course > members > button "generate list" > blank columns ]
 
The setting for date configuration seems odd. We already have a ilDatePresentation class which is used throughout the system and is language-specific. You would need a setting for each language (de/en at least) and where is the point in that?   If you need a special presentation as month/year only, we should implement it as custom date format.

Fred, 25 April 2012
 
I intended separating multiple values in getValue() by LF to avoid a mixed return type so that existing components and services which are not aware of the multiple values won't run into trouble. if you see this as the minor problem, I will change the functions getValue() and setValue() to return and accept value arrays. The functions getValueesArray() and setValuesArray() are then not needed. A new function ilAdvancedMDValue::allowsMultipleValues() will provide this information from the FieldDefinition.
 
Jörg, thanks for the tip regarding the multivalue support of FormProperties in the trunk. I compared the form classes of the trunk with the BA 4.2 branch and think it is possible to merge the needed extensions of the PropertyFormGUI and FormPropertyGUI to the branch. However, I will use them only for a new CombinedSelectInputGUI implementing the two-level selection lists and not touch the TextInputGUI and SelectInputGUI. The BA requirements currently don't need multiple values for text and simple selects. In a later trunk integration we can easily allow multiple values for those fields types.
 
My first idea for the date format string was to allow an administrator to enter this string directly in the metadata administration to give him full flexibility of how the metadata dates are presented. I saw that strftime() is aware of the LOCALE but didn't recognize that setlocale() is not separeated between Apache threads and therefore can't be used for user dependent language settings.
 
I can use ilDatePresentation, but will need to extend this class:

• adding constants for date presentation formats, at least FORMAT_DATE_DEFAULT and FORMAT_DATE_MONTH_SLASH_YEAR.
• adding a function getDateFormatForSelection() returning an array with format id and description for a selection list.
• adding an optional parameter $a_format to formatDate().
• BTW: I would also like to add an optional parameter $a_use_relative_dates to formatDate() to overcome the current get/remember/set workaround for this property.

Note: The date formats will be ILIAS specific. Other systems geting advanced meta data by ECS will probably not know them.

JL, 25 Apr 2012
 
Ok, maybe I wasn't clear: the date formats are not really up to any administator or tutor. They are language- and even user-specific [accessible via ilCalendarSettings (GUI: calendar > properties)].
 
Proposal:
As month names are part of our language files (as we are NOT using the PHP stuff), would a ilDatePresentation::formatMonth(ilDate $date, $a_short = false, $a_textual = false) not be sufficient?
The numeric/short versions are typical for statistics and table GUIs, normally we would prefer the textual ones. formatMonth() would not be affected by useRelativeDates().

• textual = false
  • short = false
    • depending on ilCalendarSettings::DATE_FORMAT_*, e.g. 10/2012
  • short = true
    • depending on ilCalendarSettings::DATE_FORMAT_*, e.g. 10/12 (IMHO doesn't make much sense)
• textual = true
  • short = false
    • depending on language: January 2012
  • short = true
    • depending on language: Jan 12

So for me the meta data would just need 3 types: datetime, date, month. The presentation GUI should decide which format is best in its context.
 
The ilDateTimeInputGUI currently has 2 modes: input or select. The input mode already depends on the user-specific calendar settings. A new getter/setter "setShowDay()" could be a possible solution to enable month values. I currently don't know if our JS-calendar-widget does support month selections in any way - a fallback could be to only support the select mode for month values in a first version (while hiding the js-calendar).
 
 

Now I got the point: we should differ between date/time precision (Year, Month, Day, Hour, Minute, Socond) and the actual display format of a value with a certain precision. The precision carries semantical information and should be controlled by the data provider or the context in which a date value is displayed, the display format depends on user settings.
That could in the future perhaps be realized in a generic way, e.g. by a precision property in ilDateTime or by a precision parameter in formatDate(), but separate functions like your proposed formatMonth() are ok for me, too.
 
I don't need to change the ilDateTimeInputGUI for the BA, because the "Publish Date" defined by BA currently has day precision. Here we see the dependency from the context: editors should provide the precise date, while users listing objects in the repository should see only month/year. To support this I would add a "date_precision" key instead of "date_format" in table adv_md_substitutions and support it in ilAdvancedMDSubstitution. Values may be "year", "month", "day" and propably "hour", "minute", "second" depending on the field type.

JF 2 May 2012: We discussed all features and which of them could go to the trunk. These can be added to Release 4.3. How do you plan to proceed?

• Multiline text input fields: ok
• (Repetitive) Multi-Value Input Fields: ok
• Keyword lists: If possible they should be implemented by a multi-value text input field (+/-) icons.
• Two-Level Selection lists "independent/dependent": We prefer to have this feature not in the trunk in this way, since it would be a special "selection list"- only feature.
• Search functionality: Yes, all fields must be included in the search.
• Administration Screen: Yes, a better usability is needed here.
• Additional object types supporting adv metadata: We appreciate the general implementation, but we would need screens/mockups how the integration into the settings screens will look for the different object types. Additionally at least Wikis and Mediacasts should be supported.
• Presentation in object lists, import/export/copy: ok
• "Allow title and description as advanced metadata": This is something we would like to dicuss together with the settings screens GUI.
• Allow to configure visibility on the info screen: ok

JF 30 May 2012: We would like to rename the feature from "advanced metadata" to "custom metadata". The custom metadata fields should be appended to the "quick edit" screen of the metadata tab (which should use the formgui class). In the long run we would like to support "core", "extended/lom" and "custom" metadata configurable for all object types, Metadata Revision.

Fred Neumann 3rd September 2012. The feature is currently productive in an ILIAS 4.2 branch for the Bundesagentur für Arbeit:

• Support for multiline text input fields
• Support for keyword lists input fields
• Two-Level selection lists (independent and dependent values)
• Multiple inputs for text fields and select lists (JavaScript interface with +/- buttons for adding/removing rows)
• New field type "Keyword list" for comma separated list of keywords
• New field types "Title" and "Description" to allow the editing of thises basic object data in extended meta data forms

• The additional field types and their values are presented in object lists and info screens
• The copy function for objects copies all new advanced meta data

• Alle new input fields are embedded into the search funtionality (database and lucene)
• The metadata administration is improved to avoid multiple tables and forms on same page
• The export and import of advanced meta data records in the metadata administration is extended to support the new field types

• Nearly all ILIAS object types are supported, except media cast, media pool, remote course, session, wiki that were not required.

• The import and export of advanced meta data is adjusted for courses where advanced meta data are already exported. Other object types do not yet export advanced meta data.

For the BA implementation the editing of advanced meta data is realised on a separate tab in the object GUIs.
 
Due to lack of time and resources the integration of the extensions in the ILIAS trunk is postponed to release 4.4.

Matthias Kunkel, 03 SEP 2012: Feature is postponed to 4.4 because it cannot be integrated into trunk untli deadline for 4.3.0_beta at September 04.

Matthias Kunkel, 17 Oct 2013: Feature is postponed and unscheduled because it cannot be integrated into trunk for 4.4.

5 Implementation

...