Enhance DCAT interface to support MatVoc specifics

[TBoonX]

For

• NOMAD
• DMMS

This task is about using specifics of MatVoc like classification to enhance the DCAT interface.
The technical basis is the work for WP4.2.
The classification is the one from WP2.3

[TBoonX]

We need to specify with what and how much we will enhance the metadata aggregation.
I think we need to include our classification somehow for WP 4.3

[yoavnash]

Hi @TBoonX, we now have the MatVoc representation of the tensile test datasets, which we would like to present to you in one of the next meetings (see an email from Matthias). In the mean time, can you provide us with details on how to extend the DSMS'S API so that it serves this information?

[TBoonX]

Dear @yoavnash , good to hear about progress.
In general we are free to include the triples we need into the DCAT interfaces/harvester. A first step would be to use the SKOS classification to enrich the DCAT data. On which objects we add the triples could be discussed in such a meeting but using dcat:theme to connect to SKOS triples would be the common start.
After adding the classification we are free to add what makes sense - what a researcher is interested in when searching through the metadata.

[TBoonX]

NOMAD DCAT API returns SSL error: ERR_INVALID_SIGNED_EXCHANGE
@markus1978 are you still the person to contact when something like this happens?

[markus1978]

I have a good idea why this happens. I can release a fixed version in a couple of days.

It is not an SSL or certificate issue. The API wrongly returns some HTTP headers that some browsers disallow in a HTTPS exchange. Until the fix, the API should still work in most "non-browser" use-cases, e.g. curl, requests, etc.

[TBoonX]

I encountered it with my python code which uses the API and it worked half a year ago.
Thanks, a fix would be nice.

[markus1978]

Mmh, the issue I am suggesting is in there for a loooong time. Maybe the underlying SSL impl got more restrictive. Or my initial analysis is wrong and it is something else. Anyhow, I investigate and try to fix it.

[markus1978]

It should be fixed now.

[TBoonX]

Thanks for the fast deployment.
It is working again in the browser even that there are issues with the certificate.
I assume that my docker container is using a newer version of python, thus the new error.
The same error occurs with sparql.stream-dataspace.net even that the certificate is alright.
I will have a look and try to resolve it on my code - I will give feedback when there is something new.

[markus1978]

This has to be something else? Yesterday, I was looking at Chrome. It was sending an accept header to the API with all kinds of mime types in it, including application/signed-exchange. The API tried to interpret this to determine in which format to return results. The bug was that the API reflected the same accept header back as content type including application/signed-exchange. This was not accepted by the chromes https implementation. This probably causes issues with other clients as well.

I just fixed the accept header handling and made sure that the returned content type is something meaningful like application/rdf or application/xml instead of application/signed-exchange.

If there are issues with the SSL certificates. I would need more information about the error. All checks I can do on the certs seem to be fine.

[TBoonX]

The browser now accepts the website and certificate completely.
My code has still issues which I have to investigate.
Thanks!