Skip to content

Vocabulary

Vocabulary

  • In this section we expose the full extent of the possibilities concerning the vocabulary in Maggot.
  • Choosing the type of vocabulary and how to enter it depends entirely on what you put in the terminology definition file. However, some approaches require a little technicality by writing small scripts based on JavaScript, but nothing too serious. You can always take an already ready-made script and modify only the part that concerns your focus.


1 - Vocabulary based on a list of terms fixed in advance (checbox with feature open=0)

  • List of well-chosen and limited Control Vocabulary e.g according to a reference e.g. Data Document Initiative.


2 - Vocabulary open for addition (checkbox with feature open=1)

  • allows you to collect the desired Control Vocabulary (CV) from users. In order to initiate the list, you can put some terms in the predefined terms column of the terminology definition file.


3 - Vocabulary based on a web API in a text field (textbox)

  • The web API is defined in a JavaScript file with the same name as the assigned variable (here cities) and must present under web/js/autocomplete. For example, to enter a French city you can use the API geo.api.gouv.fr. See cities.js


4 - Vocabulary based on a dictionary with multiple selection (multiselect)

  • Dictionaries allow you to record multiple information necessary to define an entity, such as the names of people or even the funders. These information, once entered and saved in a file called a dictionary. Based on a very simple JavaScript retrieving the complete list of items included in the dictionary, thus creating a sort of internal API, we can fill a Maggot field by autocompletion related to a search for these items.
  • The JavaScript file must be named dico.js and be present under web/cvlist/dico/ where dico is the name of the dictionary. See for instance people.js


5 - Multi-select vocabulary, based on an API managed by Twitter's Typeahead library. (multiselect)

  • Maggot embeds Twitter's Typeahead library making it relatively easy for a data manager to implement a new vocabulary from its web API. With the help of this library, this allows users to select a term from a list of vocabulary terms within a drop-down list. The list of terms has been pre-selected based on the first letters entered in the “Search for value” box. This list is dynamically refreshed when letters are added or modified. So, unlike a single call to the API returning the entire list of terms in memory, which can take a very long time to load, the calls are made dynamically on the basis of a portion of a word (3 letters minimum by default), limiting the number of terms to retrieve. Thus this makes use very fluid.

  • To implement an API-based web service, it is necessary to create two scripts (<ws>_typeahead.js and <wstype>.inc) which will each be used at one stage of the process as shown in the following figure:

  1. <ws>_typeahead.js : This file corresponds to the API call when entering vocabulary using Twitter's Typeahead library. The prefix <ws> standing for web service, must be positioned so as to correspond to the name of the service indicated in the CVname column of the mapping file (see mapping) as well as to the corresponding value for the 'ws' attribute in the column 'features' of the terminology definition file (see definitions). This file must then be placed under the web/js/autocomplete directory. You will find a template file in this directory.

  2. <wstype>.inc : This file corresponds to the API call while metadata crosswalks processus and based on the mapping file (web/conf/mapping.txt).The prefix <wstype> standing for web service type, must be positioned so as to correspond to the type of the service indicated in the CVtype column of the mapping file. This file must then be placed under the web/inc/mapping/ directory. You will find a template file in this directory.


  • By defaut, Maggot already provides some vocaburay web services implemented in this way such as the ontology portals based on OntoPortal, the SKOSMOS thesauri and the EMBL-EBI Ontology Lookup Service. The figure below shows the configuration in the terminology definition file and the corresponding screenshots for each vocabulary.

  1. AgroPortal and BioPortal are both based on OntoPortal which is a generic technology to build ontology repositories or semantic artefact catalogues.

  2. SKOSMOS is a web tool facilitating the posting of controlled vocabulary online in the form of a thesaurus according to the SKOS data model. It offers a navigation interface as well as a web API.

  3. EMBL-EBI Ontology Lookup Service is a repository for biomedical ontologies that aims to provide a single point of access to the latest ontology versions. You can browse the ontologies through the website as well as programmatically via the OLS API.

Note: we also support the Terminology Service for NFDI4Health given that it is also based on OLS.


  • Here is, for example, the implementation of the INRAE Thesaurus, a web service based on SKOSMOS. The figure below shows in more details how to fill in the definition files linked to the two scripts necessary for implementing the web service :