@lbarbot, yes, there are items that are deliberately not exported via API, the supporting materials. This is a conscious decision on our end.
New website is now live, landing pages now work. please re-harvest and consider import to production
The metadata in the <meta>
properties og:title
and og:description
should match the regular title
and description
.
These are used by e.g. Slack previews (https://medium.com/slack-developer-blog/everything-you-ever-wanted-to-know-about-unfurling-but-were-afraid-to-ask-or-how-to-make-your-e64b4bb9254).
@klaus.illmayer Sure, I am happy to forward any concrete request changes to the developer for implementation and improvement. A single list would be ideal though.
There is now a new field resource-directory-url
that has the link to the item's landing page.
Please note that we are returning the URLs as they will be and thus they don't work currently. We are still working towards the launch of our new website this month.
The author field has been corrected to array, strings are now trimmed and default to NULL if empty. API will continue to return single answer of all data.
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.
We plan to implement DINI/Nestor Schema for harvesting: https://doi.org/10.5281/zenodo.3784238
I think that's the idea...
They have a documentation how to do it as a user and it worked for me with DARIAH and eduTeams, but I can't get my Google account linked as that seems to already exist seperately... (all my CESSDA address, which is GSuite)
I would suggest to link staging to production AAI. After all, I assume more than just the core developers will log in there, e.g. to test new features, and you need to test staging against real dependencies.
we are stuck at "AAI is broken"
There should be a mechanism in EGI Check-in to do account unification or account-linking. That's at leats how the AARC BP is designed and you should redirect the user to Check-in to solve it there.
Unfortunately these things never really work well and the general recommendation is that the user will have to know which authentication method they use and never deviate from it. From the user's perspective this is not good enough and that's why we are stuck at "AAI is broken".
Now add on top to that that CESSDA uses eduTeams to manage groups. So if I want to have CESSDA's group memberships I have to choose eduteams, even if DARIAH is already available at EGI Check-in. That means I have to unify my Google Account and my DARIAH Account at both eduTeams and EGI Check-in and then unify my eduTeams account with the others at EGI Check-In as well. This is expected by design. Though I am extremely doubtful that any user will ever understand it.