SGV and Incunabula ARK URLs not working
Closed this issue · 16 comments
If I remember correctly, the Incunabula ARK URLs generated by the old SALSAH can’t work with Knora, because the old SALSAH uses project shortcode 0801 for Incunabula, but in Knora, 0801 is BEOL. Is that the problem here?
I don't think so. The ARK resolver says that these URLs are invalid:
Incunabula Narrenschiff (lat.): http://ark.dasch.swiss/ark:/72163/0803-3b7598ebb7b-9.201986
SGV Image SGV_04P_03518.TIF: http://ark.dasch.swiss/ark:/72163/0812-1388a5fb712a4-d.201986
I can’t check now, but I think the timestamp is invalid. The PHP code has a bug causing it to omit leading zeros before the month and day. Try it with this timestamp: 20190806
incunabula: https://ark.dasch.swiss/ark:/72163/0803-3b7598ebb7b-9.20190806
SGV: http://ark.dasch.swiss/ark:/72163/0812-1388a5fb712a4-d.20190806
Added zeros. Both still not working. The project shortcodes are correct in both cases. I think that @lrosenth fixed them.
The project shortcode for SGV is actually 080C in hexadecimal but the ARK URL provides it as a decimal value of 0812, which is correct.
To make the ARK resolver accept version 0 ARK URLs for a project, you have to add this to the project's configuration:
AllowVersion0: true
We decided to require this because of the conflicts between PHP project codes and Knora project codes. This way, we only support version 0 ARK URLs for a project if we're sure the project code is supported.
I'll make the error message more helpful.
but the ARK URL provides it as a decimal value of 0812, which is correct.
I didn't know that the PHP ARK URLs used decimal instead of hexadecimal for project shortcodes. Is this really necessary? I think it's going to cause confusion. It would be better if the PHP code used hexadecimal, too.
Great, the AllowVersion0: true config setting solved it. Now the two links work.
but the ARK URL provides it as a decimal value of 0812, which is correct.
I didn't know that the PHP ARK URLs used decimal instead of hexadecimal for project shortcodes. Is this really necessary? I think it's going to cause confusion. It would be better if the PHP code used hexadecimal, too.
I don't think that Lukas is going to touch the old Salsah code. Anyway, the ARK URLs are out there as they are. Probably easier to assume that version 0 ARK URLs have the project shortcode as a decimal value and then to transform it, if necessary.
Probably easier to assume that version 0 ARK URLs have the project shortcode as a decimal value and then to transform it, if necessary.
OK, I'll do that.
great, thanks :-)
A gift that doesn't stop giving ;-)
The project shortcode for SGV is actually
080Cin hexadecimal but the ARK URL provides it as a decimal value of0812, which is correct.
Decimal 0812 converted to hexadecimal is 032C, not 080C.
Hexadecimal 080C converted to decimal is 2060, not 0812.
I don't understand what the PHP code is doing. @lrosenth, can you please explain?
If it's converting one byte at a time, then would hex FFFF be converted to decimal as 255255?
Answer: the PHP SALSAH ARK URLs only contain project codes starting with 08.
Here is a SALSAH ARK URL in which the project ID is entirely in hexadecimal:
https://data.dasch.swiss/resources/2126045
It looks like this is inconsistent in the database: some are in decimal, and others are in hexadecimal.
It turns out that they're all in hexadecimal, and it's the DaSCH ARK resolver data that needs to be corrected.
The original issue was fixed by changing the config. For further questions and bugs, please open separate issues.