12 January 2023 - New year call discussing the SFP Area database and the GRSF (FAO, SFP)¶

• Table of contents
• 12 January 2023 - New year call discussing the SFP Area database and the GRSF (FAO, SFP)
  • Meeting Notes
  • Actions

Participants:
FAO (Aureliano Gentile, Bracken van Niekerk)
SFP (Susana Segurado, Patricia Amorim, Arturo Muñoz Albero)

Meeting Notes¶

1. English vs local name, mandatory vs to be collected if available (e.g Chile; Russian). For abbreviations/codes should we keep the “official”? But need a decision on other alphabets, always use Latin? No accents? Ç or ñ

   GRSF is disseminating in English for now so default language should should be English, but agreed it makes no sense to translate area names e.g. Los Lagos.
   Decision: keep one field for official romanized area name, whether in English or not, SFP can track the respective language.
   There are no issues with different characters and accents as long as we use UTF 8.

2. Proposal for rules to define namespace:
   a. If no country present, include system owner
   b. If for one country, there is more than one system owner, then include system owner
   c. If for one system owner, there is more than one system, include system
   d. Question around whether this is a good practice, as it means if we add e.g. another system owner later, then it will adjust previously defined namespaces

   Decision: not add anything not needed for differentiation. E.g. if DFO is not needed, do not include it.
   Questions: on GFCM_GSA: drop GSA if GFCM has only one system. For other RFMOs, follow the same rule, IPHC has no other system.
   Actions: check both GFCM and also IOTC assessment areas.

3. The "grsf" namespace and the possibilities of differentiating per country/organization (i.e. "grsf_phl", "grsf_ices", etc) as applicable.
   i. Cases of Japan, Russian 61.01east, intersection of FAO 27.9.a with ESP jurisdiction.

   Japan: problem of not being able to identify an authoritative source for codes. But logic is that we are not trying to build a "gsf" system. The "grsf" namespace is a sort of parking lot, while we wait for something better. When we have some information but it is not official.
   Russia: have not foud an official reference.
   Proposed rule: use "grsf" when metadata is incomplete, but shapefile is not mandatory and another format (e.g. narrative, pdf) is acceptable.
   Action: Keep going and see how many "grsf" entries we encounter, and then revisit if we need to split into multiple namespaces.

4. The possibility of areas intersection codification (i.e. phl_reg:6 area within the phl:11 area --> phl_reg:6(phl:11) or phl_reg:6phl:11) with more codes than ";" for concatenation.

   Proposal that an intersection is a new area, so should be included in namespace "grsf".
   Proposal to use && to code an intersection, ! a negation (e.g. excluding a certain area), and explore other logical operators as needed.
   Action: test if use of logical operators works, and the use of the "grsf" namespace in these cases.

5. Upper or lower case letters

   Namespace codes were adopted as lower-case for readability. Codes should be as in the original usage.

6. Underscores or dashes

   Not discussed

7. For gear code, use numeric code or abbreviation, e.g. ISSCFG: 3.19 or ISSCFG: TB.

   Problem with using the abbreviations, although they are more human-readable, is that the top-level items, e.g. Surrounding Nets, do not have standard abbreviations.

Actions¶

• Actions: check both GFCM and also IOTC assessment areas for how many Systems they own.
• Action: Keep going as see how many "grsf" entries we encounter, and then revisit if we need to split into multiple namespaces.
• Action: test if use of logical operators works, and the use of the "grsf" namespace in these cases.