## 2 MWDEX: Moodle Workshop Data EXtractor  
### Objectives and Design Approaches  
From the discussion in Section 1, MWDEX is designed with the main objective of extracting data from Moodle Workshops for further analysis through data export and visualization. By exporting data, MWDEX extends the functionality of Moodle Workshop, returning a dataset that instructors can edit, manipulate, combine, and analyze at their convenience in a browser or an external spreadsheet software. In order to facilitate the analysis, the dataset should include all the available and relevant information about peer assessment of all the assignments, that is, the data should include a list of all the submissions of a given assignment, including the following information: name or identification of the submitter, name or identification of the reviewer, and grade assigned/received. In addition, if the assignment uses an assessment rubric, the dataset should incorporate the grades given/received in each aspect of the rubric. If the assessment includes feedback comments, these should also be included in the dataset (both global feedback comments and feedback about specific aspects of the rubric, if any). Finally, when the assignment also includes self-assessment, the dataset should identify each record as pertaining to self- or peer assessment. When planning to extract data or extend the functionality of a Moodle module, such as in this case, there are three design alternatives (Table 2). The first design approach for data extraction is to craft a tailored SQL (structured query language) query to the database that returns a given dataset based on the parameters used in the query; this option requires either the use direct access to the database and the use of additional drivers (such as in [57]) or the use of custom reporting plug-ins (e.g., [[https://docs.moodle.org/37/en/Custom_SQL_queries_report](https://docs.moodle.org/37/en/Custom_SQL_queries_report)]([https://docs.moodle.org/37/en/Custom_SQL_queries_report](https://docs.moodle.org/37/en/Custom_SQL_queries_report))), as well as the necessary privileges, knowledge about SQL syntax, and the structure of Moodle database. Furthermore, it is highly dependent on the specific internal identifiers of the course and workshop, which requires adaptation whenever a change affecting these identifiers occurs. Therefore, such a method could be considered only as a temporary solution. The second design approach entails the development of a Moodle local plug-in, generally written in PHP language, or the modification of the module files; this option can also be complemented with the use of an external application that processes the data from the plug-in or the modified module. Examples of these procedures are the extension of the functionality of the Moodle Workshop module in [55, 56]. There are two important drawbacks of the implementation of local plug-ins and modification of Moodle modules. First, the compatibility with newer versions of Moodle is not guaranteed, which in turn requires revising and updating (if necessary) the correct operation of the plug-in after any update of the LMS, or changing the module files after Moodle version update. Second, many LMS administrators are often reluctant to install external plug-ins (and plainly reject modifying original LMS files) due to security concerns. A third way to tackle the extension of Moodle functionalities is to use Moodle's native web service infrastructure, which allows external applications to collect or manipulate Moodle data. Moodle currently offers a series of web service API functions (named _core web service functions_) that allow accessing information about components of the LMS through different functions or methods (e.g., the _mod_workshop_get_submission_assessments_ function returns a list of all the assessments of a given submission).