Feature Wiki

Information about planned and released features

Tabs

Introducing Data Collection

1 Requirements

ILIAS should offer a repository object that allows the collection and presentation of data for different purposes. This was decided by the ILIAS open source e-Learning society's Advisory Board on its first meeting in Stuttgart. This type of object will also be used to implement a database for exisiting ILIAS plugins. But a lot of other scenarios of usage are possible.

The Data Collection Object should be a similar object to the moodle Plugin "Datenbank": http://docs.moodle.org/20/de/Datenbank

1.1 General

The data collection object allows
  1. configuring a database within the repository for collecting data
  2. adding and editing datasets
  3. presenting data to users within the object
In a later ILIAS version it should also be possible to re-use content in other ILIAS objects (category, wiki, LM, ...).

1.2 Settings

  • Title [Text]
  • Description [Text]
  • Online [Checkbox] (Read Access for user)
  • Data input possible [Checkbox] (Write access for user)
    • Data Input possible until [DateTime]
  • Activate rating [Checkbox] -> ILIAS 4.4
  • Public comments [Checkbox] -> ILIAS 4.4 (if need be)
  • Approval required [Checkbox] -> ILIAS 4.4 (if need be)

1.3 Configuring Database

A Data Collection Object contains one configurable table.

1.3.1 Add Fields

It is possible to add any number of fields, as desired.
  • Title
  • Description
  • Type (Image, File, DateTime, Multiple Choice, Single Choice, Geolocation, Text, Long Text, URL, Integer)
    • Image - Additional Settings: Preview Size; Full Screen Size
    • DateTime - Additional Settings: Date only
    • Multiple choice - Additional Settings: Checkbox / Combo Box -> multiple boolean fields
    • Single Choice - Additional Settings: Radio button / Combo Box -> reference to a further table as drop-down
    • Text - Additional Settings: min. chars
    • Long Text - Additional Settings: min. chars; Richt Text Editor -> ILIAS 4.4 (if need be)
    • URL - Additional Settings: internal, external
    • Integer - Additional Settings: Range -> Range-Setting ILIAS 4.4 (if need be)
  • Required: True / False

1.3.2 Configure Views

Each Data Collection Object offers the following views:
  • List
  • Single View
  • New/Edit Entry
  • Search Form
  • Print View -> ILIAS 4.4 (if need be)
The views are configurable with the ILIAS Page Editor. It is possible to include the database field values with the ILIAS Page Editor. This could be done in a similar way as it is possible with the function "Insert Resource List".
 
Additionally the following functions are available:
  • edit:  Insert a link to the view "Edit Entry"
  • delete
  • approve
  • more: Insert a link to the view "Single View"
  • user: Link to the profile of the author
  • timeadded
  • timemodified

The configurable Database View in Moodle:

» docs.moodle.org/20/de/Datei:Datenbankvorlagen.jpg

1.4 Permissions

The Data Collection object should at least support the following permissions:
  • VIEW - object is shown in container but cannot be opened
  • READ - content (datasets) can be read in presentation view (usually a table)
  • ADD ENTRY - user is allowed to add a new data set but not to edit existing data (this is necessary to support controlled data collection)
  • WRITE / EDIT SETTINGS - settings and content can be changed / modified
  • COPY - object and data can be copied
  • DELETE - object and data can be deleted or moved to another tree node
  • EDIT PERMISSION - permission settings of data collection can be changed

1.5 Additional Requirements

  • Option for notification about new entries - necessary when using the data collection object for collecting information collaboratively (similar to wiki).
  • Option to create plugin ID - necessary to use object for plugin database.
  • Simple export function (all content of the object in one csv file).
  • Supporting text placeholders
  • Option to define a regular expression for text fields
  • Setting for a field's visibility (should it appear in the list view or not).

2 Status

3 Additional Information

  • If you want to know more about this feature, its implementation or funding, please contact: Matthias Kunkel / Martin Studer

4 Discussion

JF 10 Oct 2011: We highly appreciate this idea. We must not forget to support the "plugin" ID creation at the same time.

HL 8 Feb 2012: Maybe it is helpful if we collect the possible use-cases for this database-feature.
  • allows the teacher and/or students to build, display and search a bank of record entries about any conceivable topic
  • A database for ILIAS-plugins
  • An archive for theses
  • Using the database as a simple reference list (Moodles database object is often used for this purpose)
  • A tool to administrate simple mediothek (some media a group of teacher share)
  • A database for choosing literature from a defined list - for a examination:
    • a: admin defines a first table with the literature-fields, e.g. theme, title, author, pages, ...
    • b: admin defines a second table for the students
    • c: admin adds the whole literature with "New data records"/"Add entry"  - new entries in the literatur-table
    • d: students are not allowed to add new literature, but in a separate view, they can arrange their own literature-list for the examination
  • a tool for groups: collecting and evaluation collaboratively of images, documents and data

Matthias Kunkel, 20 Feb 2012: The Moodle screenshots are interesting as a reference to an existing implementation of such a feature. But I would like to make clear that the screenshots of the Moodle GUI should not be a model for the ILIAS interface. I am sure this could look much better in ILIAS ;-)
 
Second point: I am missing an export option. The database object should at least support an easy .csv export to get collected data out of the system.

JF 22 Feb 2012: We highly appreciate the concept. Open questions:
  • We understand the need to use the ILIAS page editor for the "Single View". In this case we also would like to use text placeholders (like in Moodle). Question: Should the page editor used for other views as well? How should it look/work?
  • A "unique" attribute may be interesting.
  • For text fields an option to define a regular expression could be useful
  • Options for fields whether they should appear in the list view or not.

Matthias Kunkel, 27 Feb 2012: I have added the requests from the last JF to the feature description. ILIAS service providers are now invited to send an offer for implementation.

Thomas Gärtner, 08 May 2012: I think the user would be confused because of the name "Database Object". I think this is also confusing in Moodle because it is not a database but a table. Like 1.3 says: the object contains one configurable table. So why don't you call it "Table Object" or "Database Table Object"? Or maybe "Configurable Table Object"?

Matthias Kunkel, 08 May 2012: It is important that an user understands the meaning of this repository object type - no matter how it is implemented (table / database / ...). What this object does is collecting, storing and presenting data. Therefore, database object would fit quite well. "Table" is already to much determining the presentation - as a table. In some cases I might present the data in a kind of list and not as a classical table. Therefore the name of this type should be independent from the kind of presentation. At least, how about "Data collection" / "Datensammlung"?

Thomas Gärtner, 08 May 2012: "Data Collection" fits perfect.

Bernhard 14.5.12: csv/Excel import would be a nice feature, too.

Matthias Kunkel, 08 Jun 2012: Object is now called "Data Collection".

Alex Killing, 4 Sep 2012: Great Feature! I would suggest to add another field type "Enumeration", that works similar to the user custom fields of type "Selection List". Currently you need a separate table with one field and a field reference in your main table to do this.

Matthias Kunkel, 17 Sep 2012: The data collection's usability for those who enter data could be improved if we show also the description text of input fields. Currently only the title is presented in the input form. Disadvantage of this design is that the input titles might not always be self-explaining. It would be better to have the possibility of describing what kind of information should be entered there.

JF 17 Sep 2012: We support both suggested improvements (enumaration fields and description texts).

5 Implementation

Last edited: 17. Apr 2025, 15:05, Kunkel, Matthias [mkunkel]