23-05-26 Discussing GitHub and other GRSF related issues (FAO FORTH SFP)¶
Participants:
FAO (Marc Taconet, Bracken van Niekerk, Emmanuel Blondel, Aureliano Gentile)
FORTH) (Yannis Marketakis)
SFP (Susana Segurado, Merul Patel, Patricia Amorim, Arturo Munoz Albero)
Agenda¶
- Proposal to allow forking in the GitHub water_areas_vocabulary
- Adding UUIDs to water areas
- UUIDs for stock assessment areas
- Using intersection operator in semantic IDs
- Agreed modification to fetch_uuid_fishery endpoint to return TUs
- ?Also /gettracebilityunit endpoint to return fishery ID
- Marine Resource addition of "unassessed" to areas field
- Workflow to GeoServer/GeoNetwork?
- Permission to share example shapefile with interested party
- Evolution/archiving/deprecation of GRSF records
- Addressing seasonality in stock records
- Candidate inclusion of FS stocks in SOFIA
- Connecting SOFIA work to SFP and partners work on tracking status and improvements
- Agreed EEZ vs NJA approach
- Coding jurisdiction within lakes - not EEZ, but within NJA?
- Specific country questions
Meeting Notes¶
Proposal to allow forking in the GitHub water_areas_vocabulary
The participants agreed to allow forking for changes proposals.Adding UUIDs to water areas
As the GRSF Areas Database is on development status, maintenance is needed to apply the last agreed modifications (i.e., modification of fields, namespace, etc.).
When a namespace or an area_code is modified in the database, the combination of "namespace":"area_code" is modified, loosing the connection with the records Semantic Identifiers that were refering to the modified area.
This implies that every time a modification of "namespace" or "area_code" is implemented, the Semantic Identifier of all RAMLDB, FIRMS and FishSource records affected by these areas will need to be updated in the respective database.
Exmple:
"can_dfo_cfa" namespace needs to be updated to "can_dfo_scfa" as it has been spotted an error in the field Code_system (cfa-->scfa). Therefore, all areas in the code system will change their namespace (i.e., can_dfo_cfa:22 --> can_dfo_scfa:22). This will impact all records Semantic Identifier that use areas from this Code_system (i.e., asfis:CRQ+can_dfo_cfa:22 will need to be updated to asfis:CRQ+can_dfo_scfa:22 in FIRMS, RAMLDB and FIishSource independently)
This is an issue that will apply to many "grsf" namespace areas, such as:
grsf:HAK3_escr
grsf:USA_PFMC_Groundfish_EFH_RMGspc
For achieve an easier maintenance fo the GRSF Areas Database without impacting the GRSF Databases (RAMLDB, FIRMS and FishSource), it was proposed the inclusion of UUIDs or other type of identifiers that allowed the GRSF Records to be linked to that UUID/identifier instead of being linked to the "namespace":"area_code" of the GRSF Area Database. This would allow that the area part of the GRSF Semantic Identifier for records is constructed from the GRSF Areas Database.
Example:
A snow crab (asfis:CRQ) record from GRSF is linked to an area with identifier "YYYYY". This area identifier "YYYYY" points to area "can_dfo_cfa:22" in the GRSF Areas Database, so the GRSF Record Semantic Identifier is "asfis:CRQ+can_dfo_cfa:22"
If "can_dfo_cfa:22" changes in the GRSF Areas Database to "can_dfo_scfa:22" (cfa ---> scfa), maintaining the same area identifier "YYYYY", the GRSF Record linked to "YYYYY" would automatically update to "asfis:CRQ+can_dfo_scfa:22"
The use of UUIDs was pointed as a too difficult to maintain solution, that could create further problems in the future.
As the most problematic field of the GRSF Areas Database is the system_owner (organizations abreviations of some countries change often), it was proposed to construct a list of non-changing non-official abreviations of the organizations to refer to them even when the official abreviation is updated.UUIDs for stock assessment areas
As a continuation of the previous topic, it was discussed the possibility of building UUIDs for assessment areas polygons.
GRSF Records polygons are often built by management or statistical areas, or a combination of them.
When an assessment area is obtained by joining more than one management or statistical area, a joint polygon is displayed for visualization.
This resulting joint polygon would be linked to a UUID, or have its own semantic identifier.
For example, a record of European pilchard assessed by CECAF on the total area resulting of joining CECAF areas cecaf:A and cecaf:B would display these 2 areas as a joint polygon on the GRSF map viewer.
The combined areas polygon is an assessment area itself, so (for example) it could be coded as "cecaf_ass_pil:1" (CECAF Assessment area for asfis:PIL number 1)
Record SemID to include the combined assessment area:
asfis:PIL+cecaf:A;cecaf:B --> asfis:PIL+cecaf_ass_pil:1
This could also be a solution for item 2 of the agenda, although a mapping would be needed and maintained for the connection between assessment areas and official areas.
Finally, it was decided to further dicuss Item 2 and Item 3 in order to find the best solution for these issues.
Building assessment areas polygons should be explained in the guidelines provided to countries.
URLs should be added to each assessment area that merges polygons from other official areas.Using intersection operator in semantic IDs
Intersection of areas (instead of concatenation) is sometimes required for defining the area of a GRSF record with official water area codes. For example, the combination of National Jurisdiction Areas of Namibia, Angola and South Africa in FAO 41 would need the intersection of South Africa jurisdiction area with FAO 41 (excluding FAO 51 part).
The use of a different caracter refering to intersection (i.e., *, inverted U, etc.) would have priority and be applied before the concatenation ";". For example, the intersection of South Africa jurisdiction area with FAO 41 would be coded as "nja:ZAF*fao:41", and when combined with Angola and Namibia jurisdiction areas:
"nja:NAM;nja:ZAF*fao:41;nja:AGO"
These intersection should be clearly stated in FishSource before the importing to GRSF
Interesections would create a new area in GRSF and then concatenate. The intersection would need an independent note.
It was also presented the idea of exclusion (as an other operator as concatenation or intersection). For example the NAFO area excluding the Canadian jurisdiction area could be coded as "rfb:NAFO||nja:CAN"
This processes were agreed as possible solutions to be further explored in the GRSF.
Actions¶
