Make sure all providers have a providerType

gbv / cocoda-sdk

SDK for Cocoda and coli-conc services

https://gbv.github.io/cocoda-sdk/

MIT License

5 stars 1 forks source link

Make sure all providers have a providerType #64

Open nichtich opened 1 year ago

nichtich commented 1 year ago

All providers (except local mappings) should have a providerType for #34. Currently missing:

[x] lobid provider should have type http://bartoc.org/api-type/lobid-gnd (just introduced)
[x] reconciliation provider should have type http://bartoc.org/api-type/reconciliation
[ ] occurrences-api provider should have a new API type (needs investigation: occurrences API provider follows outdated endpoint and may better be renamed to subjects API)
[ ] mappings provider and concepts provider should be merged unter type http://bartoc.org/api-type/jskos (needs investigation)

stefandesu commented 1 year ago

Quick note that so far, providerType has only been used to determine the concept registry for a vocabulary. I do agree though that every provider should have this, as it would also allow us to move more registry entries out of the Cocoda config and into BARTOC.

stefandesu commented 1 year ago

For now, all providers that offer access to concept data have a providerType. If we start adding it to other providers, there might some things we need to adjust in src/lib/CocodaSDK.js because it is currently assumed that registryForScheme only returns registries with concept data access.

nichtich commented 1 year ago

The use case is access to concepts from a specific vocabulary, so we better stick to providers returning concept data (which should include reconciliation provider, no?), although the name providerType may be misleading. Possibly documentation needed only to close this issue.

stefandesu commented 1 year ago

providers returning concept data (which should include reconciliation provider, no?)

Technically you're right, as the reconciliation API itself returns concept data. However, the Reconciliation provider returns mapping suggestions, not concept data.

I personally think it would be good to have all APIs that are related to a specific vocabulary in the BARTOC data (API field), no matter what type of data it actually is. The type of data can be determine through the API type, as long as it's supported in BARTOC (otherwise it's unspecified).

I'm still unsure about merging ConceptAPI and MappingsAPI. Technically it's just one API - JSKOS API - so it would make sense to merge it. But I'd need to check of this has consequences for Cocoda because there might be assumptions in the code that one "registry" does not offer both concept data and mappings data.