Close

December 8, 2019

Wisski Vocabularies guide

Setting up controlled vocabularies

To enable the semantic editor you first have to set the controlled vocabularies you want to annotate with the semantic editor.

You need to install the Vocabulary Control module (on GitHub), which depends on the Accesspoint module (on GitHub). If you want to statically import external vocabularies, you will also need to enable the Accesspoint Store module (it’s shipped as submodule of the Accesspoint module). In order to actually use vocabularies you have to define ontology paths and groups with the Pathbuilder module first as described in the Installation guide.

The Vocabularies Guide explains all necessary steps to configure accesspoints and vocabularies and how to use the vocabularies.

Configuring Accesspoints

The Accesspoint module provides a common SPARQL interface to local and external RDF datapools. The Controlled Vocabularies module will fill its vocabularies with entries using this interface.

The module is only visible for the user through its admin pages under “Site Configuration” -> “WissKI module settings” -> “Accesspoint”. The main page lists all defined accesspoints. There is always at least an accesspoint called ‘Local’, representing the local WissKI triple store.

wisski

The list contains the accesspoint’s name, the endpoints URL, and possible operations. In most cases, a click on the URL will direct you to a SPARQL interface where you can post queries.
Further accesspoints may be added by clicking on “Add”. There are different types of accesspoints for different modes to access datapools. As modules may provide their own accesspoint types, the available types may vary. At least the following should be available.

Accesspoint types

Inter-WissKI

Connect to another WissKI instance and use the data in its local WissKI triple store as vocabulary. The other WissKI instance needs to have the Endpoint module (on GitHub) installed and set up.
You can provide the following settings:

  • the base URL of the other WissKI instance (mandatory)
  • a read key for authentification (optional) (see also the WissKI Endpoint module)
  • a connection timeout (optional); if you experience problems when connecting to the remote store you can try to increase this value

wisski

SPARQL Endpoint

Connect to an arbitrary SPARQL endpoint, like e.g. dbpedia. Be sure to have read access on that endpoint at least for SELECT queries.
You can provide the following settings:

  • the endpoint’s URL (mandatory)
  • additional parameters if the endpoint requires so (they are encoded as query strings)
  • a connection timeout (optional); if you experience problems when connecting to the SparQL endpoint you can try to increase this value

There are already lots of endpoints running out in the web. See e.g. the WissKI Authorities page or a list of endpoints on the W3C wiki.

wisski

Store

Only available when Accesspoint Store module is enabled (shipped together with the Accesspoint module). Create a local triple store beneath the WissKI store in which triple data may be statically imported. Use this when there is no external SparQL endpoint for the data — e.g. when data is only availbale as file — or if you have timeouts or other speed related issues when directly querying.

wisski

After creating a store, you can use the import link (on the accesspoints list page, Operations column) to import a file. You can either specify the URI of the file or upload a file from your local machine. The URI may be a local path on the server. Thus you can address files previously uploaded via ftp or similar.

For importing big data files, WissKI provides the big file mode. It reads files in n-triples format (If your file is not in n-triples format you have to convert it first. There are freely available conversion tools, e.g. Rapper.) Try the big file mode if normal import mode fails. Experience says, files greater than 100MB are likely to fail in normal mode.

wisski

seeAlso http://wiss-ki.eu/vocabularies_guide