StocksAndFisheriesKB

See also the GRSF API http://62.217.127.124:8080/grsf-api/resources/stock_data?uuid=151d2126-c13f-3599-8259-b46388bff388 it has the same issue with multiple values for the same year.

Thanks Yannis, I am referring to BdivBmsypref and UdivUmsypref (Biomass and Mortality) which even if they come from a different assessment, then we should have the assessment ID (assessid) which is not the case in the above reported error/unexpected behavior of the GRSF catalogue. If the harvest of data is correct, then I guess you concur thinking that we need to distinguish such time series from different assessments.

From: Gentile, Aureliano (FIAS)
Sent: Friday, 07 September, 2018 9:23 PM
To: Nikos Minadakis minadakn@ics.forth.gr
Cc: Yannis Marketakis marketak@ics.forth.gr; Pasquale Pagano pasquale.pagano@isti.cnr.it; Francesco Mangiacrapa francesco.mangiacrapa@isti.cnr.it; Luca Frosini luca.frosini@isti.cnr.it; Νίκος Μηναδάκης minadakn@ics.forth.gr; Taconet, Marc (FIAS) Marc.Taconet@fao.org; Ellenbroek, Anton (FIAS) Anton.Ellenbroek@fao.org; Anton, Paula (FIAS) Paula.Anton@fao.org
Subject: Re: Issues with GRSF

Yes exactly, thanks for that Nikos, the issue would be to display the ram assessment id next to each value so to distinguish the different time series.
Thanks and wish you a nice weekend.
Aureliano

Da: Nikos Minadakis
Inviato: venerdì 7 settembre, 18:11
Oggetto: RE: Issues with GRSF
A: Gentile, Aureliano (FIAS)
Cc: Yannis Marketakis, Pasquale Pagano, Francesco Mangiacrapa, Luca Frosini, Νίκος Μηναδάκης, Taconet, Marc (FIAS), Ellenbroek, Anton (FIAS), Anton, Paula (FIAS)

Dear Aureliano, I investigated on the timeseries. There is nothing wrong. There are many values for the same year because they are coming from different assessments as noted by the accessment id in ram. The raw data of them are like: WGWIDE-HERRNORSS-1988-2013-ICESIMP2016 HERRNORSS Norwegian Spring Spawning Herring BdivBmgttouse 2013.0 1.0012 WGWIDE-HERRNORSS-1988-2015-ICESIMP2016 HERRNORSS Norwegian Spring Spawning Herring BdivBmgttouse 2013.0 1.0 WGWIDE-HERRNORSS-1950-2014-ICESIMP2016 HERRNORSS Norwegian Spring Spawning Herring BdivBmgttouse 2014.0 0.8132 WGWIDE-HERRNORSS-1988-2015-ICESIMP2016 HERRNORSS Norwegian Spring Spawning Herring BdivBmgttouse 2014.0 0.891

This is an example according to the issue that you included in the ticket.
As you can see for the same stock and the same year there are many values because of a different assessment id.
This is why you see multiple values for the same stock data page.
Now if the issue is why the assessment id is not visible then this is something that we should check together with our cnr colleagues.
We can discuss further in monday. Best, Nikos

Sorry for my late reply.

Reading the above comments I understood that assessment ID should be contained in the timeseries, if this is correct... the field 'assessid' is not visible because it is missing in the resource attached to record (i.e. https://goo.gl/ddwV7E), so this is not a catalogue displaying problem.

I suppose that the source json of a record has also the field 'assessid'... so I think there was a problem publishing the resources by the publishing-service and @luca.frosini@isti.cnr.it should check on this. Otherwise, @minadakn@ics.forth.gr or @marketak@ics.forth.gr can clarify, how are 'assessid' published in the catalogue?

Anyway, it would be really useful to attach to the current ticket at least one source json related to above records.

The assessment IDs are published for the legacy records. So, for the record http://data.d4science.org/ctlg/GRSF_Admin/151d2126-c13f-3599-8259-b46388bff388, you should check it's source record (in particular http://data.d4science.org/ctlg/GRSF_Admin/9046a39b-7da8-39f5-a8ea-ef32c522f32e) and then check the timeseries (e.g. Abundance Level), where you'll see the assessment IDs.

@marketak@ics.forth.gr, i am not sure to understand your explanation.
Are you saying that we should combine the information contained in two or more records and perform this operation at publication time?
If the answer is yes, i believe this is not doable and this is not in line with what we did until now. The content is prepared by the KB that has to remain the authoritative source of information.

If instead, I have not understood what you were proposing, please be so kind to add additional details.

Thanks @aureliano.gentile@fao.org

This is exactly what I described. Assessment IDs are valuable for the legacy record (in this case for the record coming from RAM). When publishing in GRSF they are omitted. If we want to keep this type of information for GRSF records, I see two options:

1. We store in the same field with the reporting year (as we do with legacy records)
2. We store them in a new field dedicated for this purpose.

The first option does not require any changes from the catalog and the publisher, while the second one does need the creation of a new field.

Either the two options are fine, indeed as separate field might be better but for now also in the same field is fine, also considering the original requirement, in fact the field is called "reporting year or assessment id". Whoever will use such data will easily understand that, for example, assessment id "WGWIDE-HERRNORSS-1950-2014-ICESIMP2016" refers to data for the reporting year = 2016.
In conclusion, and also to speed up this bug fix, in case of RAM, when assessment ID is available, this needs to be maintained in the GRSF record and not substituted with an unclear reporting year value. (Actually this rule was already working properly, it broke recently...)
Thanks a lot, please, if things are not clear enough do not hesitate to launch a quick call and we can try to better explain and understand each other through Skype.

Hi @marketak@ics.forth.gr,

In order to make available Assessment IDs also for GRSF records, I didn't understand if they are omitted in GRSF source json or there was a problem during the publication stage in the GRSF publishing service.

In the first case, you should add Assessment IDs and then republish the GRSF records, while the second one for us it would be useful to have a GRSF source json (e.g. the source json of http://data.d4science.org/ctlg/GRSF_Admin/151d2126-c13f-3599-8259-b46388bff388) to investigate and then fix the issue.

@francesco.mangiacrapa@isti.cnr.it they were omitted during the publication of GRSF records (as they should), so you don't have to investigate something.

The issue has been resolved.

As a proof of concept, I ve updated one GRSF record (http://data.d4science.org/ctlg/GRSF_Admin/151d2126-c13f-3599-8259-b46388bff388).

After resolving other issues, I will update all the GRSF records (#12906)