Currently, the legacy-id field in conceptScheme is ignored. It does not have an effect on the created URL for the conceptScheme. The only field that is respected is the identifier-field. Here we run into the problem described in #58.
Depending on the solution for #58 we either need legacy-id as a possibility to generate a custom conceptScheme URI or we find another solution which then may result in removing the legacy-id-field from the conceptScheme edit form.
I tend to use the identifier of conceptScheme as baseURI and to have a dedicated field to extend this baseURI with custom values, e.g. adding /Scheme. Generally spoken, we run here into many issues if we like to check plausibility of the generated URLs. I'm currently fine without checks, but we need to think about some rules how this can be better controlled, e.g. avoiding URLs having //.
Currently, the legacy-id field in conceptScheme is ignored. It does not have an effect on the created URL for the conceptScheme. The only field that is respected is the identifier-field. Here we run into the problem described in #58.
Depending on the solution for #58 we either need legacy-id as a possibility to generate a custom conceptScheme URI or we find another solution which then may result in removing the legacy-id-field from the conceptScheme edit form.
I tend to use the identifier of conceptScheme as baseURI and to have a dedicated field to extend this baseURI with custom values, e.g. adding
/Scheme
. Generally spoken, we run here into many issues if we like to check plausibility of the generated URLs. I'm currently fine without checks, but we need to think about some rules how this can be better controlled, e.g. avoiding URLs having//
.