All comments reviewed

Author: ferag

docs/architecture.md

@@ -7,12 +7,12 @@ Each plugin is oriented to define the way to access metadata and data, as well a
 
 * **`plugin.py`** – Python code defining how to retrieve metadata/data and how to calculate scores for each indicator.  A plugin inherits from one of the base classes and overrides methods to suit its repository. This class inherits form the `EvaluatorBase` base class.  Plugins derive from these classes and inherit core methods or reimplement those representing each indicator.  When a plugin is instantiated, it loads its configuration values from both a global configuration file and the plugin’s own `config.ini` file.  These values influence how the tests are executed—e.g., which metadata fields to examine, which vocabulary to use and which protocols are considered acceptable.
 
-* **`config.ini`** – an INI file containing configuration parameters that adjust the generic tests to the repository.  Common settings include the list of metadata fields used for identification (`identifier_term`), lists of fields to assess metadata richness (`terms_quali_generic` and `terms_quali_disciplinar`), fields that should include controlled vocabularies (`terms_cv`) and the accepted access protocols.  For instance, the **signposting** plugin declares its generic and disciplinary richness terms and controlled vocabulary terms in `config.ini`【760299466290588†L7-L29】.
+* **`config.ini`** – an INI file containing configuration parameters that adjust the generic tests to the repository.  Common settings include the list of metadata fields used for identification (`identifier_term`), lists of fields to assess metadata richness (`terms_quali_generic` and `terms_quali_disciplinar`), fields that should include controlled vocabularies (`terms_cv`) and the accepted access protocols.  For instance, the **signposting** plugin declares its generic and disciplinary richness terms and controlled vocabulary terms in `config.ini`【760299466290588†L7-L29】. Notice that there are two different config files, the API `config.ini` where general configuration can be edited and plugin `config.ini`.
 
 * **`translations/`** – optional message catalogues for internationalisation.  FAIR EVA uses [Flask‑Babel](https://palletsprojects.com/p/flask-babel/) to provide multi‑lingual support.
 
 At runtime, the evaluator loads the appropriate plugin and merges its configuration with global defaults.  Plugins may also define **term mappings** when the repository uses different naming conventions.  The **OAI‑PMH** plugin, for example, maps repository‑specific field names to standard FAIR concepts such as “Data Identifier”, “Format” and “License”【304540372057503†L1-L24】.  This mapping enables the evaluator to operate on a common set of terms regardless of the repository.
 
 ## Configuration flow
-The `fair.py` script and the web application (`web.py`) both read configuration files using Python’s `configparser`.  First, the `config.ini` of the plugin(s) to load is parsed, followed by the plugin’s `config.ini`.  The combined configuration is passed to the plugin instance【364219770113321†L17-L27】.  This two‑tiered approach allows you to define global defaults (e.g., a list of controlled vocabularies or generic metadata terms) while overriding or extending them in plugin configurations.
+The `fair.py` script and read configuration files using Python’s `configparser`.  First, the `config.ini` of the plugin(s) to load is parsed, followed by the plugin’s `config.ini`.  The combined configuration is passed to the plugin instance【364219770113321†L17-L27】.  This two‑tiered approach allows you to define global defaults (e.g., a list of controlled vocabularies or generic metadata terms) while overriding or extending them in plugin configurations.
 

docs/installation.md

@@ -1,6 +1,6 @@
 # Installation
 
-FAIR EVA can be run locally via Python or containerised with Docker. For development, clone the repository and check out the branch:
+FAIR EVA can be run locally via Python or containerised with Docker. For development, clone the repository:
 
 ```bash
 git clone https://github.com/IFCA-Advanced-Computing/FAIR_eva.git
@@ -44,11 +44,14 @@ docker run --name=fair_eva \
 
 The container exposes two ports: 9090 for the REST API.  Once the container is running, you cna run tests requesting HTTP to `http://localhost:9090` in your browser to access the evaluation dashboard.
 
+## Web client
+Older versions of FAIR EVA integrated API and Web client in the same repository. In this version, a new web client can be found in a separated repo. [Web Client](https://github.com/IFCA-Advanced-Computing/fair_eva_web_client)
+
 ## Configuration files
 
 FAIR EVA reads configuration parameters from INI files.  When running the evaluator, two files are loaded:
-<!-- TODO: revisar este párrafo -->
+
 1. **Global configuration** – typically named `config.ini` or derived from `config.ini.template` in the project root.  It defines generic terms, supported vocabularies and repository mappings【634087979570097†L31-L45】.
-2. **Plugin configuration** – located at `plugins/<plugin_name>/config.ini` (in each plugin repo).  It customises the tests for a specific repository.  For example, the **GBIF** plugin defines which metadata fields correspond to identifiers, licences, access protocols and controlled vocabularies【274614149785346†L16-L57】.
+2. **Plugin configuration** – located at `plugins/<plugin_name>/config.ini` (in each plugin repo).  It customises the tests for a specific repository.  For example, the **GBIF** plugin defines which metadata fields correspond to identifiers, licences, access protocols and controlled vocabularies.