KPI calculation again: need to be fully transparent about that

[bansp]

This is a new issue, so that we can let #273 rest in peace after the last adjustment mentioned there.

The context for this issue is the progress report for CLARIN, where I have just had to perform calculations by hand, while we should be able to present them in the SIS.

Obviously, one obstacle to that is the level of curation on the part of centres -- but that is being worked on, and we need to give it time, while being open about it and mentioning the issue at various meetings (such as the upcoming CAC), and, fundamentally, we need to actively support the TCC is their now cyclic task of getting centres to use the SIS. Until that is fully handled, we need a crutch or a sort, a way to influence the KPI calculation so that it gets as precise as we can make it, given the information lag wrt CLARIN registry, individual centre decisions, etc.

1. Crutch no. 1 we need an attribute or element that will indicate whether the centre has published its own recommendations, even if it doesn't share them. Perhaps an element that points to the relevant page.
2. Crutch no. 2 -- an attribute, I guess, that marks the fact that while the centre doesn't publish their own recommendations, they skirt around the certification requirements (in the case of B-centres), by pointing somewhere (effectively, pointing at the sky) and saying "we want what it says there", even if it says something largely off-topic if not harmful (like advocating the LMF standard from 2008, which is withdrawn by now). Just an attribute, because I'd rather not propagate that information, merely recording the fact that the centre performs that manoeuvre.

Information for both 1 and 2 is updated semi-regularly in issue #14 .

3. We need an explicit calculation or perhaps several, on the KPI page. It looks like there are two possible bases for the calculation: the number of B-centres and the number of depositing centres. Secondly, we can count centres that (a) curate their info in the SIS plus those that post their info locally (one calculation, for the two bases), and then count these plus the centres that are pointing at the sky (we can call that a reporting KPI, in contrast to the real KPI, except we probably don't want to do that explicitly, sadly). That calculation is also going to hold for two bases.
4. Finally, for housekeeping, we should indicate all the values in the centre statistics page, and visualise at least crutch no. 1 on the individual centre pages.

Now let's have a list of dependent tasks:

• full processing of registryLink, including RIs #300 -- because this is a case where one recommendations file should be counted as 2 centres
• ...

[bansp]

It seems to me that only crutch no. 1 should be implemented. Centres that only send the user elsewhere simply do not publish their own requirements. And thus they do not count for the KPI.

I would implement crutch no. 1 as an element with URI content (single URI, we're not out to document a multitude of self-published recommendations by a single centre). The KPI calculation would then use the curated centres + the uncurated self-publishing ones.