biblinks in DaCHS

[BaptisteCecconi]

There seems to be a discrepancy between the content of the biblinks.json file and the info page:

E.g:
http://dc.zah.uni-heidelberg.de/__system__/biblinks/links/info

The keys of the JSON are using _ (underscore) instead of - (dash). This is a minor issue, but it should be fixed.

[msdemlei]

On Wed, Mar 20, 2024 at 01:53:30AM -0700, Baptiste Cecconi wrote: There seems to be a discrepancy between the content of the biblink.json file and the info page: E.g: http://dc.zah.uni-heidelberg.de/__system__/biblinks/links/info The keys of the JSON are using `_` (underscore) instead of `-` (dash). This is a minor issue, but it should be fixed.

Ummm... For all I can see, the labels in the output json are as specified, right? So, what bugs you is the labels on the DaCHS info page, right? If so... well, the technical reason for the underscores is that this reflects SQL column names ("regular identifiers"), and these don't admit dashes. But then biblinks.json (the only renderer admitted on the service) doesn't expose the field information anyway. To solve this, I'd hence say (a) DaCHS shouldn't give any output fields on the info page for that service on grounds that there isn't a service on top of that data that would expose column metadata. Alternatives I could see: (b) use delimited identifiers to make column and json key names match (yuck. If delimited identifiers look like a solution, most likely the problem is wrong :-) (c) doing nothing; the fields *would* come out if I defined a tabular interface on top of this (e.g., a form service), and biblinks.json doesn't really do tables anyway, so one could argue the non-applicability of the output field metadata is sort of implied. As long as you're not asking for (b), I'm happy to resolve the situation in any way you consider reasonable.

[BaptisteCecconi]

My comment is indeed about the info page, which doesn't conform to the specification. The output is correct.

I updated #3, removing the dashes in the terms, and that would solve your internal DaCHS issues...

[msdemlei]

On Wed, Mar 20, 2024 at 03:14:07AM -0700, Baptiste Cecconi wrote: I updated #3, removing the dashes in the terms, and that would solve your internal DaCHS issues...

Oh, no, it's not going to be *so* simple; I'm adamant about not having camel case in database names, so the columns would still be with underscores. The question still is: is this bad? There probably is less potential confusion between camel case and snake case...