Support new item type: registry

[nichtich]

JSKOS Registries are used in Cocoda to manage data sources and in BARTOC for the list of terminology registries. The latter is managed in a plain NDJSON file but should be moved into a jskos-server database (https://github.com/gbv/bartoc.org/issues/70). By now, registries are only referenced in GET /voc.

Requires additional endpoints:

• GET /registries
• GET /registries/:_id
• PUT /registries/:_id
• DELETE /registries/:_id
• GET /registries/suggest

Registries should also be returned by GET /data endpoint for known URI.

And maybe:

• PATCH /registries/:_id (I don't think we actually need this but if its two lines of code why not)
• POST /registries (requires minting new URIs, we don't use UUID URIs in BARTOC so better not)

We should also review existing registry data in Cocoda config and in BARTOC to possibly adjust registry data model.

[stefandesu]

We should also review existing registry data in Cocoda config and in BARTOC to possibly adjust registry data model.

Absolutely. The term is used for different things at the moment and it should be clarified.

POST /registries (requires minting new URIs, we don't use UUID URIs in BARTOC so better not)

How do registries get into the server without a POST endpoint? It does not necessarily require minting URIs with UUIDs if we decide how URIs are built (e.g. with the notation in lowercase). It also doesn't have to be publicly accessible, but I'd rather have it implemented like this for easier import.

[nichtich]

How do registries get into the server without a POST endpoint?

Ok, POST with existing URIs in the posted records should be possible!

[nichtich]

Requires https://github.com/gbv/jskos/issues/110. As discussed there, a JSKOS Registry corresponds to a (subclass of) dcat:Catalog and it may have one or more services. These services (currently given in non-standard field API) correspond to cocoda-sdk registries and to dcat:DataService.