Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAIR EOSC: FAIR e-Infrastructure Service vs FAIR Research Infrastructure Services #32

Open
CaroleGoble opened this issue Jul 31, 2017 · 2 comments
Assignees

Comments

@CaroleGoble
Copy link

At the EOSC Summit I expected quite some discussion about the differences between FAIR Data services

  1. EOSC e-Infrastructure services : file storage, general catalogues, AAI, metadata needed for finding files, compute resources, etc
  2. Research Infrastructures using the EOSC services : data sets, subject specific catalogues, specialist Commons

But there was little discussion about (1). It was mostly (2). In fact there seemed a huge disconnect between the two. Most (2) use commercial services not EU services.
the NIH FAIR Data Commons RFA (https://commonfund.nih.gov/sites/default/files/RM-17-026_CommonsPilotPhase.pdf) recognises this and actively encourages partnership with commercial service providers.

We need:

  • common FAIR services
  • federated services
  • to clarify and respect the roles of EOSC and RI services
@LeifLaaksonen
Copy link

I wasn't at the EOSC Summit so I might be here on thin ice. This goes a bit into the philosophical side but I believe our thinking is too much caged by the fact that after we create a name for something (we want to achieve) it will rapidly turn into something physical. To me EOSC has been from the beginning rather a process than a physical infrastructure with services. In much the same way as FAIR is not to me a set of hardware services but a process. I don't even see (1) and (2) as Carole define them! We need a process (EOSC) that turns Europe into an open science landscape where data is handled in the FAIR way. To achieve this we need all the hardware components Carole mentions in (1) and (2) and both commercial services/service providers as well as services provided by the current European research infrastructure in a federated way. What makes this further challenging is of course the fact that we are not talking about a European landscape but a global one.

@peter-wittenburg
Copy link

Thanks to Carol and Leif.
Let me add my 2 cents here and also admitting that I was not at the EOSC summit.
Yet I don't know what FAIR services are: guess that these are services that may help to make data FAIR.
And it is also not quite clear to me what Carol means with EOSC versus RI services. The main reason is that I do not know what EOSC services are or could be. EOSC was a brilliant idea to convince policy level people that there is a goal which we should achieve, but it lacks anything concrete that would help to imagine how this could look like or how it should be done. If we don't formulate this as a critic then we come to what Leif is expressing: EOSC is a process and I guess that this is what the inventors of the term have in mind. Policy level colleagues throw a mistery into the room and we are all staring at this mystery and trying to give it life.
At this moment the only thing we have in our hands are the FAIR principles and this is good. With FAIR we found an easy to understand packaging and a Common Language. It seems that we all can join in since many of us have now years of discussions about these issues using different packagings and languages and thus not reach this common message level.
If I understand the terminology Carol is using I would fully support her 2 firsst points:

  • we need services that help to make data FAIR and as I indicated in another comment, there are communities that do this for more than a decade now with great success and getting the data seal of approval etc for their repositories etc. Most of these services are indeed common, however, metadata operations (editors, etc.) are partly schema based where they to include discipline specific details. Commonality in certain tools could easily end up in unmanageable complexity.
  • I also agree with the need of federated services which was the starting point of for example EUDAT and basically is the approach for most of the ESFRI research infrastructures. But at which layer do we want federation services? Cloud software manufacturers implement federation at a very low level and achieve distributed services. In EUDAT for example (and there are many other examples) the participating communities/centers wanted to have federation at a higher level to maintain some level of independence etc..

With respect to the third point I see the following devide. Within the EOSC discussions I observed from my distant view point two camps. On the one hand you have those colleagues who correctly argue that we will need a lot of copper and iron etc. to be able to provide the capacities we will need in a few years to process/transfer all the data. On the other hand you have those colleagues who come more from the scientific side and argue that it is urgently needed to overcome the fragmentation and the silo mentality. People tell me that the first group exactly knows what they want, while the second group is diverse, all having their own ideas, etc. The latter is understandable since overcoming fragmentation and silo mentality is a new territory.
It seems that in Europe there is little opportunity to come to a joint approach - not sure whether this is what Carol means with the "disconnect".
But I do not see how commercial partners can solve this, since in commerce you have as much as silo mentality as in science. Some believe that putting all kinds of data into a big cloud will solve the issues. How much time will it take to convince everyone that this assumption is wrong?

Good points you raised if I got you right. But how far should we as a FAIR group go with arguing about EOSC? Guess we only can specify requirements or steps that need to be taken independent whether they are eInfrastructures or RI. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants