Using vocabularies

Form Input

You may link to vocabulary entries when inputting data in form fields.

While typing, the server searches vocabularies for matching terms. According to the ontology path definitions the system will automatically detect appropriate vocabularies (e.g. person lists for a "has mother" field). The system will propose a list of matching entries. In order to be able to disambiguate between similar names, the broader entries are also listed. Selecting one of the entries will link the edited object instance with the entry.

Form input

Semantically Annotated Text

You may also link to vocabulary entries when inputting free text.

Select a text snippet or an existing annotation so that the side menu will show matching vocabulary entries. Clicking on a menu item will link the snippet to the entry or replace the existing annotation with a new one that links to the entry. When hovering over an annotation or menu item, an infobox will pop up with additional information that is gathered from the vocabulary's fields.

WissKI free text editor

If you have the WissKI Search Entities module (on GitHub) enabled, you may also directly search the vocabularies instead of using the side menu: Select a text snippet or an existing annotation. Click on the vocabulary search button (the magnifying glass). A dialog window will pop up, enabling you to search the vocabulary entries by label. Hovering over an item again will show an infobox. Clicking on an item will annotate the selected text.

WissKI free text editor search

Infoblock and Infobox

Since version bcdb26dd1b, the Vocabulary Control module includes an infoblock and infobox as a replacement for the tooltip box of the Editor module.

The infoblock shows vocabulary information for the instance of the current page, while the infobox pops up as a tooltip when hovering over links to other instances. The latter is supported in various places in WissKI, e.g. in the structured data box when viewing an instance or the semantic editor (see above).

The infoblock is provided as a Drupal block that can be activated and configured accordingly. The infobox configuration page can be found under Site Configuration -> WissKI module settings -> Vocabulary Control -> Infobox. For both, you can specify the vocabulary fields that shall be displayed and their order. These can vary between block and box. Apart from the fields defined in the Vocabulary Control settings, five special fields can be selected:

  • Vocabularies A list of vocabularies the instance is a member of
  • URIs A list of alternative URIs for the instance. This is only of relevance if you link local data to instances of foreign/global vocabularies that have diverging URIs. (see below).
  • Broader entries A list of instances calculated from walking up the broader hierarchy. The broader field must be set properly for non-empty values.
  • An image If a field called image is defined, the first image found will be taken and displayed along with the data. For the infobox, you can choose the position of the image in the box using the option Position of image and map.
  • A map If the fields longitude and latitude are present, a small static map with a landmark showing the coordinates will be generated and displayed. By default, the map is clickable and links to an interactive version. This field is sensitive to the options URL of the static map image and URL of the link on a static map image. By default, Google Maps will be used for map generation.

Linking to Foreign/Global Vocabularies

In version db9ccbd921 the handling changed for foreign vocabularies, i.e. vocabularies whose entries have URIs that don't belong to the site's own namespace.
Before that version, the Vocabulary Control module would use the foreign URI directly. This has major drawbacks:

  • The foreign URI is asserted the class of the pathbuilder group associated with the vocabulary. Although this should not be of any harm in most cases, it may lead to confusion if the triple data is exported without filtering.
  • The instance cannot be viewed within WissKI as this requires a local URI prefix (same domain and path prefix as site). Instead, links will point to the external resource, leaving the WissKI website without notice. As the server that responds to the external URI most likely isn't aware of the local triple data, it will not be available on the presented page, leading to a lack of coherent user experience.
  • For the same reason, one cannot use WissKI's add and edit forms to change the structured data for such an instance.
  • There is no support for instances belonging to multiple vocabularies. This is especially necessary if you want to model that two vocabularies co-refer to the same thing.

The new design changes this import behaviour for entries with an external URI: it creates a "normal" local instance with a local URI and associates the external URI with that instance. The default to link local URIs to external ones is skos:closeMatch.1 When viewing such a local instance or hovering over it, the module fetches information from the associated external resources and displays it in the infoblock/box.

Now, you can add an instance from a foreign vocabulary to the local data via the WissKI add form as simple as linking to foreign entries in other fields before. E.g., for a person input form just select an entry from a foreign vocab in the name field.
This change does not affect the user interface. However, if you upgrade, be aware of the database table change: Uninstall and reinstall the module for the changes to take effect.

1Currently the property cannot be changed through the user interface. If you want to use another property you must edit wisski_vocab_ctrl.module (~ line 10) accordingly.