Project

General

Profile

Actions
Copy link

Feature #1991

closed

Import controlled vocabularies via API

Added by Bernhard Koschiček-Krombholz over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Bernhard Koschiček-Krombholz
Category:
API
Target version:
7.15.0
Start date:
2023-03-20
Estimated time:

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
To do (* required):
  • 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 vars
  • Make 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)

Related issues 2 (0 open — 2 closed)

Related to OpenAtlas - Feature #1663: Controlled vocabularies via Vocabs ClosedMassimiliano Carloni2022-03-22Actions
Precedes OpenAtlas - Feature #2026: External reference systems for type hierarchiesClosedAlexander Watzinger2023-03-21Actions
Actions
Copy link
 #1

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Related to Feature #1663: Controlled vocabularies via Vocabs added
Actions
Copy link
 #2

Updated by Bernhard Koschiček-Krombholz over 1 year 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.

Actions
Copy link
 #3

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #4

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #6

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #7

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #8

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #9

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Description updated (diff)
Actions
Copy link
 #10

Updated by Bernhard Koschiček-Krombholz over 1 year 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:

Option 1:
  • 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

Option2:
  • Vocabulary
    • topConcept
      • subconcept
      • subconcept
    • topConcept
    • topConcept
      • sub concept

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

Actions
Copy link
 #11

Updated by Alexander Watzinger over 1 year 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.

Actions
Copy link
 #12

Updated by Bernhard Koschiček-Krombholz over 1 year 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.

Actions
Copy link
 #13

Updated by Alexander Watzinger over 1 year ago

  • Precedes Feature #2026: External reference systems for type hierarchies added
Actions
Copy link
 #14

Updated by Alexander Watzinger over 1 year 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.

Actions
Copy link
 #15

Updated by Bernhard Koschiček-Krombholz over 1 year 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.

Actions
Copy link
 #16

Updated by Bernhard Koschiček-Krombholz over 1 year ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF