Closed dpancic closed 1 year ago
In GitLab by @laureD19 on May 19, 2021, 13:37
added to epic &8
In GitLab by @laureD19 on May 27, 2021, 14:57
merge both vocab and manually create a new one:
In GitLab by @KlausIllmayer on Aug 5, 2021, 16:17
It is unclear to me how to merge both vocabularies. If I interpret the documents correct, then CESSDA only has a different naming convention compared to EOSC and uses a subset of the EOSC TRL. EOSC's TRL itself is derived from NASA's definition of "Technology Readiness Level".
I don't see a reason why we should use a combined version, as it becomes complicated to map data from different sources based on such a customised vocabulary. Please @vronk convince me from the opposite ;)
In the meantime, I rename the property to technology-readiness-level
(we used the wrong name technical-readiness-level
) and use only the EOSC TRL vocabulary. Mappings from CESSDA are no problem for 08 production and 07 beta, as EOSC TRL-08 and TRL-07 imply the same - only problem is CESSDA's development
because this could be everything from TRL-01 to TRL-06.
Adding @carsten-cessda-admin to the discussion
In GitLab by @vronk on Aug 6, 2021, 09:19
I preferred CESSDA's take on this, because it is much simpler and makes more sense to the end user. What does TRL3
means to an end user? Pretty much nothing. However, that the service is not yet at a beta stage, meaning it is still in dev (or never finished...), that makes sense. The other reason is that EOSC (MP) themselves do not make use of TRL-1
->TRL-6
, they discard/hide these resources until they reach at least TRL-7
, so why bother?
But what I was missing in CESSDA's 3 levels is the TRL-9
(actually EOSC seem to have modified the description for that one, @carsten-cessda-admin you might want to reconsider adding it to your levels, or simply merge 8 and 9 for your production).
And since we won't provide data to EOSC MP, no problem with the mapping. And in the other direction, from different sources, if we get TRL-2
or TRL-5
, we map it to our dev
and if we get TRL-9
, then we map it to our TRL-9
In GitLab by @carsten-cessda-admin on Aug 23, 2021, 12:30
Our definitions were based on https://wiki.eosc-hub.eu/display/EOSC/Service+Maturity+Classification Here, TRL-8 and TRL-9 did not make a difference for us, so TRL-8 was good enough, also as the only option. We will reconsider this, but I want to have a citeable version of the EOSC TRL, not just the API response.
In any case, we do not plan to distinguish our services in the 1-6 range, which is why we call it development. In that phase we do not promote the service anyways, so no need to be specific.
I support the use of the EOSC-CV, but I would prefer to have a way of just saying "below 7", which is effectively what we are doing in CESSDA.
In GitLab by @KlausIllmayer on Oct 21, 2021, 16:59
Unfortunately, we still need to think about the remarks by Carsten and Yoann and how to implement them into the vocabulary. It looks like that the best would be to have a custom SSHOC vocabulary either a merge of the two mentioned vocabularies or a small extension/modificatoin of TRL
In GitLab by @vronk on Nov 28, 2021, 17:52
If this still requires discussion, I propose to postpone it to after Final release.
In GitLab by @laureD19 on May 19, 2021, 13:37
the
technology-readiness-level
property is currently a string, should be modified to become a concept-based property.Vocabulary to be used: