Implement plugin system for registries/providers

gbv / cocoda

A web-based tool for creating mappings between knowledge organization systems.

https://coli-conc.gbv.de/cocoda/

MIT License

39 stars 5 forks source link

Implement plugin system for registries/providers #209

Closed stefandesu closed 5 years ago

stefandesu commented 5 years ago

To make use of the new config format (#64), and to properly integrate future additions such as mapping recommendations (#84), a plugin system for registries is needed. This would also make accessing APIs in Cocoda much cleaner. Currently, these plugins should be implemented:

jskos-api - access to vocabularies and concepts
jskos-mappings - access to mappings
jskos-occurrences - access to occurrences
local-mappings - access to local mappings
some way of getting recommendations from a Reconciliation API **
...

Each plugin should be a class or module whose instance provides different functions depending on the type of plugin. For example, there needs to be a way to differentiate between plugins that are offering vocabularies and concepts and plugins that provide mappings or any kind of mapping suggestions/recommendations.

** As the Reconciliation API is specific for a single concept scheme, this might have to be implemented differently.

nichtich commented 5 years ago

I'd rename plugin to provider and the individual providers to

concept-api
mappings-api
occurrences-api
local-mappings

which can be mapped to JavaScript classes such as ConceptApiProvider...LocalMappingsProvider. Reconciliation API could be configured the same way but with a mandatory key schemeUri:

  {
    "provider": "reconciliation-api",
    "schemeUri": "http://bartoc.org/en/node/18785",
    "baseUrl": "https://lobid.org/gnd/reconcile",
    "namespace": "http://d-nb.info/gnd/"
  },
  {
    "provider": "reconciliation-api",
    "schemeUri": "http://bartoc.org/en/node/1940",
    "baseUrl": "https://lobid.org/gnd/reconcile",
    "namespace": "http://www.wikidata.org/entity/"
  }

stefandesu commented 5 years ago

The ConceptApi still has to be implemented and all parts other than MappingBrowser have to be adapted to the changes. After all those changes are complete, I would consider taking some time to refactor the code. There will probably be lots of code pieces that are not used anymore due to the new system.

stefandesu commented 5 years ago

All these changes introduced a bug that in some cases, narrower will not get assigned the inScheme of parents, causing them to not be clickable anymore. This has something to do with a weird race condition when loading details for a concepts and should be fixed after refactoring.

stefandesu commented 5 years ago

As far as I know, there are no more issues left. Adjustment of MappingsApp will be done with #222. Any other bugs or changes should get their own issue as well.