search

SSHOC / vocabularies

0 stars 0 forks source link

technology-readiness-level vocabulary #12

Closed dpancic closed 1 year ago

dpancic commented 3 years ago

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:

dpancic commented 3 years ago

In GitLab by @laureD19 on May 19, 2021, 13:37

added to epic &8

dpancic commented 3 years ago

In GitLab by @laureD19 on May 27, 2021, 14:57

merge both vocab and manually create a new one:

dpancic commented 3 years ago

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

dpancic commented 3 years ago

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

dpancic commented 3 years ago

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.

dpancic commented 2 years ago

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

dpancic commented 2 years ago

In GitLab by @vronk on Nov 28, 2021, 17:52

If this still requires discussion, I propose to postpone it to after Final release.