StocksAndFisheriesKB

Hi @aureliano.gentile@fao.org and @marketak@ics.forth.gr,

with a query on SOLR index I detected the 2 (1374-1372=2) records of GRSF_ADMIN with a resource named "RAM" that are not assigned to any "ram" group: "grsf-stock-ram", "grsf-stock-firms-ram", "grsf-stock-firms-fishsource-ram", "grsf-stock-fishsource-ram". The records are:

| name                                 | title                                      | extras_GRSFUUID                      | extras_systemtype | extras_RecordURL                                                               | groups                                                                                                                                   | res_name                                     |
|--------------------------------------|--------------------------------------------|--------------------------------------|-------------------|--------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------|
| 4d6f3906-6a74-3505-9ac4-df02a17bbb34 | Merluccius merluccius - Western Ionian     | 4d6f3906-6a74-3505-9ac4-df02a17bbb34 | Assessment Unit   | http://data.d4science.org/ctlg/GRSF_Admin/4d6f3906-6a74-3505-9ac4-df02a17bbb34 | abundance-level,abundance-level-firms-standard,catches,fishing-pressure-firms-standard,grsf-assessment-unit,grsf-stock,scientific-advice | RAM,Fishing Pressure,State and Trend,Catches |
| 4c315909-e34e-3f32-81cd-99ef3bbbc2fd | Oncorhynchus keta - Primorye chum hatchery | 4c315909-e34e-3f32-81cd-99ef3bbbc2fd | Assessment Unit   | http://data.d4science.org/ctlg/GRSF_Admin/4c315909-e34e-3f32-81cd-99ef3bbbc2fd | grsf-assessment-unit,grsf-stock                                                                                                          | RAM                                          |

so Yannis can add them to the proper group/s.

In my opinion, maybe, to limit this kind of errors, Yannis could implement a programmatic check that after a publishing stage, running the program it could verify the "counts" and the consistency between KB numbers and Catalogue numbers.
From a Catalogue point of view, it is possible to count the items published in the catalogs of "GRSF" and "GRSF_ADMIN" VRE using the "count" facility provided by gCat Service (see at https://wiki.gcube-system.org/gcube/GCat_Service) developed by @luca.frosini@isti.cnr.it

For Example:

To get the number of items belonging to group "Stock - RAM" the query is:

https://api.d4science.org/catalogue/items?q=groups:grsf-stock-ram&count=true&gcube-token={{GRSF_PUBLISHER_GCUBE_TOKEN}}

(in the context of GRSF_ADMIN, so GRSF_PUBLISHER_GCUBE_TOKEN = the token of grsf.publisher user in the "GRSF_ADMIN" VRE)

the response is:

{
count: 1167
}

Groups (and tags) are assigned during publishung/updating from the publisher service.
From our side, we are providing the json representation of the record (without any indication about groups or tags).
Attached you'll find the json representation for one of the "problematic" records.

So I think @francesco.mangiacrapa@isti.cnr.it should check why this json is not added in the proper group.

I'm going to investigate the issue