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

_mediaType/content-type are not consistent with encoding format. #286

Closed
jdcourcol opened this issue Jan 16, 2023 · 5 comments
Closed

_mediaType/content-type are not consistent with encoding format. #286

jdcourcol opened this issue Jan 16, 2023 · 5 comments

Comments

@jdcourcol
Copy link

There is a "encodingFormat" property in the distribution and a "_mediaType" property on the file entity.

Issue: kgforge should make sure that both values are the same, as currently we have entities with:
"encodingFormat": "application/asc" for the distribution
"_mediaType": "application/octet-stream" for the entity of type "file"

The "application/octet-stream" is obviously wrong for a morphology of type "neurolucida ascii".

In addition, "_mediaType" is what is returned by the response header in content-type when downloading a file, therefore the content-type is set to "application/octet-stream" when the browser makes an HTTP request.

Example : https://bbp.epfl.ch/nexus/web/public/sscx/resources/d220681a-56af-4938-846d-01c8e77c3d3a?rev=2#JSON

@jdcourcol
Copy link
Author

cc: @MFSY

@jdcourcol
Copy link
Author

ping +1

@crisely09
Copy link
Contributor

This is interesting, because the encodingFormat value in the distribution comes from the _mediaType value once the file is registered, this is done with the file-to-resource-mapping file, so they are by construction the same.

What has happened, which I believe is the same cause for #279, is that files are updated separately, some kind of automatic file update, or even manual updates.

I may be wrong but I don't believe the solution of this is forge related, we need to find the source of the files' update, and for the existing cases fix the mismatch in the resource' distributions and their linked files.

@jdcourcol
Copy link
Author

In that case, can we fix the database ? This is our public data and I don't feel comfortable with the data being inconsistent.

@crisely09
Copy link
Contributor

The corresponding data of public/sscx project was checked and corrected.

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

2 participants