Review registry item type

[nichtich]

The registry item type seems to have been used for both description of terminology registries in BARTOC and for configuration of actionable data sources in Cocoda/cocoda-sdk.

[nichtich]

Current use of registry fields in BARTOC:

  2 altLabel
 51 API
102 definition
  4 endDate
 17 identifier
121 prefLabel
 26 startDate
 54 subject
121 type
121 uri
121 url

Of those only API and type need to be reviewed. As discussed in #63, the current type URI http://purl.org/cld/cdtype/CatalogueOrIndex should be changed to dcat:Catalog. The current format of API is just two fields type (from BARTOC API types) and url (API Endpoint URL).

Current use of cocoda-sdk registry fields (dev instance and Cocoda default):

  4 api
  8 definition
  1 excludedSchemes
 13 notation
  1 overrides
 13 prefLabel
 13 provider
  6 schemes
  6 status
  1 stored
  1 subject
 13 uri

In fact the cocoda-sdk registries more corresponds to BARTOC registries field API to describe a data source or service. This is roughly the same as dcta:DataService.

Review of JSKOS Item type registry (not no be confused with cocoda-sdk registries):

• change type URI to dcat:Catalog (#63)
• possibly remove fields not used anyhow: concepts, schemes, types, mappings, registries, concordances, occurrences. Relation between JSKOS items and registries is better expressed reverse via partOf (schemes is used in cocoda-sdk registries so it may have its use here)
• compare existing fields with dcat properties of dcat:Catalog
• introduce a field to replace API with standardized entity, possibly a revision or subset of cocoda-sdk registry object type

The latter (API) should be renamed to service (see dcat:service) or accessService (see dcat:accessService) with field:

• type : this should be renamed and be mapped to dcterms:conformsTo as defined in DCAT
• url might be renamed and should be mapped to dcat:endpointURL
• possibly add something like dcat:endpointDescription

cocoda-sdk registries can have additional fields to specify multiple API endpoints (status, api...) and additional configuration, depending on API type (overrides, stored...) - these might better be not standardized as part of JSKOS.