Closed jdcourcol closed 1 year ago
cc: @MFSY
ping +1
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 https://github.com/BlueBrain/nexus-forge/issues/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.
In that case, can we fix the database ? This is our public data and I don't feel comfortable with the data being inconsistent.
The corresponding data of public/sscx project was checked and corrected.
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