Project

General

Profile

GRSF ยป

22-03-29-GRSF import records

Discussing the GRSF interface for importing new records developed by FORTH https://isl.ics.forth.gr/grsf/grsf-api/import.jsp

Participants:

FAO (Anne Elise Nieblas, Aureliano Gentile)
RAMLDB (Arturo Munoz)
FORTH (Yannis Marketakis)

Meeting Notes

The purpose of the meeting to is inspect the GRSF-API import facilities.

Key points

  • The import page does not generate an error message if something went wrong. For example, we provided a CSV file (instead of an XLSX file) and after uploading that an empty page appeared.
  • How the XLSX file is parsed? The uploaded file is parsed by relying on the index of the columns. This means tha the first column will be the ID, the second the name etc. FORTH mentioned that this can change in order to rely on column headers. It has been agreed to leave it as it is for the moment.
  • Whitespace characters in the column headers could be problematic. Since we rely on column indexes and not column headers, we can rename them as we like (e.g. adopting a CamelCase or underscore-based approach)
  • System and Code (e.g. in species) should be in upper or lower case? We can provide them as we like.
  • A factsheet URL does not exist for the provided records. We can make the field optional and generate a factsheet URL (since this is required for the GRSF Refresh workflow) based on the Database Source URL and the ID of the record (in a similar manner as we do in GRSF for RAM records)
  • Can we have extra columns in the template? Yes as soon as they appear after the predefined ones.
  • The database source will be FAO SDG 14.1.1
  • The default behavior of the import facility is that: (a) creates a legacy record, (b) constructs the corresponding GRSF record
  • Multiple owers are supported for records, therefore a semicolon-separated list of owners is accepted.
  • The fields Reference Years, Reporting Years, State and Trend, Assessment Methods, Scientific Advices should be moved under timeseries.
  • Validation of provided species, assessment areas. Aureliano asked if the contents of the species are validated (e.g. the given ID w.r.t. The given system, indeed corresponds to the given scientific name). Yannis replied that for the moment this does not happen. However, we will be able to use the new vocabularies to do that
  • In the case of areas (or other information) without system and code, such information should be provided as UNK (e.g. UNK:UNK:area name)

  • Proposed the addition of 3 new columns at the end of the template. More specifically:

    • Action. This is selected from a controlled vocabulary [APPROVE, ARCHIVE, MERGE, MERGE & APPROVE] and inform the API about the post-construction and post-publishing activities of the new GRSF record.
    • UUID of approved record. Use this field to indicate either (a) the UUID of the record that should be merged with the current one (this assumes that the corresponding Action column is set to MERGE), or (b) the UUID of an already published GRSF record whose contents should be updated. In the latter case, instead of creating a new legacy and GRSF record, the already published one will be updated with new information that are provided from the XLS template.
    • Dominant Record. This field is used for identifying if the current record will be the dominant one in the case of a merge event. If the value is set to YES, then the record from the template will be the dominant one, otherwise the one that is already published (and its UUID is defined in the previous column) will be used. Clearly, the corresponding action in the column Action would be MERGE).

  • A request for providing the results from the competency queries pages in CSV format has been made. Yannis to investigate

Actions

  • FAO to update the Excel template and return to FORTH
  • FORTH to update the importer according to the new template and the discussions held above

Resources

Add picture from clipboard (Maximum size: 8.91 MB)