Configuring Vocabularies (I)
While the Accesspoint module provides a common access to triple datapools, the Vocabulary Control module defines how to integrate these datapools as vocabularies. A vocabulary consists of a set of entries, each having a fixed number of fields (properties/values). These fields serve to uniformly access certain information common to all or some vocabularies, while each vocabulary may choose whether to fill a field or not. Fields are used to capture properties like the prefered label (the only one that is mandatory), alternate labels, spatial coordinates or references to broader/narrower/parental entries. In order to link local data with a vocabulary entry, the WissKI system needs to know how to handle the entry's information. Thus, the entry has to be mapped to a local Pathbuilder group and it's fields to ontology paths. This mapping mechanism is the core functionality of the Vocabulary Control module.
Generally, an accesspoint may back more than one vocabulary. For example, an accesspoint pointing to a remote WissKI installation containing data on persons, places and museum objects may serve as source for three vocabularies, each containing entries on either of the categories.
Vocabularies can be administered under "Site Configuration" -> "WissKI module settings" -> "Vocabulary Control". The main page lists all defined vocabularies.
Creating a new vocabulary
Vocabularies may be created on the admin pages by clicking on the tab "Add".
A vocabulary definition is made up of general vocabulary settings, the field settings defining the ontology path mappings and indexing settings. The general information comprises a user friendly name, the backing accesspoint and a priority. The priority will influence the ranking of the entries compared to entries of other vocabularies. The higher the priority the better the rank.
For the mappings you first have to define the group, which the entries will be treated as. After that, you define the mappings for the fields. (If you need to create new fields, read here.) For each field in the Import path column you may define a path to which the value of the field will be mapped. If <None> is selected, the field is not defined for the vocabulary. The Query pattern column selects the SPARQL triple pattern which will retrieve the fields value from the accesspoint. For SKOS data there are predefined patterns. See here on how to define your own patterns. If set to <None>, the pattern is the same as the one defined by the import path. This is especially useful and advisable when creating a vocabulary from local data or data that has been modelled using the same ontology and ontology paths as the local system.
Note: The Import group field allows to choose only groups of the Import tree of the Pathbuilder! If you want to use groups of other pathbuilder trees for vocabularies, you have to make them visible in the Import tree as well. Go to the edit page of the group and check the import checkbox.
It is recommended to create one vocabulary for each Pathbuilder group (or at least the most important ones) in the local system, so that linking your local data will be facilitated.
Indexing of labels
For each vocabulary you may specify whether the entries' labels (fields Label and Alternate Label) should be indexed. Vocabularies backed by the local store are automatically indexed. Indexing is particularly useful in case of big vocabularies or remote endpoints where making lots of queries imposes performance issues. Furthermore, the automatic text analysis of the Textproc module will consider indexed labels only (manual annotation is possible, though). Hence, if you want your vocabulary to be automatically annotated, use indexes.
The index settings can be found on the Add/Edit page of the vocabulary (click on the Edit link on the vocabulary list page). You can either run the indexing process manually by clicking on the Index now button or define an interval after which the index will be rebuilt automatically. The latter should only be chosen if the vocabulary is expected to change frequently, like the WissKI store of another running project. Use the former whenever possible and do an indexing right after the vocabulary is set up.
Note: This default indexing routine is reported to cause problems on big vocabularies or vocabularies on remote stores. Especially if you encounter timeouts, memory limit issues, blank pages, etc. you can use the advanced indexing.
Create custom fields
The field settings can be managed in the Fields tab of the admin pages.
The Vocabulary Control module comes with some predefined fields that serve certain functionality:
- Label fields provide labels/names for an entry. The searching a vocabulary typically means searching entries with an according label. Label fields are:
- Label: the preferred label of an entry. This field is mandatory, i. e. there must always be an import path.
- Alternate Label: an entry may have several alternative names that are represented by this field.
- Hierarchy fields establish an ordering on the vocabulary's entries. There may be one or more top entries. The kind of ordering is not defined, but it's typically hyperonomic or meronomic. Hierarchy fields are:
- Broader: links to entries that are somehow "broader" than this entry. (This is similar to the SKOS property skos:broader).
- Narrower: links to entries that are somehow "narrower" than this entry. (This is similar to the SKOS property skos:narrower).
- Geographic fields are suited for gazetteers that provide geo-information for locating entries (ie. places, etc.) on the earths surface. Geographic fields are:
- Longitude: the geographical longitude in decimal degrees.
- Latitude: the geographical latitude in decimal degrees.
Apart from these predefined fields, you may define custom fields. The new field will have no special functionality. It merely ensures that the values will be imported when linking to an entry. This may be useful when certain additional information shall be imported and shown in the dual view form field.
To create a new field, fill in the last row of the table in the field admin page. The target type of the field can be either literal (ie. a value) or same class as source (ie. pointing to another entry of the vocabulary). The field will be added upon saving the form.
Developers: Modules may define their own fields and provide special functionality for them. The module imports a field by inserting a row in the database table wisski_vocab_ctrl_fields. It just has to take care that there are no duplicate IDs (fid).