Give vocabulary concepts a label

[KlausIllmayer]

Currently, concept can be created without a label. The minimum is code when creating a new concept:

POST /api/vocabularies/sshoc-keyword/concepts?candidate=true

{
  "code": "only+code"
}

This leads to problems in the visualisation of the concepts, e.g. in the Skosmos instance that we use for the representation of the concepts: https://vocabs.sshopencloud.eu/browse/sshomp-keyword/ You already see in this overview page of Skosmos, that there are 2264 concepts in the keywords vocabulary but only 702 within the language English. The missing 1562 concepts are the ones not having a label because the language tag in the export of a vocabulary only attaches the language to the label field. In general, having a label is more or less mandatory practice for SKOS concepts.

To sum up: the SKOS export of a vocabulary from marketplace will only apply language tags to the label field (the label field in marketplace becomes skos:prefLabel with language tag @en in the SKOS export). If there is only code given - which is currently possible - then the concept does not have a label and therefore no hint on a language. SKOS representation systems like SKOS expect that there is a label field (skos:prefLabel) which ideally also have a language tag. We use Skosmos for representation and Skosmos "hide" concepts without label/language tag in the hierarchy and in the search.

Thus we like to have label mandatory when creating concepts. We will deal with the old concepts having no label by applying the code value to the label value with the help of a script. Backend should additionally only allow the creation of concepts with a label (next to code) or should automatically apply the value of code to the value of label if no label is given.

Opinions? @tparkola @laureD19 @vronk @cesareconcordia

[tparkola]

For the sake of simplicity and clearness I would change the API, so that it expects both code and label (otherwise raises an error). What do you think?

[KlausIllmayer]

Agree with this, but we still need to think about the old ones that do not have a label. I think the only way to deal with them is to have a update script that sets label=code if label is not set. Would that work?

[tparkola]

Yes, that would work, the script can be provided along the changes in the code. Will do that.

[KlausIllmayer]

Works very well, the only new feature(?) to me is that error messages are now coming back in an extend JSON version:

{
  "timestamp": "2024-01-09 12:44:00",
  "status": 400,
  "errors": [
    {
      "field": "label",
      "code": "NotEmpty",
      "args": [
        {
          "codes": [
            "conceptCore.label",
            "label"
          ],
          "defaultMessage": "label",
          "code": "label"
        }
      ],
      "message": "The label of a concept cannot be empty or null!"
    }
  ]
}

Before we had a flat JSON:

{
  "timestamp": "2024-01-09T12:53:03.794+0000",
  "status": 403,
  "error": "Forbidden",
  "message": "Access Denied",
  "path": "/api/vocabularies/sshoc-keyword/concepts"
}

Don't get me wrong, I like the extend version but I'm not sure if frontend handles it correct. @tparkola Is this change in the return format of errors intended?