Feature #1991
closed
Import controlled vocabularies via API
Description
The VOCABS service of the ACDH-CH has an API which can be used to import controlled vocabularies into OpenAtlas.
Branch: feature_vocabs
Questions:- Do we want to import only published hierarchies or also stages (except INDIGO)? -> authentication for staging area required, currently in production.py: VOCABS_USER and VOCABS_PW
Choose language if available*(if label is not available in that language, the default language will be used)Choose multiple*Choose which OpenAtlas classes are linked*Make ID, URI and API URI as input field and not config varsMake for each Thesaurus a new reference system *- Make preview as type tree
Resources
Swagger of the Skosmos API: https://vocabs-api.acdh.oeaw.ac.at/ (choose HTTPS to try it out)
Try it out resolves to https://vocabs.acdh.oeaw.ac.at, INDIGO is still on https://vocabs.acdh-dev.oeaw.ac.at/ and password protected (Bernhard has the credentials)
All vocabularies: https://vocabs.acdh-dev.oeaw.ac.at/rest/v1/vocabularies?lang=de
INDIGO: https://vocabs.acdh-dev.oeaw.ac.at/rest/v1/indigo/
INDIGO top concepts: https://vocabs.acdh-dev.oeaw.ac.at/rest/v1/indigo/topConcepts
To get the narrower of a concept: https://vocabs.acdh-dev.oeaw.ac.at/rest/v1/indigo/narrower?uri=https://vocabs.acdh.oeaw.ac.at/indigo/ActivitiesF
(Thanks to Klaus for the input)
Updated by Bernhard Koschiček-Krombholz 9 months ago
- Related to Feature #1663: Controlled vocabularies via Vocabs added
Updated by Bernhard Koschiček-Krombholz 7 months ago
- Description updated (diff)
- Status changed from Assigned to In Progress
- Target version changed from 7.16.0 to 7.15.0
Basic functionality is implemented and works for every hierarchy.
Updated by Alexander Watzinger 7 months ago
- Precedes Feature #2019: Redesign admin area added
Updated by Bernhard Koschiček-Krombholz 6 months ago
- Description updated (diff)
Works well.
One question arise, should we import top concepts as hierarchy or should we make a single hierarchy with all concepts:
- topConcept
- subconcept
- subconcept
- topConcept
- topConcept
- sub concept
Advantage: each top concept can have another OpenAtlas class
Disadvantage: topConcepts cannot have an external reference link, clustering the custom type overview
- Vocabulary
- topConcept
- subconcept
- subconcept
- topConcept
- topConcept
- sub concept
- topConcept
Advantage: topConcepts can have an external reference link
Disadvantage: only the Vocabulary can be linked to OpenAtlas classes, therefore can the type selection be cluttered at the input/edit view
Updated by Alexander Watzinger 6 months ago
Just to be sure we talking about the same: do you mean with INDIGO top concepts these: agents, objects, activities , ...?
In that case I would say each should be an own hierarchy because they could be used for different entity classes. Also, the top concepts shouldn't be select-able anyway.
Updated by Bernhard Koschiček-Krombholz 6 months ago
In case of INDIGO, yes these are the top concepts. The thing is, that we will lose the external reference link for these concepts, because afaik there is no external reference system for hierarchy.
But then I will implement Option 1.
Updated by Alexander Watzinger 6 months ago
- Precedes Feature #2026: External reference systems for type hierarchies added
Updated by Alexander Watzinger 6 months ago
These are two different topics so I created an issue for adding reference systems to type hierarchies (#2026).
And yes, please go with option 1.
Updated by Bernhard Koschiček-Krombholz 6 months ago
- Status changed from In Progress to Resolved
Feature is done in feature/vocabs branch.
There is a minor issue within the vocabs/skosmos API, which Klaus will look into. The issue is, that some concepts don't provide a prefLabel and are therefore nameless. I solved it, that these concepts are not imported into the database. The skipped concepts are logged.
Also, duplicate topConcepts are not again imported and are logged. Duplication right now can only be checked by the name, so if the language is changed, it will not be a duplicate.
Updated by Bernhard Koschiček-Krombholz 6 months ago
- Status changed from Resolved to Closed