Namespaces and Imports section

Namespaces and Imports

The Namespaces and Imports page allows users to set prefix-namespace mappings, to owl:import ontology vocabularies and to edit the ontology mirror, a local mirror of ontologies stored within

Namespace Management

The namespace management section allows for two operations:

• to refactor the baseuri and default namespace of the edited dataset.
  The "chain" symbol keeps the baseuri and namespace aligned.
  The alignment follows this convention:
  • baseuris ending with neither hash (#) nor slash (/) will correspond to a namespace identical to them, ending with a hash (#) (as in the case in figure above)
  • baseuris ending with hash (#) or slash (/) will correspond to a namespace identical to them (e.g. baseuri: http://my.thes/ --> namespace http://my.thes/
• to create or override prefix-namespace mappings
  • the + / - buttons at the top of the section allow the user to add a new prefix-namespace mapping or to remove the selected one. The "-" symbol is greyed out in case no mapping is selected or if the mapping is a predefined one (i.e. preset by factory, such as those for the basic vocabularies of the RDF family and other notable ones (e.g. dc: dublin core)
  • the "penci" button allows to edit the currently selected prefix-namespace mapping

Imports

Please notice that the operation described in this section allows the users to owl:import an ontology, that is to state that the ontology being edited in VB depends on the content of another ontology and thus has to import its content. If the intent is instead to load the data that has to be edited inside the project, then the load data functionality from the Global Data Management menu should be selected.

The imports panel in the Namespace and Imports section allows the authorized user to owl:import ontology vocabularies into the current project. The menu offers five options, as in figure below:

The options refer to the source where to look for the ontology

• Web: imports the ontology by looking on the web for it, using the URI of the ontology for localization
• Local file: imports the ontology from a local file available in the hard disk
• Ontology mirror: imports the ontology directly from the ontology mirror
• Dataset catalog: imports the ontology exploiting the Dataset Catalog
• Local project: imports the ontology from a local project

In the following example, the FOAF ontology is being imported, and stored in the mirror as file foaf.rdf

The other options are the following:

• Alternative URL: not mandatory, if specified, tells where to download the ontology from (does not use the ontology URI)
• Force format: the format should be provided by the server in the form of a MIME type. If this non mandatory parameter is specified, then the server is asked specifically for that format and/or the interpretation of the content is forced to the specified format if the server is not providing the format information at all
• Resolve transitive imports from: this option has four choices:
  • Web: tries to import all transitive imports (i.e. ontologies imported in turn by the ontology being imported) from the Web
  • Web with fallback to Ontology Mirror: tries first from the Web and if it fails, it looks in the Ontology Mirror
  • Ontology Mirror: tries to import all transitive imports from the Ontology Mirror
  • Ontology Mirror with fallback to Web: tries first from the Ontology Mirror and if it fails, it looks in the Web

After the ontology has been imported, it will be added to the tree of imports in the Imports section and its content will be visible, with a lighter color, in the various data views. In the figure below, the classes of the FOAF ontology are visible in light orange. The lighter color means that they are read-only elements.

Failed imports

It can happen that a transitive import of an imported ontology cannot be imported (usually, from the Web) nor it is satisfied by an already imported ontologies. Such an import is dubbed a "failed import", and it is marked with a red cross in the imports tree.

On the right of a failed import, there is a button with a warning icon, which can be clicked to show a menu with various repair options. These differ mainly in the source of the ontology, with alternatives corresponding to analogous import options.

Import update

All ontology imports (including transitive ones) can be updated, replacing the local copy of the ontology inside the project with a new one. Clicking the downward pointing arrow to the right of each import brings up a menu with different update options for different sources (just like the different import options). The differently named option "Connect to project" allows the user to update the ontology with the content of another project.

An import that is already associated with a project can be updated from the source project or from another project. Alternatively, it can be disconnected from the project, making the general update options available.

When an import is updated, its owl:imports are compared to the previous ones:

• new imports are resolved according to the chosen resolution strategy,
• no longer imported ontologies are removed (unless kept alive by other ontologies),
• still imported ontologies are not updated in turn.

Ontology Mirror Management

After ontologies have been imported, if they have been also stored in the mirror, they will be listed in the Ontology Mirror Management panel (figure below) accessible by clicking on the Ontology mirror button in the heading of the Imports panel.

For each entry in the mirror, it is possible to delete the mirror file or update its content, with options analogous to those present in the Import menu.

Copyright © ART Group - Università degli Studi di Roma 'Tor Vergata'