Mobi Logo

Mobi is an open and collaborative knowledge graph platform for teams and communities to publish and discover data, data models, and analytics that are instantly consumable.

Introduction

Mobi is a free and open platform which links native data sources into a knowledge graph, creating an environment for teams and communities to accelerate discovery and deployment of advanced data systems. Mobi is built with Apache Karaf and utilizes OWL 2 for authoring ontologies, the SPARQL query language for data lookup, and a pluggable backend system for processing and handling graph data modeled using the Resource Description Framework (RDF). The Mobi platform applies the best practices recommended by the World Wide Web Consortium (W3C) to support organic growth of knowledge in a variety of domains.

Quick Start Guide

Installing from the Distribution

Prerequisites

Mobi requires a Java SE 8 environment to run. Refer to http://www.oracle.com/technetwork/java/javase/ for details on how to download and install Java SE 1.8.

Make sure your JAVA_HOME environment variable correctly points to your Java 8 installation directory. For example on a Mac, this would look like /Library/Java/JavaVirtualMachines/jdk1.8.0_221. On Windows, this would resemble C:\Program Files\Java\jdk1.8.0_221

Installation

Download the appropriate binary distribution for your system using our download site.

The Mobi distribution comes packaged as a .zip file for Windows and a tar.gz file for Linux/OSX. Extract this file to a new directory on your system. For example, in C:\Mobi - from now on this directory will be referenced as MOBI_HOME.

Open a command line console and change the directory to MOBI_HOME.

To start the Mobi server, run the following command in Windows:

> cd %MOBI_HOME%
> bin\start.bat

or for Linux/OSX:

$ cd $MOBI_HOME
$ ./bin/start

All Mobi prepackaged bundles, services, and required artifacts and dependencies will be automatically deployed by the runtime once started.

Tip
You can check the status of the running server using the bin/status script or access the Mobi shell using the bin/client script (that’s bin\status.bat and bin\client.bat for you Windows users). If you are having problems starting Mobi, check the log files in $MOBI_HOME\data\log.

The Mobi web application should now be accessible at https://localhost:8443/mobi/index.html. The default login credentials are admin:admin.

Installing the Docker Image

The easiest way to get started with Mobi on Docker is to download and install https://docs.docker.com/get-docker/. If you are using Mac or Windows Operating System, Docker Desktop will be available for use which provides a Dashboard GUI to manage docker images. If you are using a Linux operating system, you will interact with Docker via terminal commands.

Mobi is available as a preconfigured Docker image on Docker Hub: https://hub.docker.com/r/inovexis/mobi/. You can find the Mobi image by searching for our organization "inovexis" in the DockerHub search bar.

DockerHub Mobi Page
Figure 1. DockerHub Mobi Page

On this page you will see the docker pull command. Open up a terminal and execute the command to pull the Mobi Docker image.

~ % docker pull inovexis/mobi
Using default tag: latest
latest: Pulling from inovexis/mobi
6d827a3ef358: Pull complete
2726297beaf1: Pull complete
7d27bd3d7fec: Pull complete
e61641c845ed: Pull complete
cce4cca5b76b: Pull complete
6826227500b0: Pull complete
c03b117ffd91: Pull complete
821a1547b435: Pull complete
2bd47f6b1b42: Pull complete
e4cf3e9f705c: Pull complete
3733107c5c01: Pull complete
4a9bdb07bcd2: Pull complete
cb3da7c9fe66: Pull complete
Digest: sha256:f387dd12cc2235150a2dd03b2741f01baf872f771ea8fb7e61ebf8bd4acb2155
Status: Downloaded newer image for inovexis/mobi:latest
docker.io/inovexis/mobi:latest

To verify that the image was pulled correctly, you can run the command below to view all pulled images.

docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
inovexis/mobi       latest              6a5c8e447ec0        3 months ago        795MB

You can then run Mobi using the standard docker run command. We recommend running Mobi on port 8443 rather than the random default value.

% docker run -dp 8443:8443 inovexis/mobi
fb324e907ad8254e587e88e1014291850050ed8d6493463a8dabdd8ac9367430

Once you’ve created a container with the Mobi Docker image, you can go to Docker Dashboard to see image running.

Docker Dashboard
Figure 2. Docker Dashboard

You can also look in the terminal for the Mobi container running.

% docker container list
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
9abedac96a93        inovexis/mobi       "/usr/local/bin/mvn-…"   4 seconds ago       Up 2 seconds        0.0.0.0:8443->8443/tcp   flamboyant_panini

The Mobi image should now be running with the web application accessible at https://localhost:8443/mobi/index.html. The default login credentials are admin:admin.

You can use the CLI tool to login in karaf. Once you click on the CLI button, it will open up a terminal window where you can login into karaf.

DockerHub Mobi Page
Figure 3. Docker Dashboard CLI
user@machine ~ % docker exec -it fb324e907ad8254e587e88e1014291850050ed8d6493463a8dabdd8ac9367430 /bin/sh; exit
# ls -al # command to list directories
total 24
drwxr-xr-x 1 root root 4096 Jul 23 21:52 .
drwxr-xr-x 1 root root 4096 Jul 23 21:52 ..
drwxr-xr-x 1 root root 4096 Oct 29 15:43 mobi-distribution-1.17.78
# ./mobi-distribution-x.xx.xx/bin/client # command to login into karaf
Logging in as karaf




                       @@@@@
                      @#####@
                      @#####@
                     @@@@@@&
    &@%           @@@@@@@                       _     _
  @/,,,&@@@@@@@@@&   @@         _ __ ___   ___ | |__ (_)
  @,,,,,@@@@@@.     &@         | '_ ` _ \ / _ \| '_ \| |
  @,,,,/@      @@&  @@         | | | | | | (_) | |_) | |
    @*@           @@@@         |_| |_| |_|\___/|_.__/|_|
                   &@@
                    @@@
                    @&//@@
                   @//////@
                   @%////@@
                    @@@@@

  mobi (x.xx.xx).
  Powered by Apache Karaf

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown mobi.


karaf@mobi()>

To start or stop the container, you could either use the terminal or Docker Dashboard GUI.

docker container start {container id for mobi}
docker container stop {container id for mobi}

User Guide

The Mobi web application currently has six main modules:

The web application also has a My Account page to configure various settings and preferences of the logged in user and a Administration page for admin users to configure user accounts and groups. The Configuration for the Mobi software itself is set in configuration files. The Mobi Shell also provides several commands for accessing the application data. The home page of Mobi includes some quick action buttons for performing common tasks and a display of the latest key activities performed by users throughout the application. Each activity displays a summary about the action performed, who did it, and when it happened. The list is sorted with the latest activities first and is paginated so you can view earlier actions.

The home page of Mobi
Figure 4. The Home Page

Catalog

The Mobi web-based Catalog allows users to publish data, dataset descriptions, analytics and other resources. It allows users to control the way their data is shared.

Note
Federation of catalogs in Mobi is coming soon!

To reach the Catalog click on the link in the left menu.

full catalog initial view
Figure 5. The Catalog

The Local Catalog of Mobi contains all Records contained within your Mobi node. This includes all versioned ontologies created in the Ontology Editor, versioned mappings created in the Mapping Tool, and all datasets created in the Datasets Manager.

There are two main views of the Catalog:

Catalog Landing Page

catalog landing page
Figure 6. The Catalog Landing Page

The landing page of the Catalog displays a paginated list of all the Records in the Local Catalog that can be searched, sorted, and filtered. The filters on the left contain all possible types of Records and all possible user keywords. The search bar allows you to perform a text search through all the Record metadata.

Each Record in the list is displayed as a card with the Record title, type with related icon, date last modified, description, and keywords. Clicking on the title of the Record will copy its unique identifier (IRI). The footer of each Record card shows the username of its creator and a button to open that Record in its respective module (ontologies in the Ontology Editor, etc.). Clicking on the Record card will open it in the Record View.

Record View

record view
Figure 7. The Record View

The Record View displays all metadata for the selected Record along with set of tabs that updates based on the type of Record. The top of the Record view shows the Record title, type icon, and its description. The Record description is meant to provide a short summary of the Record. The right side of the view displays the created and modified dates of the Record along with its keywords and a button to open the Record in its associated module (ontologies in the Ontology Editor, etc.).

Every Record type will contain an Overview tab where you can view a Markdown description of the Record that provides more detailed information than the description field. If the Record is a Versioned RDF Record, such as an Ontology Record or Mapping Record, the tabset will also include a tab displaying the list of its Branches. The Branches in the list are expandable to view the description and commit history of the Branch.

If you have the permission to manage the Record, clicking on the title, description, overview, and keywords fields will turn them into editable fields for easy updates.

Ontology Editor

The Mobi web-based ontology editor provides a Distributed Ontology Management System (DOMS) for local and community development of Web Ontology Language (OWL) ontologies. The DOMS features a customizable user interface, knowledge capture, collaboration, access policy management, ontology reuse, and extensibility.

Note
The community distribution of ontologies in Mobi is coming soon!

To reach the ontology editor, click on the link in the left menu.

The Ontology Editor
Figure 8. The Ontology Editor

The initial view of the Ontology Editor shows the Ontologies page. The center of the page contains a paginated list of all ontologies in the local Mobi repository. Each ontology in the list displays ontology metadata and an action menu. The action menu allows you to delete the ontology and manage its permissions, (see the section on Ontology Managing). Deleting an ontology from this location will delete the ontology and associated ontology record and change history from the local catalog. Clicking an ontology will open it in the editor.

When opening an ontology, the editor will load the previous branch and commit you were viewing. If you have not previously opened the ontology or the branch you were viewing no longer exists, then the editor will load the HEAD commit of the ontology’s master branch. For an explanation of commits and branches see the section on Ontology Versioning.

From this screen you can also filter the ontology list, create new ontologies, or upload existing ones.

Creating New Ontologies

To create a new ontology, select the New Ontology button on the main ontology editor view. In the creation dialog, you are required to provide an ontology IRI and title. You can also optionally provide a description and keywords. This metadata is used to describe the ontology in the local catalog.

new ontology form
Figure 9. New Ontology Form

The Ontology IRI is the unique identifier for the new ontology. The editor pre-populates this field with a default namespace and a local name generated from the Title field. You can always override this behavior. The Title field populates the dcterms:title annotations of both the new ontology record and the ontology object within the new ontology. The Description field populates the dcterms:description annotations of both the new ontology record and the ontology object within the new ontology. The Keywords field will attach the entered values as keywords to the new ontology record.

Uploading Existing Ontologies

To upload an existing ontology, you can either click the Upload Ontology button and use the browser’s native file browser or drag and drop files onto the main ontologies view.

When uploading a file or files, a dialog box will prompt you for metadata entry for the ontology record (title, description, keywords). This metadata is used to describe the ontology in the local catalog. By default, the application will set the record title using the filename. Metadata for each ontology can be entered and submitted separately, or default metadata can be entered for all records using the Submit All button.

upload metadata form
Figure 10. Ontology upload metadata form.

Once all metadata has been submitted, a panel will be shown in the bottom right of the page which shows the status for each upload. Any errors will be detailed for each file. To refresh the main ontologies list with the new files, close the upload panel.

upload ontology results
Figure 11. Ontology upload results.

Supported ontology file types are .owl, .ttl, .xml, .jsonld, .owx, .trig, .json, .n3, .nq, .nt, .rdf, .txt, .json, .ofn, .omn , .owx, and .rdfs. The Title field populates the dcterms:title annotation of the new ontology record. The Description field populates the dcterms:description annotation of the new ontology record. The Keywords field will attach the entered values as keywords to the new ontology record. The file extension is used to guess the appropriate RDF Format to parse the file contents. If a parsing error occurs, the snackbar will display the error message relevant to guessed RDF Format.

Editing an Ontology

The Ontology Editor provides an interface for developing OWL 2 ontologies with additional features directed towards developing Simple Knowledge Organization System (SKOS) vocabularies and extensions thereof, including support for (SKOS-XL)

Tip
To learn more about OWL ontologies, see the W3C Specification. To learn more about SKOS vocabularies, see the W3C Specification

The Ontology Editor contains various tabs supporting activities for ontology development, search, and version control.

full editor ontology view
Figure 12. Ontology Editor

This section will describe the tools related to ontology development activities. These include:

The Schemes Tab and Concepts Tab will appear if the editor detects that the opened ontology contains SKOS classes and properties. The easiest way to have access to these tabs is to import the SKOS ontology (http://www.w3.org/2004/02/skos/core).

For a detailed description of the versioning components, refer to the Ontology Versioning section.

Ontology Project Tab

The Ontology Project Tab displays high-level information about the ontology. This includes the ontology annotations and properties, ontology imports, and a preview of the serialized ontology RDF.

ontology editor tab project
Figure 13. Ontology Editor Project Tab

The top of this tab contains the title of the ontology and its IRI. The IRI shown is the Version IRI, Ontology IRI, or a blank node identifier. The IRI can be copied quickly by clicking on it.

On the upper left side of this tab is a section containing a list of all the applied OWL Ontology Properties and Annotations. There are controls included to add, remove, and edit these properties.

On the lower left side of this tab is a section containing a list of all direct and indirect ontology imports. If an imported ontology could not be resolved, it will appear red. To add a new imported ontology, click on the plus button and either enter the IRI of an ontology available on the web or select an ontology within Mobi. To refresh the cached versions of the imported ontologies and attempt to resolve any unresolved imports, click on the refresh button.

On the right of this tab is a card used to generate a preview of the ontology as RDF. There is a drop down with several different RDF serializations to choose from. Clicking Refresh will generate a preview of the saved state of the ontology in the specified RDF format in the area below. The preview will be limited to the first 5000 results. Additionally, there is a button for downloading the ontology in the selected format.

Tip
The serialized ontology is a representation of data stored in the repository and will not include unsaved changes.
Overview Tab

The Overview Tab provides quick access to classes and their associated properties as compared to the Classes and Properties tabs. Properties are associated to classes through the use of rdfs:domain.

ontology editor tab overview
Figure 14. Ontology Editor Overview Tab

The left side of this tab contains the list of all classes and their associated properties, including imports. Any properties that have no rdfs:domain are grouped into a folder in the hierarchy called "Properties". You can expand a class to view its properties by clicking the "+" icon or double-clicking the class name. Properties are displayed with a symbol representing the data type of the range property. If an entity has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of the entity name. Imported classes and properties will appear grey and italicized. The list also includes a search bar that will filter the list to classes/properties with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported entities from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all entities annotated with the owl:deprecated property. Clicking on an item in the tree will load that entity’s information into the other sections in this tab.

The title of the selected class or property, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the entity and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The middle sections in this tab allow you to add, remove, and edit Annotations and Axioms for the selected class or property. Imported classes and properties cannot be edited.

If you selected a property, a section with checkboxes for adding different characteristics to the selected property is shown in the top right of the Overview Tab.

Tip
See the W3C Specification for the definitions of property characteristics.

The last section on the right displays all the locations where the selected entity is used within the saved state of the ontology. For classes, this is anywhere the selected class is used as the object of a statement. For properties, this is anywhere the selected property is used as the predicate or object of a statement. Usages are grouped by the predicate of the statement and can be collapsed by clicking on the predicate title. Links in the usages section, as with links in various other components of the editor, can be clicked to navigate to that entity. If the number of usages exceeds 100, a button to load the next 100 is shown at the bottom of the section.

Classes Tab

The Classes Tab allows you to view, create, and delete classes in the opened ontology.

ontology editor tab classes
Figure 15. Ontology Editor Classes Tab

The left side of the tab contains a hierarchical view of the classes, including imports, nested according to their rdfs:subClassOf property. That is, a class’s children are classes which are defined as subclasses of the particular class. Since classes can be defined as a subclass of multiple classes, they may appear several times within the hierarchy. If a class has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of the class name. Imported classes will appear grey and italicized. The list also includes a search bar that will filter the list to classes with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported classes from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all classes annotated with the owl:deprecated property. Clicking on an item in the hierarchy will load that class’s information into the other sections in this tab. Double clicking on a class with children will toggle the display of the children.

The title of the selected class, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the class and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The middle sections in this tab allow you to add, remove, and edit Annotations and Axioms for the selected class. Imported classes cannot be edited.

The section on the right of the Classes Tab displays all the locations where the selected class is used within the saved state of the ontology. That is, anywhere the selected class is used as the object of a statement. Usages are grouped by the predicate of the statement and can be collapsed by clicking on the predicate title. Links in the usages section, as with links in various other components of the editor, can be clicked to navigate to that entity. If the number of usages exceeds 100, a button to load the next 100 is shown at the bottom of the section.

Properties Tab

The Properties Tab allows you to view, create, and delete properties in the opened ontology.

ontology editor tab properties
Figure 16. Ontology Editor Properties Tab

The left side of the tab contains a hierarchical view of the data, object, and annotation properties, including imports. The data, object, and annotation properties are grouped into three separate folders within the hierarchy that will open and close when clicked. Properties are nested according to their rdfs:subPropertyOf property. That is, a property’s children are properties which are defined as subproperties of the particular property. Properties are displayed with a symbol representing the data type of the range property. If a property has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of the property name. Imported properties will appear grey and italicized. The list also includes a search bar that will filter the list to properties with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported properties from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all properties annotated with the owl:deprecated property. Clicking on an item in the hierarchy will load that property’s information into the other sections in this tab. Double clicking on a property with children will toggle the display of the children.

The title of the selected property, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the property and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The middle sections in this tab change depending on whether you have selected a data, object, or annotation property. If the selected property is a data or object property, the sections for adding, removing, and editing Annotations and Axioms are shown. If the selected property is an annotation property, only the Annotation sections is shown. Imported properties cannot be edited.

If the selected property is a data or object property, a block with checkboxes for adding different characteristics to the selected property is shown in the top right of the Properties Tab. Imported properties cannot be edited.

object property tab
Figure 17. Object Property View
Tip
See the W3C Specification for the definitions of property characteristics.

The last section on the right of the tab displays all the locations where the selected property is used within the saved state of the ontology. That is, anywhere the selected property is used as the predicate or object of a statement. Usages are grouped by the predicate of the statement and can be collapsed by clicking on the predicate title. Links in the usages section, as with links in various other components of the editor, can be clicked to navigate to that entity. If the number of usages exceeds 100, a button to load the next 100 is shown at the bottom of the section.

Individuals Tab

The Individuals Tab allows you to view, edit, create, and delete individuals in the opened ontology.

ontology editor tab individuals
Figure 18. Ontology Editor Individuals Tab

The left side of the tab contains a view of all individuals, including imports, nested under their classes based on the rdfs:subClassOf property. If an individual has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of the individual name. Imported individuals will appear grey and italicized. The list also includes a search bar that will filter the list to individuals with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported individuals from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all individual annotated with the owl:deprecated property. Clicking on an item in the list will load that individual’s information into the other sections in this tab.

The title of the selected individual, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the individual and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The section to the center and right of the tab allow you to add, remove, and edit Data, Object, and Annotation Properties for the selected individual. The options for Data and Object Properties are populated from the ontology and its imports. Imported individuals cannot be edited.

The types of an individual are editable by clicking the pencil icon at the end of the types list. The overlay allows you to add and remove types from the ontology and its imports. The "Named Individual" type is required.

edit individual types
Figure 19. Edit Individual Types Overlay
Schemes Tab

The Schemes Tab will appear if the editor detects the opened ontology is a SKOS vocabulary. It displays information about all the concept schemes and their directly related concepts defined in the opened vocabulary.

ontology editor tab schemes
Figure 20. Ontology Editor Schemes Tab

The left side of the tab contains a hierarchical view of the concept schemes, including imports. The top level items are the concept schemes, or subclasses of skos:ConceptScheme, and their children are all concepts, or subclasses of skos:Concept, within that scheme. This could be defined through the skos:hasTopConcept, skos:topConceptOf, or skos:inScheme properties. If a concept scheme or concept has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of its name. Imported concept schemes and concepts will appear grey and italicized. The list also includes a search bar that will filter the list to concepts/schemes with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported schemes from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all schemes annotated with the owl:deprecated property. Clicking on an item in the hierarchy will load that concept scheme’s or concept’s information in the other sections in this tab. Double clicking on a concept scheme with children will toggle the display of the children.

The title of the selected concept scheme or concept, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the entity and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The middle sections in this tab allow you to add, remove, and edit Annotations, Data Properties, and Object Properties for the selected concept scheme or concept. Imported concept schemes and concepts cannot be edited.

The third section on the right of the Schemes Tab displays all the locations where the selected concept scheme or concept is used within the saved state of the vocabulary. This is anywhere the selected concept scheme or concept is used as the object of a statement. Usages are grouped by the predicate of the statement and can be collapsed by clicking on the predicate title. Links in the usages section, as with links in various other components of the editor, can be clicked to navigate to that entity. If the number of usages exceeds 100, a button to load the next 100 is shown at the bottom of the section.

Concepts Tab

The Concepts Tab will appear if the editor detects the opened ontology is a SKOS vocabulary. The Concepts Tab displays information about all the concepts defined in the opened vocabulary.

ontology editor tab concepts
Figure 21. Ontology Editor Concepts Tab

The left side of the tab contains a hierarchical view of the concepts, including imports. The concept hierarchy is determined using all of the SKOS broader and narrower properties. If a concept scheme or concept has been changed and those changes have not been committed, it will appear bold and an indicator will be shown on the right of its name. Imported concepts will appear grey and italicized. The list also includes a search bar that will filter the list to concepts with annotations or local names containing your search query and the ability to apply one or more filters. The Hide unused imports filter will remove all imported concepts from the list that are not used by any of the entities defined in the ontology. The Hide deprecated entities filter will remove all concepts annotated with the owl:deprecated property. Clicking on an item in the hierarchy will load that concept’s information in the other sections in this tab. Double clicking on a concept with children will toggle the display of the children.

The title of the selected concept, its IRI, and its type(s) are displayed at the top of the tab along with buttons to delete the concept and view its change history (see Entity History). The IRI can be copied quickly by clicking on it. The middle blocks in this tab allow you to add, remove, and edit Annotations, Data Properties, and Object Properties for the selected concept. Imported concepts cannot be edited.

The third section on the right of the Concepts Tab displays all the locations where the selected concept is used within the saved state of the vocabulary. This is anywhere the selected concept is used as the object of a statement. Usages are grouped by the predicate of the statement and can be collapsed by clicking on the predicate title. Links in the usages section, as with links in various other components of the editor, can be clicked to navigate to that entity. If the number of usages exceeds 100, a button to load the next 100 is shown at the bottom of the section.

Search Tab

The Search Tab allows you to perform a keyword search through all the entities within the saved state of the opened ontology and its imports.

ontology editor tab search
Figure 22. Ontology Editor Search Tab

The left side of the tab contains a simple search bar and a list of search results. To perform a search, type a string into the search bar and press the ENTER key. The results are separated by type headers which are collapsible. Each result is displayed with its display name. Properties are displayed with a symbol representing the data type of the range property. Clicking on a result will load that entity’s information into the right section of this tab. The right section displays the entity’s display name, IRI, types, and properties. The parts of the property values that match the search text will be highlighted. The right section also includes a Go To button that will open the entity in the appropriate tab. Double clicking on an entity in the list will also open that entity in the appropriate tab.

Ontology Managing

The Ontology Editor provides functionality to allow you to specify which users and groups can perform various actions against ontologies. When a user uploads or creates an ontology, the default settings are that any authenticated user can view and create and edit branches, but only the publisher of the record can manage the ontology permissions, delete the ontology, and edit the MASTER branch.

ontology permissions
Figure 23. Ontology Permissions

To view the current permissions and edit them, select the Manage action in the ontology’s action menu in the main page. Then to view and edit the current setting for a permission, click on the icon on the right.

edit ontology permissions
Figure 24. Editing an Ontology Permission

The overlay for viewing/editing a specific permission on an ontology allows you to specify a list of users and groups to restrict the action to. Alternatively, you can set the permission to "Everyone" which means any authenticated user can perform that action against the ontology.

If a user is not allowed to modify the branch they are currently viewing, all actions in the editor that would affect the branch are disabled or removed. In addition, if a user is not allowed to edit the target branch of a merge request, they will not be able to accept the request.

Ontology Versioning

Each ontology in Mobi is versioned in a manner similar to the Git Version Control System, whereby all changes to an ontology are collected into a chain "commits" which form a commit history called a "branch". Thus, every version in the history of an ontology can be generated by selecting a commit and applying all the changes in the branch back to the initial commit.

Every ontology is initialized with a MASTER branch that contains the initial commit. Work can be done on this MASTER branch or can be split out into separate branches. Work done on these branches occur in isolation until they are merged back into the MASTER branch, joining any other changes committed in the meantime. When merging two branches, the ontology editor does its best to combine any changes made on both branches. If a conflict occurs, the editor allows the user to resolve them manually. More information on merging branches can be found in the section on Merging Branches.

Checking Out Branches/Tags/Commits

The check out select box located underneath the selected ontology in the left display, provides a list of all the available branches and tags on the ontology. To checkout a branch or tag, simply select the branch in the drop-down menu. Checking out a tag will open the ontology at the tagged commit in read-only mode. If you have checked out a commit from the Commits Tab, the commit will be in the dropdown list and show as selected. Note that the select box will be disabled if you have any uncommitted changes on the current branch. To edit a branch name or description, click on the edit icon next to the branch in the drop-down menu. You cannot edit the master branch of an ontology.

check out select

check out select commit

check out tag
Figure 25. Ontology checked out at a tag

To delete a branch or tag, click on the delete icon next to the branch/tag in the drop-down menu. If a branch is deleted, all commits on that branch that are not part of another branch will be removed, as well as the branch itself. If a tag is deleted, the commit is not removed. Note that these actions cannot be undone.

Viewing Saved Changes

Every edit made to an entity within an ontology is automatically saved and an indicator is shown in the top right if the most recent changes have been saved successfully. The Changes Tab displays all saved and uncommitted changes in the opened ontology. Saving changes without committing allows a user to edit an ontology through a number of browser sessions before making any commits to the commit history. These changes are unique to the user, and are available to other users once a commit is performed.

ontology editor tab changes
Figure 26. Ontology Editor Changes Tab

Within each collapsible block in the list are the added and deleted triples for a particular entity IRI. If there are no changes to the ontology, this page will be empty. To commit these changes, select the Commit Changes button in the Button Stack. To remove these changes, click Remove All Changes.

If new commits have been made to the branch by other users while you are editing or viewing an ontology, a warning symbol will be displayed in the section title and a message will be displayed in the section notifying you that there are new commits on the branch. If you have no saved changes, there will be a link to update the current ontology by pulling in the latest changes. If you have saved changes, there will be a message notifying you to either commit your changes or remove them. If you choose to commit your changes, you can still continue working and there will be a link to pull in the latest changes and re-sync with the branch.

pull latest changes
Figure 27. Pull in latest changes message
behind head
Figure 28. Behind the head with saved changes
Merging Branches

The Ontology Editor also supports merging the head commit of the branch you are currently viewing into the head commit of another branch. Two branches can only be merged if there are no conflicts between the head commits of each branch. To perform a merge, select the green Merge Branches button in the button stack.

The merge view displays the name of the current (source) branch, a select box for the branch (target) you want to merge into, and a checkbox for whether or not you want the source branch to be deleted after it is merged. The view also shows an aggregated view of all changes made in the source branch that will be merged into the target branch along with a list of all the commits that will be added to the target branch from the source branch.

merge view
Figure 29. Merge branches view

Clicking Submit will attempt to perform the merge. If there are no conflicts between the changes on both branches, a new commit will be created merging the two branches, and a success message will appear in the top right corner of the screen.

Conflicts arise when the application cannot determine how to automatically merge specific changes to entities between two branches. If conflicts exist between the two branches, the merge process will be halted and the screen will update to notify you of those conflicts and provide you a way to resolve them. Each conflict is listed by entity within the ontology and with a marker indicating whether or not it has been resolved. Click on a conflict in the list to start resolving them.

merge conflicts main
Figure 30. List of all merge conflicts

When resolving a conflict, the tool displays the changes to the entity from both branches. To resolve the conflict, select the version of the entity you wish to keep. You can either click the Back to List button to go back to the list of all the conflicts or the Previous or Next buttons to iterate through the list of conflicts.

Note
Currently the editor only supports accepting entire changes. We are working on improvements to give more flexibility in resolving conflicts during a merge operation.
merge conflicts resolution
Figure 31. Merge conflict resolution view.

Once all conflicts have been resolved, the Submit with Resolutions button will become active and you can complete the merge operation. Completing the merge will create a new commit that incorporates your conflict resolutions into the target branch, and displays a success message in the upper right corner of the screen.

Commits Tab

The Commits Tab provides a table and graph of all the commits made in the history of the branch you are currently viewing. The username of the creator, ID, message, and date for each commit are displayed within the table. The graph displays each commit connected to its parent commits continuing backwards until the initial commit. To view more information about a particular commit in the history, such as the added and deleted statements, click on its id or associated circle in the graph. The table also includes buttons for "checking out" a commit in the history. Clicking a View button will open the ontology at that commit in read-only mode. This is useful for creating tags to indicate versions on the ontology (see Button Stack and Checking Out Branches/Tags/Commits).

commit history table
Figure 32. Commit history table of a branch
Entity History

Clicking on a See History button next to a selected entity in one of the tabs will open a view containing the change history of that specific entity in the ontology. The view is split into two columns. The left side contains a dropdown containing all the commits where that entity was changed and defaults to the latest commit. Any added triples will be green and any deleted triples will be red. The right side contains a table of all the commits where that entity was changed. The table behaves the same as the table in the Commits Tab, just without the graph. To return to the main editor, click the back button in the top left.

entity history
Figure 33. Entity History view
Visualization Tab (BETA)

The visualization tab depicts the ontology in a force-directed graph layout. Each node represents a class, with dotted lines symbolizing the relationship between parent class and subclass, and solid lines representing the object properties.

pizza graph
Figure 34. Pizza Ontology Graph

The Ontology Visualization feature enables users to easily understand data within an Ontology by allowing them to navigate across the classes and their relationships. The feature allows users to zoom, pan, select, drag, hover, and click nodes and links.

The number of classes displayed is currently limited to 500. InProgressCommits are not currently not rendered in the beta version of this feature. After initial graph calculation, the state of the graph will persist while users keep the Ontology open. The graph will only be re-rendered when there is a new commit.

pizza graph commitInProgress
Figure 35. Uncommited changes state
node limit
Figure 36. Over the limit state
Imported Ontologies

The rendered graph will include every Ontology within the imports closure. The classes in the graph are rendered with different colors based on what Ontology within the imports closure they belong to. If a change to an imported Ontology is made, the changes will not be rendered until a manual refresh is triggered which will reset the Ontology cache or until a new commit is made.

imported ontology
Figure 37. Imported Ontologies
update imports
Figure 38. Refresh import

Ontology Editor Reference

Edit IRI Overlay

The Edit IRI overlay provides the user with a simple way to edit and create valid IRIs. The Begins with field (required) is the beginning of the IRI. This is more commonly known as the namespace. When editing the IRI of entities within an ontology, this value is typically the ontology IRI. The Then field (required) is the next character in the IRI. This value can be thought of the separator between the namespace and local name (described below). The provided values for the Then field are "#", "/", and ":". The Ends with field (required) is the last part of the IRI. This value is commonly known as the local name. It is used in the drop down lists in this application as the easiest way to identify what the IRI references. Clicking the refresh button on the left will reset the three fields to their original values. You cannot create/save an edited IRI that already exists within the ontology. Clicking Cancel will close the overlay. Clicking Submit will save the IRI with the entered values for the selected entity and update the ontology.

edit iri overlay
Figure 39. Edit IRI overlay
Axiom Overlay

The Axiom Overlay is how you add new axioms to entities in your ontology. The Axiom dropdown provides a list of common axioms for the type of entity you have selected. Once selected, there are two ways to add a value. The first is choosing from a list of entities within the ontology and its imports. The second is writing out a class expression or restriction in Manchester Syntax in the Editor. Entities are referenced by their local name and must be present in the ontology or its imports.

axiom value editor
Figure 40. Axiom Overlay Editor with an example
Property Value Displays

Property Value Displays are a common way Mobi displays multiple values for a property on an entity. These properties could be data properties, object properties, annotations, axioms, etc. The display consists of the title section and the values section. The title section includes a bold title and the property IRI. The values section lists all the values set for the displayed property along with the type, if the value is a literal, and edit and delete buttons when you hover over the value. The functionality of the edit and delete buttons for values differ depending on where the Property Value Display is being used. If a value of a property is a class restriction or expression, it will be represented in a simplified format or Manchester Syntax if it is supported. These values can be deleted, but not edited.

Tip
See the W3C Specification for information about blank nodes, class/property restrictions, and class/property expressions.
property value display
Figure 41. A property value display with multiple values
Button Stack

The Button Stack is visible in any Ontology tab in the bottom right hand corner of the screen and holds a variety of buttons that are shown when the stack is hovered over.

button stack
Figure 42. Collapsed button stack

To add a new entity to the ontology, click on the main Create Entity button in the stack. This will open an overlay with options for what kind of entity to create and once you have selected an option, an appropriate overlay will be shown for creating that type of entity. After creating the entity, a snackbar will appear at the bottom allowing you to navigate directly to your new entity.

create entity button
Figure 43. Create Entity button
new snackbar
Figure 44. New Entity snackbar

If you have made changes to an ontology, the Commit Changes button will become active. Clicking on this button will bring up the Add Commit overlay.

commit changes button
Figure 45. Commit button

The Add Commit overlay provides a textarea for you to enter in a Comment that will be associated with that commit. This commit usually specifies what changes where made in the commit so that others can read the message and understand what happened at that point in time. You can still commit your changes if you are not currently viewing the head commit of the current branch. Clicking Cancel will close the overlay. Clicking Submit will add all your saved changes to a new commit object whose parent is the commit you were viewing and close the overlay.

add commit overlay
Figure 46. Add commit overlay

See the Merging Branches section for details on how the merging branches works.

merge branch button
Figure 47. Merge Branch button

The Create Branch button allows you to create a new branch from the commit and branch you are viewing, including past commits. This action can be performed even if you have unsaved or saved changes. Clicking on the button will bring up the Create New Branch overlay.

create branch button
Figure 48. Create Branch button

The Create New Branch overlay provides fields for entering information about the branch as a whole. The Title field (required) will set the dcterms:title of the branch. The Description field will set the dcterms:description of the branch. Clicking Cancel will close the overlay. Clicking Submit will create a new branch with the entered information whose head commit was the commit you were viewing and close the overlay.

create branch overlay
Figure 49. Create new branch overlay

The Create Tag button allows you to create a human readable and persistent pointer to the commit you are currently viewing. Clicking this button will bring up an overlay where you can type in the title for the Tag and customize it’s IRI. Once the Tag is created, the ontology will open the ontology in read-only mode at the tagged commit.

create tag button
Figure 50. Create Tag button

The Upload Changes button allows you to upload a new version of your ontology from a file and apply the changes. Clicking this button will bring up an overlay where you can select the file with the changed ontology. Uploaded changes will not be automatically committed, but will allow you to review changes before making a new Commit.

upload changes button
Figure 51. Upload Changes button
Extension Mappings

The table below describes which file extensions are mapped to which RDF Formats when an ontology file is uploaded to Mobi. In the event more than one RDF Format is possible for a single extension, all RDF Formats are attempted.

Table 1. Table Extension to RDF Formats
Extension RDF Format Name

.json

RDF/JSON, JSON-LD

.jsonld

JSON-LD

.ttl

Turtle

.xml

Rio OWL XML, RDF/XML

.ofn

Rio Functional Syntax

.omn

Rio Manchester Syntax

.owx

Rio OWL XML

.rdf

RDF/XML

.rdfs

RDF/XML

.owl

RDF/XML, Rio OWL XML

.trig

TriG

.nt

N-Triples

.nq

N-Quads

.obo

Open Biological and Biomedical Ontologies

Merge Requests

The Mobi Merge Requests module allows users to create long lived representations of a merge between two branches of a record to provide checks and balances before including changes into the object the record represents. Each merge request is connected to a particular Record in the local Catalog and specifies a "source" and "target" branch. The request represents what would occur if the "source" branch were merged into the "target" branch.

To reach the Merge Requests module, click on the link in the left menu.

full merge requests initial view
Figure 52. The Merge Requests module

The initial view of the Merge Requests module displays a list of all currently open merge requests within the application sorted by created date descending along with a button to create a merge request. To view all accepted merge requests, change the selected filter next to the search bar. Each merge request in the list displays a preview of the request metadata and a button to delete the request. Clicking on a merge request in the list opens a display of the individual merge request.

individual request
Figure 53. An Individual Merge Request

The individual merge request view displays all information regarding the merge request. The top displays more metadata about the request including the request’s description and whether the source branch will be removed once the request is accepted. Below the metadata are a series of tabs containing the discussion on the request, the changes between the source and target branch, and commits that will be added from the source to the target branch. The bottom of the view contains a button to delete the request, a button to accept the request if it not already accepted, and a button to go back to the main list of merge requests.

The discussion tab allows users to comment and discuss the changes within the request to facilitates more collaboration in a distributed environment. You can create new comments to start new threads of communication or you can reply to existing comments and further the discussion. Comments can only be removed by the creators of the comment.

Note
The comment editor supports GitHub flavored Markdown which you can find more information about here.

The metadata of a request can be edited by hovering over the area and clicking the pencil button. In the resulting overlay, you can change the Title, Description, target branch, Assignees, and whether the source branch should be removed on acceptance.

edit merge request
Figure 54. Editing Merge Request Metadata

Create a Merge Request

To create a merge request, click Create Request on the initial view of the Merge Requests module. Creating a merge request is a three part process. The first step is to select which record in Mobi that request should be attached to by searching within the displayed paginated list of records. Once you have selected a record, click Next.

Important
If the record a request is attached to is deleted, that request is removed. If the source branch of a request is removed, that request will also be removed.
step1
Figure 55. Creating a Merge Request: Step 1 - Select a Record

The second step of creating a merge request is to pick the "source" and "target" branch from the attached record. The source branch will be the branch in the first select box and the target branch will be in the second select box. Once both are selected, you will see an aggregated view of all changes made in the source branch that will be merged into the target branch along with all the commits from the source branch that will be included in the target branch. Once you have selected the branches you want to merge, click Next.

step2
Figure 56. Creating a Merge Request: Step 2 - Select Branches

The third step of creating a merge request is to provide any metadata you want to include about the request. This includes the required Title, optional Description, any Assignees of the request, and whether the source branch should be removed when the request is accepted. Once you have provided the metadata you wish to include, click Submit and a new Merge Request with your selections will be created.

step3
Figure 57. Creating a Merge Request: Step 3 - Request Metadata

Accepting a Merge Request

A merge request can be accepted only if there are no conflicts between the source and target branch and the user accepting the request has permission to modify the target (see Ontology Managing). If there are conflicts between the source and target branches, a notification will be shown with the option to resolve the conflicts from within the Merge Requests module. Resolving conflicts behaves the same as in the Ontology Editor, except that the resolution will become a commit on the source branch.

conflicts
Figure 58. Conflicts on a Merge Request

If a merge request is accepted, the merge will be preformed from the source into the target and the request will be moved into an Accepted state. All accepted merge requests are saved within the application for provenance.

Mapping Tool

The Mobi web-based Mapping Tool allows users to define custom, ontology-driven definitions to control and execute input data transformations to the Resource Description Framework (RDF) semantic data model. User-defined mappings load semantic data into the Mobi store for analysis, sharing and linking.

To reach the Mapping Tool, click on the link in the left menu.

full mapping tool initial view
Figure 59. Mapping Tool button

To use the Mapping Tool to map data, an ontology must be in the Mobi repository, but it does not have to be opened to access it. If there are no available ontologies, you will not be able to map delimited data. To upload an ontology go to the Ontology Editor and follow the steps for uploading ontologies or creating a new ontology.

The initial view of the Mapping Tool shows the Mapping Select Page. The left side displays a searchable list of all the mappings within the local Mobi repository along with buttons to create and delete mappings. Clicking on a mapping in this list loads its information into the right side of the page. The preview of the mapping includes its description, the classes and properties it maps, and the title of the source ontology along with a dropdown menu with options for editing, running, duplicating, and downloading the mapping. If the selected source ontology no longer exists in the local Mobi repository, you will not be able to edit, run, or duplicate the mapping.

Creating a Mapping

To create a new mapping, click Create Mapping on the Mapping Select Page. The creation overlay requires you to enter a Title which will populate the dcterms:title annotation of the new mapping record. The Description field populates the dcterms:description annotation of the new mapping record. The Keywords field will attach the entered values as keywords to the new mapping record.

create mapping overlay
Figure 60. Create Mapping Overlay

Clicking Submit brings you to the File Upload Page to continue the process of creating a mapping. You must upload a delimited file to use as a standard for the mapping. You can also check whether or not the file contains a header row and select the separator character if the file is CSV. The accepted file formats are .csv, .tsv, .xls, and .xlsx. Selecting a file in the form on the left loads a preview of the first 50 rows and columns of the delimited file into the table on the right. Clicking Continue brings you to the Edit Mapping Page.

file upload create
Figure 61. File Upload Page for Creating a Mapping

The Edit Mapping Page contains two tabs, Edit and Preview. The Edit tab contains a section for displaying the currently selected source ontology, the list of class mappings, and a list of property mappings for a particular class. For every row in the delimited data, an instance of a mapped class will be made according to each class mapping. Each created class instance will have a set of properties as defined by the property mappings associated with each class mapping. The values of data properties will have assigned datatypes based on the range of the mapped data property unless otherwise specified. The Preview tab allows you to map the first 10 rows of the selected delimited file using the current state of the mapping in a variety of different RDF serializations.

Tip
To learn about the structure of a mapping, refer to the Mobi Mappings Appendix.
edit mapping edit
Figure 62. Edit Mapping Page Edit Tab

When creating a mapping, the first thing you will see is the Source Ontology Overlay. This setting can always be changed by clicking the pencil button next to the ontology name in the Edit form. The Class section contains a select box with all the class mappings, a button to delete a specific class mapping, and a button to create a new class mapping. Clicking Add Class opens an overlay where you can select a class in the imports closure of the source ontology that has not been deprecated.

The IRI Template section displays the template Mobi will use when generating IRIs for the created class instances from the selected class mapping. The value within the ${} indicates what will be used for the local name of each class instance’s IRI. "UUID" means that a unique identifier will be generated for each class instance. An integer means that Mobi will grab the value from the column with that index (zero-based) for each row and use each value with all white space removed as the local name for the class instance. This template can be edited by clicking the pencil button next to the section title and filling in the fields in the IRI Template Overlay.

The Properties section lists all the property mappings for the selected class mapping with a button to add a new property mapping. Object property mappings are displayed with the name of the class mapping whose instances will be used as the range of the property. Data or Annotation property mappings are displayed with the name of the column whose values will be used as the range of the property, a preview of what the first value would be, the datatype for the mapped value, and the language for the values if specified. Each property mapping also provides a button to edit and delete. If a data property mapping is invalid, meaning it points to a column that does not exist in the delimited file, it must be handled before the mapping can be saved or run.

Clicking Add Property opens an overlay where you can select a property in the imports closure of the source ontology that has not been deprecated or a common annotation. The common annotations that can be mapped are rdfs:label, rdfs:comment, dcterms:title, and dcterms:description. If you select a data property or an annotation, a select box appears containing identifiers for each column in the delimited file along with a preview of the first value of the selected column. At this point, you can also specify a manual datatype override which the mapper will use over the range of the property if set. You can also specify the language for the property values by selecting rdfs:langString as the type and then a language select will appear underneath. If you select an object property, a select box appears containing the titles of all class mappings of the appropriate type along with an option to create a new class mapping.

create property mapping overlay data
Figure 63. Create Property Mapping Overlay for a Data/Annotation Property
create property mapping overlay object
Figure 64. Create Property Mapping Overlay for an Object Property
language selection
Figure 65. Language Selection for a Data/Annotation Property

Clicking the main Save button at the bottom of either the Edit or Preview tab saves the current state of the mapping and brings you back to the Mapping Select Page. Clicking on the arrow to the right of the Save button provides you options for running the mapping in addition to saving it. These options are downloading the mapped data, uploading the mapped data into a data within a Mobi repository, or committing the mapped data to a specific branch of an ontology. Each option will bring up an appropriate overlay for choosing a RDF format and file name, a dataset, or an ontology and branch respectively. Clicking Submit in an overlay will save the current state of the mapping and run it.

Tip
To learn about datasets in Mobi, refer to the Datasets Manager.
Note
For more information about running a mapping into an ontology, refer to Mapping into an Ontology.
save run options
Figure 66. Options for saving and running a mapping

Editing a Mapping

To edit a mapping, click Edit on the Mapping Select Page. The application performs a quick check to see if the source ontology or its imported ontologies changed in such a way that the mapping is no longer valid. If this check does not pass, an overlay is displayed informing you of the error. If it passes, you are brought to the File Upload Page where you must upload a delimited file to use as a standard for the mapping. If the delimited file you choose does not contain enough columns for the mapping’s data property mappings, a list of the missing columns are displayed under the file select. However, you can still edit the mapping as long as those data properties are fixed. From there, editing the mapping works the same as creating a mapping.

file upload edit
Figure 67. File Upload Page for Editing a Mapping
file upload edit missing columns
Figure 68. File Upload Page for Editing a Mapping with missing columns

Duplicating a Mapping

To duplicate a mapping, click Duplicate on the Mapping Select Page. The application performs a quick check to see if the source ontology or its imported ontologies changed in such a way that the mapping is no longer valid. If this check does not pass, an overlay is displayed informing you of the error. If it passes, the Create Mapping overlay will appear allowing you to choose new values for the Title, Description, and Keywords. The rest of the process is the same as editing a mapping including how missing columns are handled.

Running a Mapping

To run a mapping against delimited data without editing it, click Run on the Mapping Select Page. The application performs a quick check to see if the source ontology or its imported ontologies changed in such a way that the mapping is no longer valid. If this check does not pass, an overlay is displayed informing you of the error. If it passes, you are brought to the File Upload Page where you must upload a delimited file to be used when generating RDF data. You can also check whether or not the file contains a header row and select the separator character if the file is CSV. The accepted file formats are .csv, .tsv, .xls, and .xlsx. The classes and properties that will be created using the mapping are displayed under the file select. The columns that must be present in the delimited file are highlighted in the table on the right. Selecting a file in the form on the left loads a preview of the first 50 rows and columns of the delimited file into the table. If the delimited file you choose does not contain enough columns for the mapping’s data property mappings, the properties that are missing columns turn red and you will not be able to run the mapping.

Tip
To learn about datasets in Mobi, refer to the Datasets Manager.
file upload run
Figure 69. File Upload Page for Running a Mapping
file upload run missing columns
Figure 70. File Upload Page for Running a Mapping with missing columns

Clicking Run Mapping will provide you with options for downloading the mapped data, uploading the mapped data into a data within a Mobi repository, or committing the mapped data to a specific branch of an ontology. Each option will bring up an appropriate overlay for choosing a RDF format and file name, a dataset, or an ontology and branch respectively.

Note
For more information about running a mapping into an ontology, refer to Mapping into an Ontology.
run options
Figure 71. Options for saving and running a mapping

Mapping Tool Reference

Source Ontology Overlay

The Source Ontology Overlay allows you to select the source ontology for the mapping from all uploaded ontologies in the local Mobi repository.

source ontology overlay
Figure 72. Source Ontology Overlay

The left side of the overlay contains a searchable list of all the ontologies in the local Mobi repository and a select for the version of the ontology to use. For most ontologies, this will only contain the "Latest" value. However, if an ontology was previously selected for a mapping and that ontology has changed since then, there will be an option for the "Saved" version of the ontology. The right side of the overlay displays information about the ontology from its record in the Catalog and a sample of the classes in that ontology. Setting the source ontology will remove any class and property mappings in the mapping that are incompatible. Class mappings and property mappings are incompatible if the class or property that is referenced no longer exists in the imports closure of the source ontology. Property mappings are also incompatible if they are a different type or have a different range.

IRI Template Overlay

The IRI Template overlay provides you a way to edit each portion of the IRI template of a class mapping. The template will be used to generate the IRIs for each instance created by a class mapping.

iri template overlay

The Begins with field (required) is the beginning of the IRI. This is more commonly known as the namespace. The Then field (required) is the next character in the IRI. This value can be thought of the separator between the namespace and local name (described below). The provided values for the Then field are "#", "/", and ":". The Ends with dropdown field (required) is the last part of the IRI. This value is commonly known as the local name. The values in this dropdown are "UUID", which represents generating a unique identifier as the local name for each generated instance of each row, and the title of each column, which represents using the value of that column as the local name for each generated instance of each row. Clicking Cancel will close the overlay. Clicking Submit will save the IRI template.

Mapping into an Ontology

The overlay for mapping into an ontology contains several configurations on how the mapping result data will be committed. First, you must select the Ontology and Branch that will receive the new commit. After that, there are radio buttons that will determine how the mapping result data will be treated when the commit is made. The first option will treat all the mapping result data as new data, meaning no existing data in the ontology branch will be removed. The second option will treat all the mapping result data as changes to the existing data on the ontology branch. This means that if there are entities or properties on entities in the ontology that are not present in the mapping result data, they will be removed.

map into ontology

A sample workflow using this tool would be to create an ontology in the Ontology Editor and create a branch that will received all mapped data commits. Then run your mapping from the Mapping Tool, commiting to the new branch as additions. Finally in the Ontology Editor, merge that branch with the mapped data commit into the MASTER branch. Then any subsequent runs of the mapping with updated data would be committed as changes to the mapped data branch and merged into the MASTER branch.

Datasets Manager

The Mobi Datasets Manager allows users to create, edit, clear, and delete datasets within the application to group and store Resource Description Framework (RDF) semantic data into various graphs for enhanced query isolation, data segmentation, and management.

Tip
To learn more about the structure of a dataset, refer to the Mobi Datasets Appendix.

To reach the Datasets Manager, click on the link in the left menu.

full datasets manager initial view
Figure 73. The Datasets Manager

The page displays a paginated list of all the datasets within the local Mobi repository. Each dataset in the list displays a preview of the dataset metadata, and a dropdown menu with edit, clear, and delete buttons. Clicking on a dataset displays the rest of the dataset metadata. Deleting a dataset deletes the dataset, catalog record, and all associated data graphs. Clearing a dataset removes all associated data graphs except the system default named graph. Clearing a dataset does not remove the dataset or the catalog record. Editing a dataset allows to you to change some information about the dataset. This list can also be filtered with search text.

To create a new dataset, click New Dataset and fill out the information in the creation overlay.

Create Dataset

new dataset overlay
Figure 74. New Dataset Overlay

The Create New Dataset overlay contains several sections. The Title field populates the dcterms:title annotation of the new dataset record. The Dataset IRI field allows you to specify what the IRI of the new dataset should be. If not provided, the system will create a unique one for you. The Description field populates the dcterms:description annotation of the new dataset record. The Keywords field will attach the entered values as keywords to the new dataset record. The Repository ID field displays the identifier of the repository registered within Mobi where the dataset and all associated named graphs will be stored. For now, this is defaulted to the system repository. Finally, you can select which ontologies should be used as the basis for the data. Select an ontology from the searchable list of ontologies to add it to the dataset. To remove a selected ontology, click the x next to the ontology name. Clicking Cancel will close the overlay. Clicking Submit will create the dataset with the provided metadata.

Note
The ability to create new repositories in Mobi is coming soon!

Edit Dataset

edit dataset overlay
Figure 75. Edit Dataset Overlay

The Edit Dataset overlay allows you to modify information about the dataset. The Title field modifies the value of the dcterms:title annotation of the dataset record. The Description field modifies the value of the dcterms:description annotation of the dataset record. The Keywords field allows you to add/remove keywords attached to the dataset record. The ontologies area allows you to modify the ontologies associated with the dataset record; just as during creation. Clicking Update will update the dataset record with the new metadata.

Caution
Datasets are associated with specific versions (commits) of an ontology record. In order to update a dataset to the latest version of an ontology record, you’ll need to remove the ontology, click Submit, then add that ontology back to the dataset.

Discover

The Mobi web-based Discover module allows users to quickly search and explore their knowledge graphs. The Explore tab provides an intuitive interface for quickly navigating through ontology-defined entities. The Search tab enables quick data filtering based on keywords and ontology properties. The Query tab allows users to develop and execute SPARQL queries.

Tip
To learn more about SPARQL queries, see the W3C Specification.
Note
The ability to save, publish, share and reuse SPARQL queries as part of applications or larger workflows is coming soon!

To reach the Discover page, click on the link in the left menu. The first tab shown is the Explore tab.

full discover page initial view
Figure 76. The Discover Page

Explore

The Explore tab of the Discover page allows you to get a high-level overview of the structure of your data within a dataset.

explore classes
Figure 77. Explore tab with classes

The Explore tab opens with a view of all the classes found within the selected dataset and a button to create a new instance. Each card displays the label and a brief description about a class, the number of instances defined as that class, a few of those instances, and a button to explore the instances themselves. Clicking Explore Data opens the instances view.

explore instances
Figure 78. Explore Tab with instances

The instances view contains a paginated list of all the instances defined as a particular class. Each card displays the label, brief description about an instance, a button to explore the instance itself, and a button to delete the instance. The label is determined based on the values of the rdfs:label, dc:title, or dcterms:title properties on the instance. The description is based on the values of the rdfs:comment, dc:description, or dcterms:description properties on the instance. You can navigate back to the classes view using the breadcrumb trail in the top left. Clicking View Class Name opens the single instance view. Clicking Create Class Name opens the single instance editor. If the particular class has been deprecated in the ontology, you will not be able to create a new instance.

explore single instance
Figure 79. Explore Tab with single instance

The single instance view displays the IRI, label, brief description, and list of all properties associated with the selected instance. Each property will only show one value by default; however, you can view more values, if there are any, by clicking the "Show More" link for that property. The instance view can also display any assertions on a reification of a property value statement by clicking on the small downward arrow on the right side of a property value. Clicking Edit opens the single instance editor.

explore single instance editor
Figure 80. Explore Tab with single instance editor

The single instance editor displays the IRI and a list of all properties associated with the selected instance in an editable format. The IRI can be edited by clicking the pencil button next to the IRI which will open the Edit IRI Overlay. If the instance being edited does not have all the required properties set, as described by cardinality restrictions in the ontology, the instance cannot be saved. To add a another property value, type in the provided input and press the ENTER key. To remove a property value, click on the "X" button of the associated chip. To view a complete property value and add assertions to its reification, click on the associated chip.

Caution
Editing the instance IRI might break relationships within the dataset.

To add a new property to the instance, click Add New Property and select the property in the overlay. After all edits have been made, clicking Cancel will discard the current changes and go back to the single instance view. Clicking Save will save the current changes to the repository and then go back to the single instance view.

The Search tab of the Discover page allows you to submit a quick search against a dataset using various preconfigured filters.

search full view
Figure 81. Search tab

The left side of the Search tab contains a form for filtering on different aspects of entities in a selected Dataset. Each type of filter is concatenated together so that your results match all your filters in each section. The top section allows you to search for entities containing certain keywords in their property values. The radio buttons allow you to toggle between finding entities that match any of your keywords (OR) or all of your keywords (AND). The middle section allows you specify classes to filter the matching entities. Again, the radio buttons allow you to toggle between finding entities with any selected class (OR) or all selected classes (AND).

The bottom section allows you to apply filters based on property values. The box displays all property filters you’ve already set and the results must match all of them. To add a new property filter, click Property and the Add New Property Filter overlay will appear. First, you must select a Property from dropdown. This list includes all properties in the dataset’s ontologies with no domain or a domain of one of the selected classes from the middle section. If no classes are selected in the middle section, all properties in the dataset’s ontologies will be available. If you select an object property, the Property dropdown will appear again so you can filter on properties on the instances in that range. If you wish to stop the filter at the existence of the object property instead, click the Submit button. If you select a data property, the Filter Type dropdown will appear with a list of types of filters depending on the range of the selected property. Once you select a filter type, the appropriate input box(s) will be shown.

search add property filter overlay 1
Figure 82. Add New Property Filter overlay with Property select
search add property filter overlay 2
Figure 83. Add New Property Filter overlay with Object Property selected
search add property filter overlay 3
Figure 84. Add New Property Filter overlay with Filter Type select

The right side of the Search tab displays the results of your most recent search. Each row represents a matching entity in the dataset and each column equates to a property on that entity that matched one of your filters. If multiple values on the same property matches one of your filters, the values will be separated onto different lines.

Query

The Query tab of the Discover page allows you to submit SPARQL query against the Mobi repository and optionally a specific dataset.

discover query editor overview
Figure 85. Query tab

The Query tab provides a SPARQL query editor powered by the YASGUI SPARQL library. The top section of the page contains the query editor (powered by YASQE), a Dataset field and a Submit button. The Dataset field contains a list of all available datasets within the Mobi repository. Selecting a dataset limits the query to search through the data within the selected dataset. Clicking Submit executes the entered query against the Mobi repository, optionally limited by the selected dataset, and updates the bottom section with the results.

The bottom section displays the results of the most recently submitted SPARQL query (powered by YASR). The section has separate tabs for rendering the query result set depending on the type of SPARQL query submitted. SELECT query results are displayed under the Table tab where the headers of the table are the variables specified in the SPARQL query. The Table comes with features such as filtering, page size, sorting and pagination. CONSTRUCT query results can be displayed under the Turtle, JSON-LD and RDF/XML tabs. The query results are limited to 500 triples/rows for rendering, but the entire result set can be downloaded using the button in the upper right corner of the bottom section.

discover construct query
Figure 86. Construct query

My Account

The My Account page of Mobi provides users with a way to configure their own account and customize various aspects of the application to suit their needs.

To reach the My Account page, click on the display of your username in the left menu.

my account link
Figure 87. My Account link

The My Account page contains four main tabs for configuring your account:

Profile

The Profile tab contains a form for viewing and editing your basic profile information. This information includes your First Name, Last Name, and Email address. None of this information is required. Your current settings for these fields will be displayed to start. To edit, simply change the values in one or more of the fields and and click Save in the bottom right. If the change was successful, you will see a success message at the top of the section.

profile tab
Figure 88. Profile Tab

Groups

The Groups tab contains a list of all the groups you belong to. Next to each group title is an indicator of how many users are within that group. If a group has the admin role, an indicator will be next to the group’s title.

groups tab
Figure 89. Groups Tab

Password

The Password tab contains a form for updating your password. To change it, you must first input your Current Password in the first field. Then enter your desired New Password in the second field and the Confirm Password field and click Save in the bottom right. If the change was successful, you will see a success message at the top of the tab.

password tab
Figure 90. Password Tab

Preferences

The Preferences tab will dynamically populate with user preference definitions added to the repository (see documentation here). These preferences are specific to your user.

preferences tab
Figure 91. Preferences Tab
Note
Default preferences coming soon!

Administration

The Administration page provides administrators with a portal to create, edit, and remove users and groups in Mobi. From this module, you can also assign high level access control for common actions within the application.

To reach the Administration page, click on Administration in the left menu. This option is not available to non-administrators.

administration link
Figure 92. Administration link

There are three main tabs of the Administration page:

Users

The Users tab allows you to create, edit, and remove users from the application.

users tab
Figure 93. Users Tab

The left side of the tab contains a list of all the users in Mobi. Each user is displayed using their first and last names, if available, or their username. If a user is an administrator, whether by having the admin role or by being a part of a group with the admin role, an indicator will be next to their username in the list. At the top of the list is a search bar that will filter the list of users based on their first name, last name, or username. Clicking on a user will load that user’s information into the right side of the section.

Note
The default Admin user can not be deleted.

The middle of the Users tab contains the username of the selected user, a block for viewing and editing the user’s profile information, and a block for resetting the user’s password. Resetting a user’s password cannot be undone.

The right side of the tab contains blocks for viewing and editing the selected user’s permissions and viewing the user’s groups. Clicking on the title of a group will open it in the Groups section.

To create a user, click Create User and the Create User overlay will appear. The Username field (required) must be unique within the application. The Password fields (required) allow you to enter in the password for the new user. The First Name, Last Name, and Email fields are not required, but allow you to enter in basic profile information for the new user. The last section contains a checkbox for setting whether the new user is an administrator. Clicking Cancel will close the overlay. Clicking Submit will create a new user with the entered information.

create user overlay
Figure 94. Create User Overlay

Groups

The Groups tab allows you to create, edit, and remove groups from the application. Groups allow you to associate users with one another and apply the same permissions and roles to all members.

groups tab
Figure 95. Groups Tab

The left side of the tab contains a list of all the groups in Mobi. Next to each group title is an indicator of how many users are within that group. At the top of the list is a search bar that will filter the list of groups based on their title. Clicking on a group title will load that group’s information into the right side of the section.

The right side of the tab contains the selected group’s title and two rows of blocks. The top row contains blocks that allow you to edit the group’s description and permissions. If a group has the "Admin" role, all members within that group are considered administrators.

The bottom row contains a block that allows you to view, add, and remove the group’s members. To add another user to the group, click Add Member and that line in the table will transform into a drop down selector of all the users in Mobi that have not already been selected. Selecting a user in this drop down will automatically add them to the group. To remove a user from the table, click on the corresponding delete button at the end of the row. Any changes in this table will immediately be applied. Clicking on a username in this table will open that user’s information in the Users section.

To create a group, click Create Group and the Create Group overlay will appear. The Group Title field (required) allows you to specify a name for the group. The Description field allows you to enter in a description about what the group represents. At the bottom of the overlay is a table for adding users to the group. Your user account will be added automatically. To add others to the group, click Add Member and that line in the table will transform into a drop down selector of all the users in Mobi that have not already been selected. To remove a user from the table, click on the corresponding delete button at the end of the row. Clicking Cancel will close the overlay. Clicking Submit will create a new group with the entered information and add the listed users to it.

create group overlay
Figure 96. Create group overlay

Permissions

The Permissions tab allows you to set high level access control for common actions in the application, such as creating Ontology Records and querying the system repository. Permissions can be set to allow all authenticated users (the Everyone slider) or limit access to specific users and groups. To set the permission to a user or group, unselect the Everyone permission, find a user or group in the search box underneath the appropriate box, and select it. To remove a user or group from the permission, click the X button next to the username or group title. After you have finished making the changes you want, make sure to click the save button in the bottom right.

Note
More permissions coming soon!
permissions tab
Figure 97. Permissions Tab

Configuration

All default configuration files for Apache Karaf and Mobi are located inside the {MOBI_HOME}/etc directory.

Mobi

Service Configuration

The basic Mobi services can be configured using the following files:

Table 2. Mobi Service Configuration Files
Configuration File Description

com.mobi.catalog.config.CatalogConfigProvider.cfg

Configurations for the Mobi Catalog

com.mobi.platform.config.state.StateManager.cfg

Configurations for the Mobi State Manager

com.mobi.service.repository.native-system.cfg

Configurations for the Mobi System Repository

com.mobi.service.repository.native-prov.cfg

Configurations for the Mobi Provenance Repository

By default, all resources besides provenance data are stored in the system repository which is an RDF triplestore located in the data/repos/system directory of the Mobi distribution. The provenance data is stored within the prov repository. Each repository in Mobi is uniquely identified by its id. To change the data location, id, or title of either repository, edit the dataDir, id, and title properties respectively in the appropriate file. Apache Karaf will dynamically reload any changes made to this existing file.

You can create new repositories to be used for storage in Mobi. First, choose either a "native" repository or a "memory" repository. These two types of repositories are defined in the NativeRepositoryConfig and MemoryRepositoryConfig classes in the com.mobi.repository.impl.sesame module. Once you have chosen the type of repository, make a new .cfg file in the {MOBI_HOME}/etc directory with a file name that starts with either "com.mobi.service.repository.native" or "com.mobi.service.repository.memory". In the file, set the id, title, and dataDir properties you wish for the repository. The file should look like this:

id=demo
title=Demonstration
dataDir=path/to/directory

Apache Karaf will automatically recognize the new configuration file and create the new repository.

The repository that all Catalog resources are stored with is controlled within the com.mobi.catalog.config.CatalogConfigProvider.cfg file. The storage repository for all other types of data are controlled individually in other configuration files. To change each of these repository configurations, open the associated .cfg file and change the id of the repository.target property to be the id of the new repository. For example to change the repository for storing Catalog resources to the repository in the example above, you would open the com.mobi.catalog.config.CatalogConfigProvider.cfg file and edit the repository target line to be:

repository.target = (id=demo)

Apache Karaf will automatically detect the changes and reload the new configuration.

Security Configuration

The configuration for user authentication, authorization, and management are stored in the following files in the {MOBI_HOME}/etc directory:

Table 3. Mobi Security Configuration Files
Configuration File Description

com.mobi.jaas.engines.RdfEngine.cfg

Configurations for the Mobi RDF Engine

com.mobi.security.policy.api.xacml.XACMLPolicyManager.cfg

Configurations for the XACML security policy manager

Mobi utilizes JAAS for user authentication and basic authorization. By default, user credentials and information are managed by the RdfEngine service which is configured with the com.mobi.jaas.engines.RdfEngine.cfg file. The file contains an id of the repository to be used for storage, the encryption settings for JAAS which are enabled to start, and the two default roles: "user" and "admin". Apache Karaf will automatically detect any changes and reload the updated configurations.

The default user for Mobi is "admin" with password "admin". To change the credentials of the "admin" user or perform any other user management activities, utilize the Administration page, the My Account page, or the appropriate REST endpoints.

For more advanced authorization functionality, Mobi uses the an Attribute Based Access Control (ABAC) system called XACML. Policies describing the attributes for allowing or denying individual access requests are managed by the XACMLPolicyManager service which is configured with the com.mobi.security.policy.api.xacml.XACMLPolicyManager.cfg file. The file contains an id of the repository to be used for storage, the location the XACML policy files should be stored in, and whether the policy file location should be created if it does not already exist. Apache Karaf will automatically detect any changes and reload the updated configurations.

Email Service Configuration

The configuration for the Mobi Email Service is stored in the following file in the {MOBI_HOME}/etc directory:

Table 4. Mobi Email Service Configuration Files
Configuration File Description

com.mobi.email.api.EmailService.cfg

Configurations for the Mobi Email Service

The Mobi Email Service is built on the Apache Commons Email API. The Email Service provides the ability to connect to a provided SMTP server and send an email using a configured email account. By default, the service is configured to connect to a Gmail SMTP server in the com.mobi.email.api.EmailService.cfg file. The service has configurations for smtpServer, port, emailAddress, emailPassword, security, and emailTemplate. Please see below for different configurations of popular email services.

Email Template

The Mobi Email Email Service supplies a default email template that works across most email clients. The default file is located in the {MOBI_HOME}/etc directory. If you want to provide your own email template, modify the emailTemplate configuration to the new email template with either a relative or absolute path to the file. The email service will resolve relative file paths for an email template using the {MOBI_HOME}/etc directory as the base directory.

The email service provides a method for doing a simple string replace on the !|$MESSAGE!|$ binding within the template. For more complex HTML inserts, the service provides a method to replace all HTML between the two !|$BODY!|$ bindings. Custom templates must have the aforementioned bindings (!|$MESSAGE!|$ & !|$BODY!|$). The !|$MESSAGE!|$ binding must be between two !|$BODY!|$ bindings. For example:

<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
...
<body>
!|$BODY!|$
<table>
    <tbody>
    <tr>
        <td>
            <p>
                <!-- A simple message to replace -->
                !|$MESSAGE!|$
            </p>
        </td>
    </tr>
    </tbody>
</table>
!|$BODY!|$
...
</body>
</html>
SMTP Configurations
Gmail

To send emails with Gmail, you must also follow the steps here to allow less secure apps to access the gmail account. Gmail also has strict sending limits that can impair functionality as your organization grows. Additionally, Gmail may flag a machine that it does not recognize and prevent access. If this occurs, log in to your gmail and grant the device access.

smtpServer = smtp.gmail.com
emailAddress = my.email@gmail.com
emailPassword = my-password
port = 587
security = STARTTLS
emailTemplate = emailTemplate.html
Outlook
smtpServer = smtp-mail.outlook.com
emailAddress = my.email@outlook.com
emailPassword = my-password
port = 587
security = STARTTLS
emailTemplate = emailTemplate.html
Office 365
smtpServer = smtp.office365.com
emailAddress = my.email@yourdomain.com
emailPassword = my-password
port = 587
security = STARTTLS
emailTemplate = emailTemplate.html
Yahoo
smtpServer = smtp.mail.yahoo.com
emailAddress = my.email@yahoo.com
emailPassword = my-password
port = 465
security = STARTTLS
emailTemplate = emailTemplate.html
Mailgun
smtpServer = smtp.mailgun.org
emailAddress = my.email@mg.gitlab.com
emailPassword = my-password
port = 587
security = STARTTLS
emailTemplate = emailTemplate.html

Apache Karaf

The Karaf instance that runs Mobi can be configured using the configuration files located in the {MOBI_HOME}/etc directory.

Table 5. Relevant Karaf Configuration Files
Configuration File Description

org.ops4j.pax.url.mvn.cfg

Configurations for Maven repositories used for bundle resolution and deployment

org.ops4j.pax.web.cfg

Configurations for HTTPS connections

The org.ops4j.pax.url.mvn.cfg file specifies how Apache Karaf will resolve Maven URLs. This file is set up so that Apache Karaf will use the basic Maven repositories along with your local Maven repository and the public Mobi remote repository to resolve artifacts.

The org.ops4j.pax.web.cfg file configures the web service Apache Karaf uses to run Mobi. By default, Mobi only runs HTTPS on port 8443.

Mobi Shell

The Mobi Shell is a wrapper around the Karaf shell which provides additional commands and tools for working with Mobi data. To access the shell, run the bin/client script in MOBI_HOME (that’s bin\client.bat for you Windows users). The startup screen of the Mobi shell looks like the following.

                 @#@@
                @###@
               @@@@@                   _     _
   @@@       @@@@      _ __ ___   ___ | |__ (_)
  @,,,@@@@@&    @     | '_ ` _ \ / _ \| '_ \| |
  @,,&&     @  @      | | | | | | (_) | |_) | |
              @@      |_| |_| |_|\___/|_.__/|_|
               @@
              @///@
              @////&
               @@@@


  mobi (1.12.37)
  Powered by Apache Karaf (4.0.6)

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or 'osgi:shutdown' to shutdown mobi.

karaf@mobi>

The Mobi specific commands all start with mobi:. To view the list of available commands, type mobi: and hit TAB. To get information about a particular command, type the name of the command and --help afterwards and run it. For example, running mobi:import --help would show you this.

karaf@mobi>mobi:import --help
DESCRIPTION
        mobi:import

	Imports objects to a repository or dataset

SYNTAX
        mobi:import [options] ImportFile

ARGUMENTS
        ImportFile
                The file to be imported into the repository

OPTIONS
        -c, --continueOnError
                If true, continue parsing even if there is an error on a line.
        -d, --dataset
                The id of the DatasetRecord the file will be imported to
        -r, --repository
                The id of the repository the file will be imported to
        --help
                Display this help message
        -b, --batchSize
                The number representing the triple transaction size for importing.
                (defaults to 10000)

You can also run commands in the Mobi shell without opening it by running bin/client "command". For example, to run the mobi:repository-list command, you would run bin/client "mobi:repository-list". If the command you are running involves files with spaces in the name, make sure the spaces are escaped, meaning use "\ " instead of " ". The same goes for commands that include text within quotes, make sure the quotes are escaped as well.

Administration Guide

Mobi is made available as a compressed distribution package available here. Deployment consists of unpacking this distribution to an appropriate location on the filesystem and modifying included configuration files. Mobi comes pre-bundled with an open-source, file-based RDF database. By default, all data, logs, and configurations will be stored in the extracted file location.

Mobi Requirements

Hardware Requirements

We provide recommended hardware requirements as a guideline. These specifications are based on standard deployment environments. Larger production data or user requirements may require more powerful hardware configurations.

The table below provides a summary of the recommended hardware for production servers and the minimum requirements for test servers.

Component Minimum Recommended Guidelines

Available RAM

1 GB

8 GB or more

Mobi needs enough RAM to load large ontology and data files and run Mobi processes. The configurations provided refer to maximum Java heap size.

Disk Space

10 GB

40 GB or more

By default, Mobi stores all data and configurations in the extracted file location.

CPU

1 core

4 cores or more

Multi-core configurations dramatically improve performance of the bundled application server and database.

Software Requirements

The table below provides a summary of the software requirements.

Component Minimum Recommended Guidelines

Operating System

RHEL/CentOS 6
Windows 7
OSX

RHEL/CentOS 7

Mobi runs within standard Java runtimes; however, we recommend RHEL/CentOS operating systems for on-premise or cloud-based server environments.

Java

1.8

1.8 (latest)

The latest versions of Java 8 include security and performance updates.

Web Browser

Chrome
Firefox
Safari
Edge

Chrome

Use the latest versions of web browsers for best compatibility, performance, and security.

Firewall Requirements

The table below lists the TCP ports to open on the Mobi host.

Port Description

8443

Application HTTPS port.

Tip
We recommend running Mobi on the default port 8443 and using firewall configuration or a proxy server for SSL (port 443) termination and redirection. Mobi does not run on non-SSL ports by default.

Installing Mobi

Pre-Installation Configuration

Create Service Account

Before installing Mobi, create a service account on the host server. The account will be used to run Mobi. The service account should meet the following requirements:

  • The service account must have read and write permissions for the Mobi installation directory. On Linux, this is typically /opt/mobi/mobi-distribution-<version>.

On a standard RHEL/CentOS system, this can be created using the following command:

sudo useradd -d /opt/mobi mobi
Install Java 8

Mobi requires the latest version of Java 1.8 to operate. On a standard RHEL/CentOS system this can be installed using the following command:

sudo yum install java-1.8.0-openjdk

The JAVA_HOME environment variable must be set for the user running Mobi. On a standard RHEL/CentOS system this can be set using the following commands:

sudo su - mobi
echo 'export JAVA_HOME=/etc/alternatives/jre_1.8.0' >> ~/.bashrc
exit

Install Mobi

Follow the instructions below to install Mobi. These instructions assume that you have copied the Mobi distribution to the server.

Note
These instructions are prepared for a standard RHEL/CentOS deployment server.
  1. Unpack Mobi to the installation parent directory (e.g. /opt/mobi)

    sudo su - mobi
    tar -xf $MOBI_DIST.tar.gz
  2. Create a symlink to the latest distribution

    ln -s $MOBI_DIST latest
  3. Start the Mobi server

    cd latest
    ./bin/start

To stop the Mobi server, run the following command:

./bin/stop

Post-Installation Configuration

Change the Default Java Heap Size

Set the max heap size in $MOBI_DIST/bin/setenv (e.g. JAVA_MAX_MEM=4G)

Change the Default Web Port

Change the default SSL port in $MOBI_DIST/etc/org.ops4j.pax.web.cfg

org.osgi.service.http.port.secure = <SSL_APPLICATION_PORT>
Tip
We recommend running Mobi on the default port 8443 and using firewall configuration or a proxy server for SSL (port 443) termination and redirection. Mobi does not run on non-SSL ports by default.
Configure Custom SSL Certificates

Mobi comes bundled with default self-signed SSL certificates stored in a Java Keystore file in etc/keystore. To provide your own SSL certificates, simply replace the default keystore file with your own:

cp mycerts.jks $MOBI_DIST/etc/keystore

If there is a keystore password, it can be configured in the $MOBI_DIST/etc/org.ops4j.pax.web.cfg file using the following configuration properties:

Configuration Property Description

org.ops4j.pax.web.ssl.password

The password used for keystore integrity check

org.ops4j.pax.web.ssl.keypassword

The password used for keystore

Configure Default Authentication Token (JWT) Duration

To configure the web authentication token duration, you must create a file called com.mobi.jaas.SimpleTokenManager.cfg with the property detailed below and put it in the etc/ directory of your Mobi installation before starting the application, otherwise the token duration will use the default of 24 hours.

Property Name Description Required Default

tokenDurationMins

Token Duration time in minutes

1440

An example file would look like this.

### 1 day token duration
tokenDurationMins = 1440
Note
.p12 and .jks files should both be supported
Installing Mobi as a Service

We recommend that you configure Mobi as a Linux service for starting Mobi automatically as the service user. Follow the instructions below to implement the service on a standard RHEL/CentOS environment.

Note
The below steps should be run as the root user.
Warning
Be sure to correctly configure the file locations and user.
  1. Create a file called mobi.service in the /usr/lib/systemd/system directory. For example:

    [Unit]
    Description=Mobi Service.
    After=network.target
    StartLimitIntervalSec=30
    
    [Service]
    Type=forking
    PIDFile=/install_path/latest/karaf.pid
    User=mobi
    ExecStart=/install_path/latest/bin/start
    ExecStop=/install_path/latest/bin/stop
    ExecReload=/install_path/latest/bin/stop; /install_path/latest/bin/start
    Restart=always
    
    [Install]
    WantedBy=default.target
  2. Save and close the file, and then run the following commands to start and enable the new service:

    systemctl start mobi
    systemctl enable mobi

Once the service is enabled, Mobi should be running. The Mobi process will start and stop automatically with the server. Any time you start and stop Mobi manually, run the following systemctl commands: sudo systemctl stop mobi and sudo systemctl start mobi.

Password Encryption Configuration

Mobi provides a way to automatically encrypt plaintext passwords stored within service configurations on startup and subsequent updates. The setup for this is very short. All you have to do is ensure that a file called com.mobi.security.api.EncryptionService.cfg exists in the $MOBI_DIST/etc directory and contains the following fields:

enabled=true
password=ENTER_A_UNIQUE_PASSWORD_HERE
Note
This password is not the password you want to encrypt, rather it is a unique master password used for encrypt and decrypt operations.

This encryption config is present and enabled by default, meaning your passwords will be automatically encrypted. An alternate way of providing an encryption master password is via environment variable. To configure the use of an environment variable, use the following fields:

enabled=true
variable=MY_CHOSEN_ENVIRONMENT_VARIABLE

If you use an environment variable, make sure before you start Mobi that you have stored a unique password as the value for that environment variable.

Warning
If there is a default password in the Encryption Config (i.e. CHANGEME) make sure you change it to a unique password before starting Mobi, otherwise your passwords will be easy to decrypt.

Once the encryption config is added, start Mobi and if a Mobi service configuration includes a plaintext password, it will encrypt the value and update the configuration file. To change an encrypted value, simply replace it with the new plaintext value in the configuration file and after a few seconds it will be automatically re-encrypted and the file will be updated.

Services that use Encryption
Service Config File Field that gets encrypted

Email

com.mobi.email.api.EmailService.cfg

emailPassword

To update the encryption master password, change the password field in the com.mobi.security.api.EncryptionService.cfg file while Mobi is running. After a few seconds have passed, all passwords will be automatically re-encrypted using the new master password.

Note
If the master password is changed while AVM is not running, all previously encrypted passwords must be re-entered in plain text for the encryption service to re-encrypt.

Developer Guide

Prerequisites

To build the Mobi source code, you must have the following software and tools installed.

Technology Version Download Link

Java

8

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Maven

3.1+

https://maven.apache.org/download.cgi

Node.js

10+

https://nodejs.org/en/download/

Google Chrome

94+

https://www.google.com/chrome/

Build from Source

Clone the Mobi project from GitHub and navigate to that directory on your machine. Run the following command to build the source:

mvn clean install

The build creates the Mobi distribution as both a .tar.gz file and a .zip file in the mobi-distribution/target directory. Extract one of the files and navigate into that directory.

Inside the extracted distribution directory, start up the Mobi Karaf instance. For Unix/Linux:

bin/start

or for Windows:

bin\start.bat

All the Mobi bundles and services and their dependencies will be automatically deployed using OBR.

The Mobi web application should now be accessible at https://localhost:8443/mobi/index.html.

OntologyCache Configuration File

Mobi utilizes the Repository Cache Ontology API implementation to represent Ontologies.

Configuration file for the CacheRepositoryCleanup job:

com.mobi.cache.impl.repository.CleanupRepositoryCache.cfg

This file is responsible for deleting stale ontologies within the repository after a specified period in order to preserve resources and improve processing. The format looks like the following:

repoId = ontologyCache
expiry = 1800
scheduler.expression=0 0 * * * ?

Clearing Pre-existing Configurations in Karaf

If Mobi has been run with the OWLAPI implementation prior to using the Repository Cache implementation, a configuration object will have been stored in Karaf and must be removed.

From the Karaf terminal run:

karaf@mobi()> config:delete com.mobi.ontology.impl.owlapi.OntologyManager

In order to revert back to the OWLAPI implementation after the Repository cache implementation has been launched, run the following:

karaf@mobi()> config:delete com.mobi.ontology.impl.repository.OntologyManager

Load Dataset Data

Data can be manually loaded into an existing Dataset using the Mobi shell. You will need the full path to the data file and the IRI of the target DatasetRecord.

Open the Mobi shell and run the mobi:import command passing the IRI of the DatasetRecord and the path to the data file. For example, if you wanted to load data located at /Users/tester/Documents/testData.trig into the https://mobi.com/records/my-dataset DatasetRecord, you would run the following command:

mobi:import --dataset https://mobi.com/records/my-dataset /Users/tester/Documents/testData.trig

All triples that are not within a named graph will be loaded into the system default named graph. All triples within named graphs will be added and their named graphs associated with the Dataset.

Accessing Swagger REST API Documentation

Every installation of Mobi provides Swagger Documentation for the full suite of Mobi REST APIs. This documentation is provided as a standard Swagger YAML file as well as a fully interactive hosted version. The Swagger YAML file can be downloaded at $MOBI_HOST/swagger-ui/mobi-swagger.yaml. To reach the Swagger Documentation UI, navigate to $MOBI_HOST/swagger-ui/index.html. For example, in a default deployment these URLs would look like https://localhost:8443/swagger-ui/mobi-swagger.yaml and https://localhost:8443/swagger-ui/index.html, respectively.

Swagger REST API Documentation

Translating Documents

Files in the xml, json, or csv formats can be transformed into an ontology and corresponding instance data using Mobi’s document translation tool. This experimental feature can be utilized via REST endpoint, the Mobi shell, or from the Swagger UI, with all methods providing users configuration options to alter the generated files.

Utilizing the Mobi Shell

The tool can be run from the Mobi shell with the mobi:document-translate command. The command accepts the full path to both the input file to translate and output location for the result. Below is an example call to the command:

mobi:document-translate /Users/tester/Documents/example.json /Users/tester/Documents/outputDir

The Document Translate command accepts several additional configuration options to tailor the way the input file is processed. These options currently include the ability to set the default namespace of the generated ontology and instance data, specify the type of file being translated, and set a number of rows in a CSV to be analyzed before identifying a data property range. The command result is a zip file located at the output destination that contains two turtle files: ontology.ttl which will contain an ontology describing the structure of the input file and data.ttl which will contain the data within your input file translated into RDF data conforming to the ontology.

Utilizing the REST endpoints and Swagger UI

Mobi’s REST endpoints & Swagger UI provide additional ways to use the document translation tool. When using either a direct REST call or the Swagger UI, users are able to select an input file from their filesystem and convert it to valid RDF. If successful, output is returned as a downloadable zip file. Similar to the output generated by the Mobi shell, this zip file contains two turtle files containing the generated ontology and conforming instance data respectively. Additionally, these two methods provides users the same configurable options that the Mobi shell does, with one additional option. When using Rest endpoints or the Swagger UI to translate a document, users are able to also specify the name of the output file. If one is not specified, the name of the input file will be used with a timestamp added on to the end.

Document Translation Swagger Documentaion
Document Translation Postman Documentaion

Translating Different File Types

XML

The XML translator uses the hierarchical structure of the XML input file in order to construct classes and object properties.

XML Input File
Figure 98. XML Example File

When generating the ontology, each element is simultaneously treated as a class and object property if it has child elements and is regarded as a datatype property if it does not. The output will resemble a file similar to the one below.

XML Ontology Ouput File
Figure 99. XML Example Ontology File

The generated data file is composed of elements that have been deemed a class and that have literal values attached to it. Each instance is given a unique IRI based on the namespace of the ontology with a trailing UUID attached at the end.

XML Data Output File
Figure 100. XML Example Data File
JSON

Given a JSON file like below, the JSON translator will use the nested structure of JSON objects in order to construct classes and object properties.

JSON Input File
Figure 101. JSON Example File

An output ontology is then generated using the passed in IRI or a UUID as the namespace. Classes and object properties relating these classes are created based on the keys present in the input file.

JSON Ontology Output File
Figure 102. JSON Example Ontology File

The generated data file is created by utilizing the literal values of each key object. For each instance of a JSON object there is in the input file an RDF entity is created with the same namespace as the ontology.

JSON Data Output File
Figure 103. JSON Example Data File
CSV

The CSV translation tool is the only translator that does not create multiple classes or any object properties. A singular class is generated per file, with the name of the file being used as the name of the class.

CSV Input File
Figure 104. CSV Example File

Each column header is treated as a different datatype property, with the translator parsing a certain number of rows to determine the range of the property.

CSV Ontology Ouput File
Figure 105. CSV Example Ontology File

When creating the instance data, each row within the file is treated as an instance of the class with the cell values being the object of the triples generated by the datatype properties.

CSV Data Output File
Figure 106. CSV Example Data File

Appendix A: Mobi Mappings

Mobi mappings are used to convert delimited data into RDF and are made up of instances of classes defined in a custom ontology found in the com.mobi.etl.api/src/main/resources/delimited.ttl file in the source code. These main classes are:

Note

All examples in this Appendix will be in Turtle RDF serialization and use the following prefixes:

Prefix Namespace

example

http://guide.org/

delim

http://mobi.com/ontologies/delimited#

Mapping

The delim:Mapping class represents the mapping itself. Every mapping must have one and only one instance of the Mapping class. Properties associated with this class provide information about the mapping that are needed for the Mapping Tool to have context. These properties are:

sourceRecord

The delim:sourceRecord property specifies the OntologyRecord a mapping uses for its classes and properties. The Mapping Tool requires this property along with sourceBranch and sourceCommit to retrieve a specific version of an ontology saved in Mobi. A mapping will have access to all entities defined in ontologies within the imports closure of the source ontology. The Mapping Tool utilizes all class and property definitions to validate the class and property mappings and apply the correct datatypes to data property values.

Example 1. sourceRecord
example:DocumentExample delim:sourceRecord <http://mobi.com/records/uhtc> .

sourceBranch

The delim:sourceBranch property specifies the Branch of the sourceRecord a mapping uses for its classes and properties. The Mapping Tool requires this property along with sourceRecord and sourceCommit to retrieve a specific version of an ontology saved in Mobi. A mapping will have access to all entities defined in ontologies within the imports closure of the source ontology. The Mapping Tool utilizes all class and property definitions to validate the class and property mappings and apply the correct datatypes to data property values.

Example 2. sourceBranch
example:DocumentExample delim:sourceBranch <http://mobi.com/branches/master> .

sourceCommit

The delim:sourceCommit property specifies the Commit of the sourceBranch a mapping uses for its classes and properties. The Mapping Tool requires this property along with sourceRecord and sourceBranch to retrieve a specific version of an ontology saved in Mobi. A mapping will have access to all entities defined in ontologies within the imports closure of the source ontology. The Mapping Tool utilizes all class and property definitions to validate the class and property mappings and apply the correct datatypes to data property values.

Example 3. sourceCommit
example:DocumentExample delim:sourceCommit <http://mobi.com/commits/0> .

ClassMapping

The delim:ClassMapping class represents a blueprint for creating an instance of a class. Every ClassMapping defined in a mapping will create an instance of the class it maps to for every row in a set of delimited data. Each class instance created will have a generated IRI. Properties associated with this class specify how the class instance it creates should be constructed. These properties are:

mapsTo

The delim:mapsTo property specifies the class a ClassMapping will create. This is a required property for a ClassMapping since otherwise, the Mapping Tool will not know which class to create an instance of. It must point to a class that is defined either within the source ontology of the mapping or one of the ontologies in the source ontology’s imports closure.

Example 4. mapsTo
example:ClassMappingExample delim:mapsTo <http://mobi.com/ontologies/uhtc> .

dataProperty

The delim:dataProperty property specifies a DataMapping that is associated with a ClassMapping. It must point to a DataMapping instance defined within the mapping. A ClassMapping can have one or more of this property. Every instance of a class created from a ClassMapping will have the property specified in the DataMapping specified by dataProperty.

Example 5. dataProperty
example:ClassMappingExample delim:dataProperty example:DataMapping1 ;
    delim:dataProperty example:DataMapping2 .

objectProperty

The delim:objectProperty property specifies an ObjectMapping that is associated with a ClassMapping. It must point to a ObjectMapping instance defined within the mapping. A ClassMapping can have one or more of this property. Every instance of a class created from a ClassMapping will have the property specified in the ObjectMapping specified by objectProperty.

Example 6. objectProperty
example:ClassMappingExample delim:objectProperty example:ObjectMapping1 ;
    delim:objectProperty example:ObjectMapping2 .

hasPrefix

The delim:hasPrefix property specifies the namespace of the IRI for every class instance created by a ClassMapping. This property is required by the Mapping Tool so it knows how to construct the IRI for each class instance created by the ClassMapping. The value of this property is a string and must be a valid namespace.

Example 7. hasPrefix
example:ClassMappingExample delim:hasPrefix "http://guide.org/example/" .

localName

The delim:localName property specifies how the local name of the IRI will be generated for every class instance created by a ClassMapping. This property points to a string literal and must be in the following format. The string must start with a dollar sign ($) and contain either the string "UUID" or a number surrounded by curly braces "{}". The "UUID" string will generate a unique identifier for every class instance created by the ClassMapping. A number will grab the value of the column at that zero-based index in the row being mapped. If the column specified has duplicate values, the Mapping Tool will combine the properties of every class instance with that IRI and combine them into a single instance. If this property is not set on a ClassMapping, the Mapping Tool will default to generating a UUID for every class instance.

Example 8. localName

This means every class instance will have a unique identifier for a local name.

example:ClassMappingExample1 delim:localName "${UUID}" .

This means every class instance will have the value from the third column for a local name.

example:ClassMappingExample2 delim:localName "${2}" .

DataMapping

The delim:DataMapping class represents a blueprint for creating a data property on a class instance. Since data properties in an ontology point to literal values, a DataMapping specifies a column whose value in the row being mapped will be used as the value of the generated data property. Properties associated with this class define how a data property will be created. These properties are:

columnIndex

The delim:columnIndex property specifies which column a DataMapping should pull the value from to set as the value of the generated data property. This property is required for a DataMapping so that the Mapping Tool knows where to get the value of a data property. All column values retrieved by this property are interpreted as strings. The value of this property must be a string and all the column indexes are zero-based.

Example 9. columnIndex

This will retrieve the value from the first column.

example:DataMapping1 delim:columnIndex "0" .

hasProperty

The delim:hasProperty property specifies which data property a DataMapping will create. This property is required for a DataMapping so that the Mapping Tool knows what property to create. It must point to a data property defined either within the source ontology of the mapping or one of the ontologies in the source ontology’s imports closure. This property can be associated with either a DataMapping or a ObjectMapping.

Example 10. hasProperty for DataMapping
example:DataMapping1 delim:hasProperty <http://mobi.com/ontologies/uhtc/aDataProperty> .

datatypeSpec

The delim:datatypeSpec property specifies a manual override for the datatype of generated data property values resulting from a DataMapping. By default, the datatype will be determined from the range of the property if found with a fallback of string. This setting has precedence over the range of the property. This property is optional for a DataMapping. The value of this property must be the IRI of a standard XSD datatype.

Example 11. datatypeSpec

This will set the datatype of all values to xsd:double.

example:DataMapping1 delim:datatypeSpec xsd:double .

languageSpec

The delim:languageSpec property specifies a language for all generated data property values resulting from a DataMapping. If this property is set, the mapper will manually change the datatype of the value to be rdfs:langString. Any datatype specified by the range of the property will be ignored. This property is optional for a DataMapping. The value of this property must be a valid language tag string (found here under the ISO 639-1 column).

Example 12. languageSpec

This will set the language of all values to be English.

example:DataMapping1 delim:languageSpec "en" .

ObjectMapping

The delim:ObjectMapping class represents a blueprint for creating an object property on a class instance. Since object properties in an ontology point to other classes or class expressions, an ObjectMapping specifies a ClassMapping that will be created for the same row and whose generated class instance will be used as the value of the generated object property. Properties associated with this class define how an object property will be created. These properties are:

classMapping

The delim:classMapping property specifies which class instance generated from a ClassMapping will be used as the value of the generated object property. This property is required for an ObjectMapping so that the Mapping Tool knows which class should be the value of the object property. The generated value will be the class instance created by the specified ClassMapping for the row being mapped. The value must be a ClassMapping defined within the mapping.

Example 13. classMapping
example:ObjectMapping1 delim:classMapping delim:ClassMappingExample .

hasProperty

The delim:hasProperty property specifies which object property an ObjectMapping will create. This property is required for an ObjectMapping so that the Mapping Tool knows what property to create. It must point to a object property defined either within the source ontology of the mapping or one of the ontologies in the source ontology’s imports closure. This property can be associated with either a ObjectMapping or a DataMapping.

Example 14. hasProperty for ObjectMapping
example:ObjectMapping1 delim:hasProperty <http://mobi.com/ontologies/uhtc/aObjectProperty> .

Appendix B: Mobi Datasets

Mobi datasets are used to group and store RDF data into various graphs for enhanced query isolation, data segmentation, and management. The Mobi dataset structure is defined in a custom ontology found in the com.mobi.dataset.api/src/main/resources/dataset.ttl file in the source code. This design is loosely based on the W3C Specification for SPARQL Datasets wherein a collection of graphs can be queried as default named graphs or named graphs. The primary class is dataset:Dataset, and the properties associated with this class provide information about all the named graphs within the dataset. These properties are:

Note

All examples in this Appendix will be in TriG RDF serialization and use the following prefixes:

Prefix Namespace

example

http://guide.org/

dataset

http://mobi.com/ontologies/dataset#

systemDefaultNamedGraph

The dataset:systemDefaultNamedGraph property specifies the default named graph that Mobi will use when loading data that does not specify a graph (e.g. data from a Turtle file). For example, this approach is currently used for data created by the Mapping Tool. This named graph will be cleared, but not removed when a dataset is cleared.

Example 15. systemDefaultNamedGraph
GRAPH example:DatasetExample {
    example:DatasetExample a dataset:Dataset ;
        dataset:systemDefaultNamedGraph example:sdng .
}

GRAPH example:sdng {
    example:Subject a example:Object .
}

defaultNamedGraph

The dataset:defaultNamedGraph property specifies a default named graph within the dataset. These graphs are not maintained by the system and can be used when data segmentation is required within a dataset. These graphs are removed when a dataset is cleared.

Example 16. defaultNamedGraph
GRAPH example:DatasetExample {
    example:DatasetExample a dataset:Dataset ;
        dataset:defaultNamedGraph example:dng .
}

GRAPH example:dng {
    example:Subject a example:Object .
}

namedGraph

The dataset:namedGraph property specifies a named graph within the dataset. These graphs are not maintained by the system and can be used when data segmentation is required within a dataset. These graphs are removed when a dataset is cleared.

Example 17. namedGraph
GRAPH example:DatasetExample {
    example:DatasetExample a dataset:Dataset ;
        dataset:namedGraph example:ng .
}

GRAPH example:ng {
    example:Subject a example:Object .
}

Appendix C: Settings Framework

The Settings Framework was designed to allow the tracking and editing of Settings within the Mobi Application. The framework was designed to be easily extensible such that a new setting can be added to the platform with only some RDF and a few code changes.

The Preferences Tab is powered by the User Preference definitions stored within the system which can be tailored to populate different types of forms depending on the type of data to be stored.

Setting RDF Definition

In order to introduce new Settings to the Mobi Application, a developer must create an RDF representation of the Setting they want to add to the application. The Setting Framework uses SHACL to define settings. Setting RDF must consist of exactly one SHACL NodeShape and one SHACL PropertyShape in order to be recognized as a Setting by the Mobi Application. Requirements for the structure of these SHACL shapes is outlined below.

The following prefixes will be used in the rest of this appendix:

Prefix Namespace

owl:

http://www.w3.org/2002/07/owl#

rdfs

http://www.w3.org/2000/01/rdf-schema#

shacl:

http://www.w3.org/ns/shacl#

setting:

http://mobi.com/ontologies/setting#

xsd:

http://www.w3.org/2001/XMLSchema#

For an explanation of what each SHACL class and property represent, read the descriptions given here: https://www.w3.org/TR/shacl/. The following are descriptions of Mobi specific properties.

setting:Preference

The setting:Preference class acts as the parent class of all preferences within the Mobi Application. Mobi preferences always have an rdfs:subClassOf setting:Preference and are also of type sh:NodeShape.

setting:ApplicationSetting

The setting:ApplicationSetting class acts as the parent class of all application settings within the Mobi Application. Mobi application settings always have an rdfs:subClassOf setting:ApplicationSetting and are also of type sh:NodeShape.

Note
From here on, when referring to either setting:Preference or setting:ApplicationSetting the phrase setting subType may be used.

setting:PreferenceGroup

Every Mobi preference must have a setting:inGroup of a instance of setting:PreferenceGroup. These preference groups are meant to group together semantically related preferences.

setting:ApplicationSettingGroup

Every Mobi application setting must have a setting:inGroup of a instance of setting:ApplicationSettingGroup. These application setting groups are meant to group together semantically related application settings.

setting:FormField

Instances of the setting:FormField class are used by Mobi settings to specify the form input that is used by the UI to select setting values.

setting:hasDataValue

The setting:hasDataValue property is used by instances of setting subTypes to point to the current value of that setting. All Settings must point to a Property Shape that has an sh:path of setting:hasDataValue.

setting:usesFormField

The setting:usesFormField property is used by the required sh:PropertyShape of a Mobi Setting to designate the type of form input that will be used by the frontend to accept setting values for that specific setting.

setting:inGroup

The setting:inGroup property specifies either the setting:PreferenceGroup or setting:ApplicationSettingGroup that a Mobi Setting belongs too. It is used to semantically group related Settings in the UI.

Required SHACL NodeShape
  • Must be of type owl:Class as well as type shacl:Nodeshape

  • Must have an rdfs:subClassOf of setting:Preference or setting:ApplicationSetting

  • Must have an shacl:description that will be shown above the Setting in the UI

  • Must have a shacl:property that points to the required SHACL PropertyShape for the setting

  • Must have a setting:inGroup of an IRI in the system of type setting:PreferenceGroup or setting:ApplicationSettingGroup

Required SHACL PropertyShape
  • Must be of type shacl:PropertyShape

  • Must have an shacl:path of setting:hasDataValue

  • A shacl:datatype of one of the following values

    • xsd:boolean

    • xsd:string

    • xsd:integer

  • Must have a setting:usesFormField that has one of the following values that will affect which type of form input is shown in the UI for this preference

    • setting:ToggleInput

    • setting:TextInput

  • Must have a setting:inGroup of a valid instance of the setting:PreferenceGroup or setting:ApplicationSettingGroup class.

  • May have optional shacl:minCount and/or shacl:maxCount fields denoting the min and max number of possible values for the preference which will be enforced in the UI.

  • May have optional shacl:pattern which may have a regex that controls what values may be used and will be enforced by the UI.

Note
Support for more datatypes and form fields coming soon!
Required PreferenceGroup/ApplicationSettingGroup
  • At least one instance of setting:PreferenceGroup or setting:ApplicationSettingGroup must exist which has an rdfs:label.

    • Preference/ApplicationSetting Groups already in the system can be reused.

Note
Predefined Property Groups coming soon

The following diagram illustrates the relationship between the various preference related classes and properties:

preference diagram

Example RDF

@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix setting: <http://mobi.com/ontologies/setting#>.
@prefix : <http://mobi.com/ontologies/test#>.
@base <http://mobi.com/ontologies/test>.

:MyBooleanPreference a owl:Class, sh:NodeShape;
    rdfs:subClassOf setting:Preference;
    sh:description "What value do you want for your Boolean Preference?" ;
    sh:property :MyBooleanPreferencePropertyShape;
    setting:inGroup :MyTestPreferenceGroup .

:MyBooleanPreferencePropertyShape a sh:PropertyShape;
    sh:path setting:hasDataValue;
    sh:datatype xsd:boolean;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    setting:usesFormField setting:ToggleInput .

:MyTestPreferenceGroup a setting:PreferenceGroup ;
    rdfs:label "My Test Preference Group"@en .

Adding Custom Settings

In order to create new custom settings in the Mobi application, there are 3 steps:

  1. Create Setting RDF to model the new Setting

  2. Generate Java classes from the Setting RDF using the Mobi rdf-orm-plugin

  3. Load the Setting RDF into the Mobi Repository

Generate Java Classes from Setting RDF

  • Create an RDF file with your custom setting definition in the src/main/resources directory of a Mobi bundle. This can be any valid RDF format, such a Turtle. A list of supported RDF formats can be found here: Uploading Existing Ontologies

  • Create a pom.xml based on the following example pom in the appropriate Mobi bundle.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>Testsf</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>${project.groupId}.${project.artifactId}</name>
    <packaging>bundle</packaging>
    <parent>
        <artifactId>mobi-parent</artifactId>
        <groupId>com.mobi</groupId>
        <version>1.20.0</version>
        <relativePath></relativePath>
    </parent>
    <dependencies>
        <dependency>
            <groupId>com.mobi</groupId>
            <artifactId>rdf.orm</artifactId>
            <version>1.20.0</version>
        </dependency>
        <dependency>
            <groupId>com.mobi</groupId>
            <artifactId>setting.api</artifactId>
            <version>1.20.0</version>
        </dependency>
    </dependencies>
    <repositories>
        <repository>
            <id>inovex</id>
            <url>http://nexus.inovexcorp.com/nexus/content/repositories/public-maven-prod-group/</url>
        </repository>
    </repositories>
    <pluginRepositories>
        <pluginRepository>
            <id>inovex</id>
            <url>http://nexus.inovexcorp.com/nexus/content/repositories/public-maven-prod-group/</url>
        </pluginRepository>
    </pluginRepositories>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>3.5.1</version>
                <extensions>true</extensions>
                <configuration>
                    <obrRepository>NONE</obrRepository>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <configuration>
                    <skip>true</skip>
                </configuration>
            </plugin>
            <plugin>
                <groupId>com.mobi.orm</groupId>
                <artifactId>rdf-orm-maven-plugin</artifactId>
                <version>1.20.0</version>
                <executions>
                    <execution>
                        <id>generateOrmSources</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>generate-orm</goal>
                        </goals>
                        <inherited>false</inherited>
                        <configuration>
                            <generates>
                                <ontology>
                                    <ontologyFile>${project.basedir}/src/main/resources/myontologyfile.ttl</ontologyFile>
                                    <outputPackage>my.bundle.ontologies</outputPackage>
                                    <ontologyName>MyOntologyName</ontologyName>
                                </ontology>
                            </generates>
                            <references>
                                <ontology>
                                    <ontologyFile>jar:http://nexus.inovexcorp.com/nexus/repository/public-maven-prod-group/com/mobi/rdf.orm.ontologies/1.20.0/rdf.orm.ontologies-1.20.0.jar!shacl.ttl</ontologyFile>
                                    <outputPackage>com.mobi.ontologies.shacl</outputPackage>
                                </ontology>
                                <ontology>
                                    <ontologyFile>jar:http://nexus.inovexcorp.com/nexus/repository/public-maven-prod-group/com/mobi/setting.api/1.20.0/setting.api-1.20.0.jar!setting.ttl</ontologyFile>
                                    <outputPackage>com.mobi.setting.api.ontologies</outputPackage>
                                    <ontologyName>Setting</ontologyName>
                                </ontology>
                            </references>
                            <outputLocation>${project.basedir}/src/main/java</outputLocation>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Be sure to replace references to "My ontology" and "My bundle" with your actual ontology and bundle. Also make sure to have the <packaging>bundle</packaging> and the com.mobi.rdf.orm dependency. On your next Mobi build, interfaces, implementation classes, and factory classes will be created based on your ontology.

Load Setting RDF into Mobi Repo

In order for Setting RDF to be recognized by Mobi, it must be loaded into the http://mobi.com/setting-management graph. This can be done one of two ways. The first option is to upload the RDF via Mobi Command Line. To do this, create a trig file with a graph of http://mobi.com/setting-management that has the same contents as your setting RDF. The following is an example:

@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix sh: <http://www.w3.org/ns/shacl#>.
@prefix setting: <http://mobi.com/ontologies/preference#>.
@prefix : <http://mobi.com/ontologies/test#>.
@base <http://mobi.com/ontologies/test>.

<http://mobi.com/setting-management> {
:MyBooleanPreference a owl:Class, sh:NodeShape;
rdfs:subClassOf setting:Preference;
sh:description "What value do you want for your Boolean Preference?" ;
sh:property :MyBooleanPreferencePropertyShape;
setting:inGroup :MyTestPreferenceGroup .

    :MyBooleanPreferencePropertyShape a sh:PropertyShape;
        sh:path setting:hasDataValue;
        sh:datatype xsd:boolean;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        setting:usesFormField setting:ToggleInput .

    :MyTestPreferenceGroup a setting:PreferenceGroup ;
        rdfs:label "My Test Preference Group"@en .
}

Next, start up Mobi, and run the following command in the Mobi Shell: mobi:import -r system /path/to/my/trigfile.trig. At this point, the preference should now be present and editable in the Mobi UI.

Note
This will only work if you have already built using the rdf-orm-plugin described earlier in the documentation to generate Java classes for the setting RDF.

The second option to load your Setting RDF into the Mobi Repository is to add code to the activate method of a service in your corresponding Mobi bundle. The following methods can be used to help add code into the Mobi Repository.

  • The Models.createModel() method to turn an InputStream into a Model.

  • getRepository().getConnection().add(…​) from the CatalogConfigProvider class used to add a model to the repo. Be sure to pass the http://mobi.com/setting-management iri as the context parameter value.

Example:

settingUtilsService.updateRepoWithSettingDefinitions(MY_ONTOLOGY_INPUT_STREAM, MY_ONTOLOGY_NAME);

Using a Stored Setting

In order to use the value of a stored setting, the setting service will be used in conjunction with one or more of the ORM generated classes (classes generated in the Generate Java Classes from Setting RDF section). The following is an example of how to extract the value of a boolean preference that exists in the system:

boolean myBooleanPreferenceValue = false;
Optional<Preference> myPreferenceOptional = preferenceService.getSetting(valueFactory.createIRI(MyPreference.TYPE), user;
if (myPreferenceOptional.isPresent()) {
    MyPreference myPreference = (MyPreference) myPreferenceOptional.get();
    myBooleanPreferenceValue = myPreference.getHasDataValue().orElseThrow(() -> new IllegalStateException("Some message")).booleanValue();
}

Appendix D: Release Notes

Release Notes for Mobi 1.20

Mobi 1.20 released on October 11, 2021. This release features a beta for Ontology Visualization in the Ontology Editor, updated dct:modified dates on Records, Record filtering by keyword in the Catalog, UPDATE query CLI support, and an extension to the Settings framework to support application wide settings. It also includes updates to policy handling, such as the filtering Records based on the user’s ability to view the Record. Additionally, this release includes SPARQL query endpoint compliance, a REST interface for ETL, Basic Authentication on REST endpoints, Reflexive/Irreflexive property support, and various bug fixes and improvements.

What’s New

  • We’ve added a new beta feature for Ontology Visualization in the Ontology Editor

  • We’ve added Record filtering by keywords in the Catalog

  • We’ve introduced filtering Records based on the user’s ability to view the Record

Warning
Query System Repo policy will be reset to support updated SPARQL compliant endpoints.

Detailed Notes

General Improvements and Fixes
  • Removed deprecated OWLAPI Ontology Implementation bundle

  • Added support for UPDATE queries to the mobi:query CLI command. Has the ability to perform a dry run of the query displaying what will change

  • Created an experimental REST interface for automatically translating source files into RDF with an extracted ontology. Currently supports XML, JSON, and CSV files

  • Added Basic Authentication support to REST endpoints

  • Introduced POST support to SPARQL Query endpoint in order to be more aligned with the SPARQL query endpoint specification

  • Extended Settings framework to add support for application wide system settings

  • The User Management module in the frontend code have been converted from AngularJS to Angular

  • Added a REST endpoint to retrieve a Provenance Activity by resource ID

  • Fixed issue with system policies being evicted from the policy cache and updated API for easier loading of policies

  • Fixed issue where dangling graphs would persist across backup/restores

  • Fixed system policy to restrict permissions to do everything from anyone with the admin role to only the admin user

  • Fixed issue with Swagger docs not displaying list parameters correctly

Catalog
  • Added the ability to filter Records based on keywords on the Record

  • Updated dct:modified date of Records based on committing to a branch, adding/removing branches, editing branch metadata, and editing Record metadata

  • Fixed issue where the markdown editor help text would be cut off by side component

Ontology Editor
  • Introduced a beta feature for Ontology Visualization that will render up to 500 classes as nodes in a network graph, using the subclass relationships and object properties as edges. Uses the source Ontology and its imports

  • Added the source Ontology IRI when viewing an imported entity

  • Added owl:ReflexiveProperty and owl:IrreflexiveProperty support to properties

  • Introduced a notification to the user when Ontology state is updated on reopen of an Ontology

  • Added the ability to see the full ontology title on hover when importing an Ontology on the server

  • Updated query REST requests to stream results back to the frontend

  • Fixed issue where failed imports did not truncate

  • Fixed issue in the Search Tab where the warning message did not display for searches with more than 500 results

  • Fixed issue when viewing an Entity’s history in a large Ontology would cause server slowdowns

  • Fixed issue where a long imported Ontology IRI would extend past the confirm modal on deletion

  • Fixed issue where a long imported Ontology IRI would extend past modal on addition

Mapping Tool
  • Fixed issue where Classes from uncommitted changes on MASTER of source Ontologies appeared in Class selector

Discover
  • Updated the display of syntax error messages in the Query tab when submitting invalid SPARQL queries to be more human-readable

My Account
  • Fixed issue where updated names wouldn’t immediately reflect the change in the side panel

Administration
  • Added handling for cleaning up User State when deleting a User

Release Notes for Mobi 1.19

Mobi 1.19 released on May 7, 2021. This release includes improved performance for various actions within the Ontology editor, support for uploading compressed ontology files, and new features for an improved editing and viewing experience. It also features a new SHACL based framework for setting user preferences in the UI, fully interactive Swagger documentation for our extensive REST APIs, and numerous bug fixes and improvements.

What’s New

  • We’ve added new Swagger-based REST API documentation where API calls can be tested live

  • We’ve introduced a new framework for configuring and generating web forms for user preferences powered by SHACL

  • We’ve introduced performance improvements to the Ontology Editor to better support uploading large ontologies and viewing the change history of ontology entities

Detailed Notes

General Improvements and Fixes
  • Encryption of sensitive information stored within service configuration files is now enabled by default

  • Changes to the master password used for service configuration encryption can be changed without having to restart the server

  • Swagger REST API documentation is available on every running server (see documentation here)

  • Enabled an experimental command-line feature for automatically translating source files into RDF with an extracted ontology. Currently supports XML, JSON, and CSV files

  • Added full Java and REST API framework for storing, updating, and retrieving preferences based on SHACL shape definitions (see documentation here)

  • Downgraded the jsonld-java library to fix issue where subjects could not be defined as a type of themselves

  • Fixed issue where tags in an ontology were not included when exporting the record via the mobi:export-record command

  • Fixed issue where icons did not load when not connected to the internet

  • Fixed issue where logs viewed via the Karaf console did not display the Java Class names

Catalog
  • Added ability to copy the full IRI of a commit when clicking on the hash in the commit info overlay

  • Fixed issue where a new record "Overview" value would not immediately display after saving

  • Fixed issue where In Progress Commits were not deleted from the repository when a Record was deleted

Ontology Editor
  • Changed calculation of differences on upload changes to deterministically skolemize blank nodes to provide a more accurate difference

  • Improved the performance of the See History view for individual entities in an ontology

  • Improved the performance of caching an retrieving ontology data

  • All ontology file uploads are automatically compressed before sending to the server for improved network performance

  • Changed wording of info messages to be more helpful

  • Combined the endpoints for uploading ontology JSON-LD and an ontology file such that the data and record metadata are both provided as form data parameters

  • Added new filter to hierarchies to remove deprecated entities (i.e. items annotated with owl:deprecated)

  • Added ability to upload zipped (.zip) and gzipped (.gzip) ontology files

  • Added ability to copy the full IRI of a commit when clicking on the hash in the commit info overlay

  • Added support for rendering SKOS-XL literal form as entity names in hierarchies and relationship labels

  • Added support for owl:TransitiveProperty and owl:SymmetricProperty in Property Characteristics block

  • Added ability to change the type of individuals in an ontology even if they do not contain the owl:NamedIndividual type

  • Added support for creating qualified restrictions on a class where the class is another restriction. An example in Manchester Syntax looks like this: isConnectedTo exactly 1 (Fin or Fuselage or Wing)

  • Added display of syntax errors to the upload changes overlay

  • Added prevention of trig upload which would cause unexpected behavior

  • Fixed issue where the class hierarchy did not fully reset after a branch was created

  • Fixed issue where uploading the same ontology as changes still created an In Progress Commit

  • Fixed issue where uploading an ontology file with a non resolvable import threw an error

  • Fixed issue where See History did not update when switching branches

  • Fixed issue where a "IRI already exists" error would display for a split second when creating a new entity

Merge Requests
  • Fixed issue where long ontology names caused the second step of creating a Merge Request to horizontally scroll

Mapping Tool
  • Added ability to copy the full IRI of a commit when clicking on the hash in the commit info overlay

  • Fixed issue where full mapping definition was not returned when downloading a mapping

Discover
  • Fixed issue where blank nodes defined as known classes caused errors in the Explore tool when viewing the class list and list of instances

My Account
  • New Preferences tab that will populate with User Preference SHACL definitions from the repository (see documentation here)

  • Confirm password input in Password tab was converted to a single field with the ability to unmask the value for verification

Administration
  • Confirm password input in Reset Password overlay and Create User overlay was converted to a single field with the ability to unmask the value for verification

Release Notes for Mobi 1.18

Mobi 1.18 released on November 3, 2020. This release includes improved performance when viewing the differences of a specific commit or between two commits. It also has a brand new SPARQL query editor that supports CONSTRUCT queries as well, expressive syntax error displays on ontology uploads, support for encrypting passwords stored in service configuration files, and updates to several underlying libraries between the backend and frontend.

What’s New

  • We’ve introduced performance improvements to the Ontology Editor, Merge Requests, and Catalog to support viewing extremely large collections of differences while also displaying the calculated name for each entity instead of the local name of the IRIs

  • We’ve introduced a new SPARQL query editor in the Discover module with a better query editing experience, resizable editor and results areas, and support for CONSTRUCT SPARQL queries

  • We’ve added the ability to view syntax errors when an ontology upload fails

  • We’ve added configurable encryption of sensitive information stored within service configuration files

Detailed Notes

General Improvements and Fixes
  • Updated RDF4J version to 2.5.5

  • New support for configuring a master encryption password used to protect plaintext property values stored within service configuration files

  • The Login and Home modules in the frontend code have been converted from AngularJS to Angular

  • Improved memory usage when iterating through large sets of RDF statements in the backend

  • Fixed issue where users would see a "Problem Getting States" error when logging in

  • Added security policy for Dataset creation.

Catalog
  • Changed the display of commit differences to load incrementally and display the calculated names of each entity instead of the local name of the IRI

Ontology Editor
  • Added support for owl:versionInfo and owl:versionIRI

  • Added more intelligent identification of the RDF format of a file when uploading ontologies

  • Added display of syntax errors to the ontology upload snackbar

  • Changed the display of commit differences to load incrementally and display the calculated names of each entity instead of the local name of the IRI

  • Improved performance of the Concepts hierarchy by reworking a filter used within the Annotation, Data Property, and Object Property sections

  • Improved performance of the query to fetch entity names within the ontology leading to faster open times

  • Fixed issue where the endpoint for fetching the list of branches had no default sort value

  • Fixed issue where search text was not properly highlighting matches within the list of ontologies

  • Fixed issue where modals for creating entities within an ontology accepted invalid characters at the beginning of the IRI

  • Fixed issue where modals for editing an IRI accepted invalid characters

  • Fixed issue where editing an owl:subPropertyOf axiom would cause Concept tab to lose identification of imported concepts

  • Fixed issue where the text of the selected data or object property in the "Add Datatype Property Value" modal would extend past the edge of the modal

  • Fixed issue where changing the language of a skos:prefLabel value on a Concept Scheme or Concept would cause an "Invalid JSON-LD" error

Merge Requests
  • Changed the display of commit differences to load incrementally and display the calculated names of each entity instead of the local name of the IRI

  • Fixed issue where ontology IRIs would extend past their cards in the first step of creating a merge request on Firefox

Mapping Tool
  • Changed the display of commit differences to load incrementally

  • Fixed issue where the selected property would not load when editing an existing property mapping

Discover
  • Introduced new policy to control who can create Datasets within the system (available in the User Management module)

Discover
  • Refactored Query submodule to re-skin YASGUI for Mobi

  • Introduced CONSTRUCT query support to both frontend Query editor and backend endpoints

  • Changed JSON response for SELECT SPARQL queries to conform to the W3C specification

  • Introduced utility Java class to support converting SELECT SPARQL query results to JSON, CSV, and TSV

Release Notes for Mobi 1.17

Mobi 1.17 released on August 5, 2020. This release includes major performance improvements, allowing the ontology editor to support much larger ontologies than it could before. It also has a new "Active Entity" filter in each of the ontology tabs that will optionally filter out imported entities from the hierarchy view, configurable token duration for account logins, a limit on the amount of data shown in the Preview Block of the Ontology Editor, and now defaults to using the Repository Implementation for the Ontology API.

What’s New

  • We’ve introduced performance improvements to the Ontology Editor to support extremely large ontologies with hundreds of thousands of entities as well increasing application response speed for various actions.

  • We’ve introduced a new filter for the hierarchy in each of the ontology tabs that will optionally filter out imported entities from the hierarchy view

  • We’ve added configurable token duration for account logins

Detailed Notes

General Improvements and Fixes
  • Added scaffolding that includes new packages and files to help facilitate the switch from angularJS to angular

  • Application now defaults to using the Repository Implementation for the Ontology API

  • New support for configurable token duration for account logins

  • Added a line in the config specifying the default port for Mobi.

  • Fixed issue where the username of the logged in user was replaced with "…​" if it was to long to fit in the navbar instead of truncating.

Ontology Editor
  • New "Active Entity" filter in each of the ontology tabs that will optionally filter out imported entities from the hierarchy view

  • Refactored the Ontology Editor to store only required data for rendering in the web application rather than the entire Ontology RDF

  • New backend endpoint to retrieve full RDF for a specified entity along with it’s transitively attached blank nodes

  • Modified the behavior on click of an entity in the hierarchy so that it retrieves the entity RDF from the new GET entity endpoint.

  • Modified the GET ontology-stuff endpoint to include a map of entity IRIs in the imports closure to the values of properties used in calculating the display name

  • Removed the GET ontology calls from the frontend to improve performance, especially when opening large ontologies

  • Modified the GET commit endpoint to only retrieve commit metadata instead of full list of differences

  • Modified the GET differences endpoint to make the target commit ID optional

  • Improved performance of opening an Ontology

  • Improved performance of switching branches

  • Improved performance of retrieving ontology data after a new commit

  • Improved performance of uploading an Ontology

  • Improved the Ontology Editor module to support extremely large ontologies with hundreds of thousands of entities

  • Added a limit to the amount of data displayed in the Preview block to improve performance of large ontologies

  • Fixed issue where the ontology upload modal would stop appearing if the user accidentally clicked off of the ontology upload modal

  • Fixed issue where imported ontologies without an Ontology IRI defined showed up blank in the Imports block of the Project tab

  • Fixed issue where a long title for an ontology would expand the row on the Ontology List page too far horizontally and push the page content to the right along with it

  • Fixed issue where a modal would close if you clicked on something in the modal, held the click, and released outside of the modal

  • Fixed issue where application would run out of memory when merging large ontologies with merge conflicts

  • Fixed issue where incorrect blank nodes were generated from certain Manchester Syntax strings

Catalog
  • Fixed issue where the graph in the Catalog Commit table overlapped with the Creator column

Release Notes for Mobi 1.16

Mobi 1.16 released on October 7, 2019. This release includes a Webpack and Typescript frontend, a new implementation of the backend Ontology API, better SKOS and SKOS-XL vocabulary support, and various other performance improvements.

What’s New

  • We’ve introduced a completely new implementation of the backend Ontology API that utilizes a triplestore for caching and querying information.

  • We’ve changed the build process and language of the frontend code from Gulp and JavaScript to Webpack and TypeScript.

  • We are continuing to create a more consistent look-and-feel across the application. To that end, we’ve included several UI updates to various tools.

Detailed Notes

General Improvements and Fixes
  • Switched certain backend services to OSGi DS annotations instead of deprecated BND annotations

  • Switched backup/restore methods to copy and replace all configuration files except for server specific files

  • Switched backend library for generated JSON from net.sf to Jackson for improved performance

  • New support for milliseconds for all stored xsd:dateTime values

  • New backend support for users external to Mobi

  • New support for committing mapped data to an ontology using the mobi:transform command

  • Refactored how tokens are generated and verified in the backend

  • New policy for controlling who can run a SPARQL query against the system repository

  • Fixed issue with thread allocation in OWL API Ontology API implementation.

  • Fixed issue where passwords with special characters could not be saved.

  • Fixed issue where usernames were case sensitive.

  • Fixed issue where restoring an older version of Mobi overwrote the version of the deployed bundles on a clean start

Ontology Editor
  • New implementation of the backend Ontology API that allows for the uploading and opening of .OBO ontologies

  • New implementation of the backend Ontology API that uses a repository for caching and querying

  • New backend endpoint for retrieving the list of ontology IRIs in the imports closure

  • Improved performance of opening and switching branches of large ontologies

  • Improved performance of displaying a commit’s changes for large ontologies

  • Improved performance of calculating conflicts between commits with a large number of changes

  • Improved performance of the Changes when displaying a large number of changes

  • Improved performance of uploading a large number of changes to an ontology

  • Default the commit dropdown in the See History view to the latest commit

  • New support for creating a branch when viewing a specific commit

  • New support for displaying values of the SKOS-XL literalForm property as the display name for SKOS-XL Labels

  • Reworked Concepts and Schemes tab to show all data and object properties

  • Fixed issue where searches of large ontologies crashed the browser

  • Fixed issue where imported concepts were not displayed underneath their parent concept schemes in the Schemes tab

  • Fixed issue where a changed entity in a hierarchy would not update when a commit was made

  • Fixed broken "go to" functionality in the Object Property section of the Individuals tab

  • Fixed bug where JavaScript console errors appeared when closing an ontology with the new entity snackbar visible

Catalog
  • Fixed issue where updating record metadata would remove all other entities within the Record’s named graph (such as linked ontologies for Dataset Records)

  • Fixed issue where commits would not display for a branch of a VersionedRDFRecord when switching which branch was open

Merge Requests
  • New backend support for editing comments on a merge request

Datasets
  • New backend support for querying specific named graphs within a dataset using a Dataset Repository Connection

  • Fixed issue where a SPARQL query in the form of CONSTRUCT WHERE {…​} against a Dataset would not be rewritten properly

Administration
  • Fixed issue where the list of groups would not update after one was created

  • Fixed issue where the table of members of a group would not update after removing a member

Release Notes for Mobi 1.15

Mobi 1.15 released on March 28, 2019. This release includes a redesigned Catalog, new ontology editor usability features, and several performance and API improvements.

What’s New

  • We’ve completely reworked the Catalog to improve search and usability. We’ve added functionality for editing record metadata, including support for Markdown descriptions.

  • We’ve implemented several new features in the ontology editor to improve user experience. Users can now filter hierarchies based on search terms and view the change history of individual entities. We’ve implemented "scroll-to" functionality for quickly navigating to deeply nested terms, and provide a more complete list of language tags when annotating strings.

  • We’ve improved processing of large ontologies including better memory management and processing of complex hierarchies.

  • We are continuing to create a more consistent look-and-feel across the application. To that end, we’ve included several UI updates to various tools.

Detailed Notes

General Improvements and Fixes
  • Upgraded underlying RDF4J version to 2.4.3.

  • Upgraded underlying AngularJS version to 1.7.7.

  • Added support for SPARQL and HTTP backing repositories

  • Added documentation on how to use IRIs with URL encoded symbols in Mobi CLI.

  • Restructured web files to reduce nested directories and have a consistent naming scheme.

  • Made improvements to frontend routing so redirects to the login page are more intuitive.

  • Refactored the return structure of the users and groups REST endpoints to improve performance and correctly encode strings.

  • Fixed issues with text overflow in several views.

  • Fixed an issue where backups made with the Mobi CLI on Windows machines would not restore correctly on Unix or Linux machines.

Ontology Editor
  • New support for filtering hierarchies based on search text. Matches any annotations used for calculating the display name along with the local name.

  • New support for viewing entity change history. Displays the list of commits where an entity was changed and what the entity looked like at each change.

  • New support for opening a newly created entity via a snackbar and auto scrolling to its location in the list.

  • New support for auto scrolling to an entity in the list when clicking "Go To" from the search tab.

  • New support for a much larger list of language tags when creating annotations.

  • In the Ontology API, refactored retrieval of hierarchical relationships to use the Ontology object rather than an in-memory repository.

  • Refactored Ontology API to remove unused classes.

  • Changed the processing of hierarchical relationships in the Ontology REST and frontend for faster processing.

  • Fixed an issue where the list of entities in the search tab where not sorted.

Catalog
  • New support for opening a record in its respective module from the catalog.

  • New support for adding a Markdown description to records you have the permission to manage.

  • New support for editing the title, description, and keywords of records you have the permission to manage.

  • Developed new look and feel for the Catalog UI.

Merge Requests
  • Updated UI components to be consistent with the rest of the application.

  • Fixed an issue where Merge Requests were not properly deleted if they had reply comments.

Dataset Manager
  • Fixed issue where invalid dataset IRIs spaces were accepted.

Release Notes for Mobi 1.14

Mobi 1.14 released on January 18, 2019. This release includes several new features for ontology versioning, tools for creating better review and ingest workflows with merge requests and the mapping tool, and major performance improvements.

What’s New

  • We’ve developed new features for viewing older versions of an ontology in the ontology editor. You can now select commits from the Commits tab to open those versions in read-only mode. You can also tag any commit to create a human readable and persistent pointer to a particular commit to track multiple ontology versions.

  • We’ve implemented several performance improvements across the application to improve user experience when uploading, opening, and editing large ontologies.

  • We’ve added several new features to the Merge Request tool, including discussions, to help improve user experience for review workflows.

  • In our previous release, we added capabilities for mapping data into ontologies. In this release we’ve improved this capability by adding features for de-duplicating committed data and for calculating differences between mapping results and existing data. These features should enable workflows for versioning externally managed ontologies and vocabularies.

  • In order to ease the burden of upgrading Mobi to a new version, we’ve included Mobi command line tools for creating full system backups and restores. For instructions on upgrading from version 1.13 check out this KB Article.

  • We are continuing to create a more consistent look-and-feel across the application. To that end, we’ve included several UI updates to various tools.

Detailed Notes

General Improvements and Fixes
  • Upgraded underlying RDF4J version to 2.4.1.

  • Modified the default repository indexing strategy to include named graph indexing by default. This should increase performance considerably on larger repository sizes.

  • Added support for automatically compressing all web service responses.

  • Added support for full system backup and restore through the Mobi CLI.

  • Added support to the ORM framework for removing values of a functional property for an ORM Object.

  • Refreshed User Management modal UI design to be more consistent with the rest of the application.

  • Fixed an issue causing performance degradation when committing large sets of data to Versioned RDF Records.

Ontology Editor
  • New support for creating tags within an ontology. Tags are persistent identifiers for specific commits.

  • New support for opening specific commits and tags. These commits and tags are opened in read-only mode.

  • Added support for querying ontology data via web services and optionally including imported ontologies.

  • Added support for editing the types of owl:NamedIndividuals.

  • Added support for admins to bypass access control for ontology records.

  • Refreshed the UI display for the Search and Changes tabs to be more consistent with the rest of the application.

  • Added support for automatically updating the ontology list when a set of uploads completes.

  • Reworked the ontology import selector to enable search and a better ontology selection experience.

  • Fixed an issue where the ontology list was not properly loaded when filter queries were abnormally slow.

  • Fixed an issue where ontology record was corrupted if the client connection was lost during upload.

  • Fixed an issue preventing opening of an ontology that imports another ontology that has an identical ontology and version IRI.

  • Fixed performance issues when rendering large entity hierarchies.

  • Fixed an issue causing display of double scrollbars in some ontology editor panels.

  • Fixed an issue where circular subclass relationships prevent ontology opening.

  • Fixed an issue improperly displaying a success toast after closing access control management with no changes.

  • Fixed an issue that improperly opened a modal when ontology upload is cancelled.

Merge Requests
  • New support added for creating and deleting comments and replies in merge requests to facilitate discussions.

  • Added support for editing open merge requests.

  • Added support for removing the source branch upon merge.

Mapping Tool
  • Added support for committing mapped ontology entities to a specific branch rather than only the master branch.

  • Added support for removing data from the mapping results that already exists on the target branch during ontology mapping.

  • Added support for calculating differences between mapping results and data on the target branch during ontology mapping.

  • Refreshed modal UI design to be more consistent with the rest of the application.

  • Reworked the ontology selector to enable search and a better ontology selection experience.

  • Fixed an issue with improperly processing empty rows in a CSV file in certain situations.

  • Fixed an issue causing filename to improperly display when changing file selection in the Mapping Tool.

Catalog
  • Added better support for rendering branches in a Versioned RDF Record view.

Dataset Manager
  • Reworked the ontology selector to enable search and a better ontology selection experience.

Release Notes for Mobi 1.13

Mobi 1.13 released on October 10, 2018. This release includes a completely refreshed user experience, ontology access control, new tools for creating ontologies and vocabularies, and enhanced features for ontology review workflows.

What’s New

  • We’ve developed an entirely new look-and-feel for the Mobi application. This update includes a brand new Home Page and a redesigned Ontology Editor.

  • We released the beginnings of our policy-based access control in 1.12 and have expanded that to all ontology records. You can now control which users and groups can create, read, modify, and delete ontologies.

  • For those of you maintaining vocabularies in Excel files, you can now use the mapping tool to load those files into Mobi ontologies. Simply create a mapping based on SKOS or OWL and use the "Commit to Ontology" option.

  • Merge requests are a great way to create ontology review workflows and we’ve added new features for assigning, editing, and accepting them.

Detailed Notes

General Improvements and Fixes
  • Redesigned look and feel for the Mobi web application including new Home Page and Ontology Editor designs

  • Refactored conflict checking to provide better support for a variety of merge scenarios

  • Upgraded underlying Apache Karaf version to 4.2.0

  • Developed a new extensible framework for managing catalog records including record type specific implementations for export, delete, and create

  • Refactored file naming and storage strategy for Mobi Binary Store

  • Refactored policy services to use the Mobi Binary Store for policy storage and retrieval

  • Added support for managing access control for ontology records. Support includes user and group control for view, delete, record modification, and master branch modification.

  • Added support for configuring default location for the Mobi Binary Store

  • Added web service support for comparing differences between two commits on a Versioned RDF Record

  • Added service support for sending email notifications

  • Fixed an issue where passwords do not match error was not being properly cleared

  • Fixed an issue where merging duplicate changes from two branches sometimes resulted in statements remaining that should have been deleted

Ontology Editor
  • Properly implemented backend paging for the ontology list

  • Redesigned entity creation in the ontology editor. Creation now happens through the editor button stack instead of within each individual tab.

  • Prioritize rendering of english labels in hierarchy views

  • Added support for horizontal scrolling in hierarchy views

  • Added support for drag-and-drop upload of ontologies

  • Added web service support for querying ontology versions with SPARQL

  • Fixed an issue where adding and removing an import did not properly clean up the user’s in-progress commit

  • Fixed an issue with an incorrect error message when uploading an empty ontology

  • Fixed an issue with commit table rendering of long user names

  • Fixed an issue where uploading ontologies with missing entities on restrictions resulted in Error Entities being displayed

  • Fixed an issue where anonymous ontologies did not properly show the commit history

Merge Requests
  • Added support for assigning merge requests to users

  • Added support for accepting merge requests

  • Added support for resolving merge conflicts within a merge request. Request still available for review after conflict resolution.

Mapping Tool
  • Added support for mapping the same property to multiple columns of a tabular file

  • Added support for Annotation Properties in property mappings

  • Added support for selecting datatypes in property mappings

  • Added support for selecting languages in property mappings

  • Added support for committing mapping results to an ontology record

  • Fixed an issue when mapping ontology properties for blank cells

Release Notes for Mobi 1.12

Mobi 1.12 released on May 18, 2018. This release includes new features for collaborating and reviewing changes to ontologies as well as a new policy-based security architecture.

General Improvements and Fixes

  • Released new, extensible service layer for managing hierarchical record types within the Mobi Catalog.

  • Updated underlying RDF4J version to 2.2.4

  • Updated underlying OWLAPI version to 5.1.4

  • Fixed an issue in being unable to delete a record that had no associated provenance data.

  • Fixed an issue affecting evaluation order of commits within branching commit chains for Versioned RDF Records.

  • Fixed an issue preventing Windows machines from running the Mobi CLI client.

Security

  • Released new support for policy-based access control. New APIs and backend services support managing and evaluating security policies for controlling actions at all layers of the platform.

  • Support added for controlling which users and groups can create ontologies.

Merge Requests

  • Released new module for managing merge requests. Merge requests are long lived components that enable reviewing changes between branches of a record before performing a merge.

Ontology Editor

  • Reworked behavior of ontology editor when making changes while behind the head of a branch. New notifications and seamless merging has been implemented to make this process more intuitive.

  • Support added for viewing relevant commit list when merging two branches.

  • Support added for saving state of in-progress merge actions when switching tabs.

  • Fixed an issue where StackOverflowErrors were thrown when processing sufficiently deep class hierarchies.

  • Fixed an issue where the ontology creation page did not retain state when switching between modules.

  • Fixed an issue where exceptions during ontology upload still created a record.

  • Fixed an issue where the owl:deprecated property was not properly being recognized as a boolean value.

  • Fixed an issue where downloading an ontology while a mapping was being edited resulted in a page transition confirmation dialog.

  • Fixed an issue with languages and datatypes not being properly displayed in ontology search results.

  • Fixed an issue where failed ontology uploads were not being properly displayed in the ontology upload screen.

  • Fixed an issue where ontology search results did not include matches for all literal types.

  • Fixed an issue where the ontology commit table was showing the commit history for the entire branch even if the user was behind the head of that branch.

  • Fixed an issue with improper overflow of text in the ontology imports panel.

  • Fixed an issue allowing merge actions to be completed when a user has uncommitted changes.

  • Fixed an issue where re-uploading an ontology improperly indicates success after initially indicating failure.

Mapping Tool

  • Fixed an issue where local ontology changes affected mappings being edited at the same time.

Discover Module

  • Fixed an issue where navigating away from editing an instance would automatically save changes instead of cancelling.

Release Notes for Mobi 1.11

Mobi 1.11 released on January 24, 2017. This release features improvements to ontology version control, data management and exploration, and numerous bug fixes and performance improvements across the platform.

General Improvements and Fixes

  • Support added for configuring Repositories based on standard SPARQL endpoints.

  • Support added for copying values from RDF preview blocks.

  • Support added for using minified web resources in production builds.

  • Added link to the Mobi Help Center in the application help menu.

  • Fixed an issue causing an intermittent "Application not found" error after the server has been unexpectedly shutdown.

  • Fixed an issue causing slow load time for the Activity Log.

  • Fixed an issue where triples were not properly being tracked if the same triple was added and removed in the same commit.

Ontology Editor

  • Improved branch merging process. Merges are now initiated through a button on the button stack. Commit changes are aggregated and shown beneath the branch selector. Finally, the conflicts view has been updated to improve readability of entity change conflicts. These improvements make it easier to review changes between branches before merging.

  • Support added for tighter integration between the Individuals tab and Concepts tab when developing SKOS vocabularies.

  • Support added for uploading multiple ontologies at once through file browser or drag-and-drop.

  • Improved web-app performance when managing large lists of entities in an ontology.

  • Support added for using inferences when suggesting relationships and creating new Concepts in the Concepts Tab.

  • Fixed an issue that caused an intermittent gray screen in the ontology editor after logging out and back in.

  • Fixed an issue causing incorrect overflow of long imported ontology labels.

  • Fixed an issue where skos:narrower is not properly nesting Concepts in the Concepts tab.

  • Fixed an issue where Top Concepts are not properly nested beneath Concept Schemes.

  • Fixed an issue with dropdown item selection when entities are defined within an ontology and its imports.

  • Fixed an issue where the property creation dialog box was cut-off on low resolution displays.

  • Fixed an issue causing an error when a user’s ontology editor state suggested opening an ontology to a previously deleted branch.

  • Fixed an issue where the ontology cache was not properly updated after deleting the source branch during a merge.

  • Fixed an issue where Concepts could be related to themselves.

  • Fixed an issue allowing users to add duplicate values for the same property to an ontology entity.

  • Fixed an issue with class folders being added to the individuals tab incorrectly when creating subclass axioms.

Dataset Manager

  • Support added for uploading RDF data files to a dataset through the Dataset Manager UI.

Discover Module

  • Support added for using inferences when suggesting link targets while editing instances in the Explore tool.

Release Notes for Mobi 1.10

Mobi 1.10 released on November 27, 2017. This release features improvements to vocabulary editing, new instance management tools, and numerous bug fixes across the platform.

General Improvements and Fixes

  • Incorporated new automated web testing framework for testing web UI components.

  • Added many new backend services and features to support future distributed catalog capabilities.

  • Added many new backend services and features to support future ETL workflow capabilities.

  • Fixed an issue with ORM API causing ConcurrentModificationExceptions when editing functional properties with more than value assigned

Ontology Editor

  • Completed a major overhaul of the vocabulary editor. The vocabulary editor features have now been rolled into the ontology editor and dynamically become available upon declaration or import of SKOS classes. Additionally, various display improvements have been made for the Schemes and Concepts views.

  • Fixed an issue causing dropdowns with hundreds of items or more to become unresponsive. Dropdowns with large numbers of items now show a subset of items and allow searching.

  • Fixed a variety of issues causing performance problems when loading large ontologies

  • Fixed a variety of issues causing performance problems when loading ontologies with large import closures

  • Fixed an issue where imported classes retrieved via REST endpoint contained some incorrect values

  • Fixed an issue with the preview block not updating when switching ontology tabs

  • Fixed an issue with the preview block not correctly grouping triples by subject

  • Fixed an issue with missing ontology properties from the edit ontology properties block

  • Fixed an issue causing display problems when switching between web modules

  • Fixed an issue with poor display of long branch names in the branch select box

  • Fixed an issue with inconsistent use of inferred ontology entities

Mapping Tool

  • Mapping components (class and property mappings) now have associated titles so that they are more easily identified.

  • Support added for creating multiple class mappings of the same type. This allows mapping different properties to the same class type.

Dataset Manager

  • Added missing form label for ontologies list

  • Fixed an issue where linked ontologies were not correctly retrieved

  • Fixed an issue causing performance problems when importing large data files into a dataset

Discover Module

  • Support added for searching with property paths in the Search tool

  • Support added for creating new instances of classes from the class page in the Explore tool

  • Support added for showing labels of linked instances in the Explore tool

  • Support added for showing labels of available instances for linking in the Explore tool

  • Support added for deleting instances in the Explore tool

  • Fixed an issue when customizing IRIs of new instances in the Explore tool

  • Fixed an issue where editing an instance property did not correctly add datatypes in the Explore tool

Release Notes for Mobi 1.9

Mobi 1.9 released on October 20, 2017. This release features new provenance, search, and visualization features as well as numerous bug fixes across the platform.

General Improvements and Fixes

  • New provenance features collect information about catalog record creation and deletion events, and provide an Activity Log in the web UI. This data collection joins existing capabilities tracking record modification to provide a detailed picture about how resources within Mobi are being created, used, and destroyed. Future improvements will provide more detailed visualization tools and collection capabilities to track all resources within Mobi at a detailed level.

  • Updated the project source code to reflect the rebranding from MatOnto to Mobi

  • New backend service capabilities added to manage ETL workflows. Future improvements will bring UI tools for creating and managing workflows that include ingest from relational database, XML, and directory-based data sources.

  • New backend service capabilities added for managing files and file systems

  • Fixed an issue where dates were not properly persisted with the xsd:dateTime datatype

Ontology Editor

  • Improvements made in how the ontology editor handles blank node data within the browser

  • Fixed an issue impeding the loading of ontologies with a large number of direct or indirect imports

  • Fixed an issue that caused the new ontology tab to disappear intermittently

  • Fixed an issue where commit change labels were not being properly rendered in some cases

  • Fixed an issue where users were not always able to pull the latest changes from the server when behind the HEAD of a branch

  • Fixed an issue where ontology entities were not being properly expanded and collapsed in entity trees

  • Fixed an issue where new Concepts were not being dynamically nested based on SKOS relationships

  • Fixed an issue where editing Concepts in the Scheme tab provided the wrong list of relationships

  • Fixed an issue where deleted Concepts could not be made again

  • Fixed an issue where searching on a newly created vocabulary resulted in many missing entities

  • Fixed an issue where clicking a Concept link in the ontology editor did not correctly navigate to the Individuals tab

Mapping Tool

  • Fixed an issue where updating the ontology version was not properly saved to the mapping record

  • Fixed an issue where mappings could not be run from the edit page unless changes were made

  • Fixed an issue where dropdown boxes were not correctly populated after modifying the mapping ontology

Dataset Manager

  • Fixed an issue where pagination in dataset creation overlay did not work properly

  • Fixed an issue with incorrect info messages on the Dataset Manager UI module

  • Fixed an issue where selected ontologies were improperly displayed when editing a dataset

Catalog

  • Fixed an issue where catalog sorting options contained duplicate values

  • Fixed an issue where the catalog module broke when a selected record was deleted

Analytic Module

  • New module added to support development of analytics and visualizations in the Mobi web application. This initial release includes features for developing dynamic tables based on user-managed ontologies. Future improvements will bring charting, dashboard, and reporting capabilities.

Federation Services

  • Renamed services and data to reflect new federation naming scheme

  • Fixed an issue where modifying service configurations did not immediately reconfigure federation services

  • Fixed an issue where platform services were not able to start correctly if MAC address could not be determined

CLI

  • Support added for submitting SPARQL queries via the Mobi command-line client

Release Notes for Mobi 1.8

Mobi 1.8 released on August 27, 2017. This release features the official rebranding of the MatOnto platform as Mobi. Key features include improved support for OWL Restrictions, new support for local ontology imports, new features for instance data editing and creation, and a new "Search" tool within the Discover Module.

General Improvements and Fixes

  • New support added for importing and exporting data from the Mobi console. Support includes importing data into an existing dataset and exporting dataset data and catalog records.

  • Support added to the Mobi console for exporting named graphs from a repository

  • Fixed several build errors related to running unit tests in Windows environments

  • Fixed an issue where commit fragments were not being properly removed when a Versioned RDF Record was deleted

Ontology Editor

  • Improved support for rendering OWL Restrictions including owl:oneOf and cardinalities

  • Support added for owl:inverseOf and owl:AsymmetricProperty

  • Support added for adding ontology imports from the local server

  • Support added for identifying indirect ontology imports in the imports closure

  • Support added for identifying missing ontology imports

  • Support added for creating a commit by uploading a modified version of an ontology (enabling external ontology modification)

  • Support added for applying owl:deprecated to ontology classes

  • Refactored the vocabulary editor to split schemes and concepts into their own editor tabs

  • Fixed an issue where SKOS relationships were not available within the vocabulary editor

  • Fixed an issue where entity usages were not being properly displayed within the ontology editor

  • Fixed an issue where IRI existence validation was improperly reporting errors

  • Fixed an issue where especially long RDF lists within an ontology would cause stack overflow errors

Mapping Tool

  • Support added for properly respecting owl:deprecated on ontology classes

  • Support added for versioning mapping records

  • Support added for processing formulas within Excel files

  • Fixed an issue where the mapping name was unmodifiable within the mapping editor

Discover Module

  • New "Search" tool added to the Discover Module. "Search" tool supports keyword, type, and data property search within a dataset.

  • Support added to the "Explore" tool for viewing, editing, and creating instance data

  • Support added to the "Explore" tool for applying properties to existing data through the use of reification

  • Support added to the "Explore" tool for respecting required properties when creating and editing instance data

Datasets

  • Support added for editing datasets from the Datasets Module

Federation Services

  • New features added for creating federations of Mobi nodes as a first step toward enabling distributed collaboration

API Updates

  • Improved versioning services to properly version quads in addition to triples

  • Support added to properly edit blank node resources by skolemizing blank nodes between the triplestore and the web application

  • Fixed an issue for properly handling null values in DatasetConnection.remove(s, p, o, c)

Known Issues

  • In the Vocabulary Editor, adding hierarchical relationships (e.g. broader and narrower) to concepts does not properly nest them in the concept tree until the vocabulary is reopened.

  • There is a typo in the etc/branding-ssh.properties that causes the Karaf client to hang. This will be fixed in release 1.9.

Release Notes for MatOnto 1.7

MatOnto 1.7 released on June 5, 2017. This release includes many bug fixes and performance improvements for the ontology editor and mapping tool as well as a new Discover Module for exploring datasets.

General Improvements and Fixes

  • Fixed an issue where retrieving users with email addresses in the User Management tool caused an Internal Server Error

Discover Module

  • Replaced the existing SPARQL Editor Module with the new Discover Module

  • Added "Explore" tool to the Discover Module to enable quick exploration of datasets. This new tool will show the user what types of data are stored in the dataset and provide data samples. Future updates to the tool will allow users to explore and modify instance properties, create new instances, and delete existing instances.

  • Fixed an issue where comments were not allowed in SPARQL queries against datasets

Ontology Editor

  • Improved parsing of entity local names with acronyms used for display values (e.g. http://example.com/ontology#ABCEntity → "ABC Entity")

  • Support added for directly adding a subClassOf or subPropertyOf axiom when creating a new class or property

  • Fixed an issue allowing users to create multiple ontology entities with the same IRI

  • Fixed an issue where some commit data was not removed when deleting an ontology

  • Fixed an issue where the individuals tree was not updated correctly when the ontology class tree changed

  • Fixed an issue where a user could not assign a ConceptScheme when creating a new Concept

Mapping Tool

  • Support added for applying datatypes to literals based on the selected ontology properties

  • Support added for using basic rdfs and dcterms properties in a mapping

  • Support added for mapping multiple properties to the same source data column

  • Fixed an issue where modifying an ontology that was also being used in an active mapping broke the mapping ontology selector

  • Fixed an issue where the Mapping Tool was not properly including ontology updates when selecting the latest ontology version

API Updates

  • Refactored public Catalog API to include path validation when performing operations such as creating commits and merging branches

  • Significant performance improvements when retrieving commit data from the Catalog REST endpoints. Dramatically reduces load times for large ontologies.

  • Support added for creating commits from external data. This capability will enable future support for applying commits from files and merging records.

  • Various improvements to memory management when opening ontologies. Dramatically reduces memory usage when opening large ontologies.

Known Issues

  • In the Vocabulary Editor, SKOS relationship properties are missing from the property selector when using subclasses of skos:Concept. This issue will be fixed in Release 1.8.

  • Intermittent build errors occur in the Catalog REST bundle due to some shared resources. This issue will be fixed in Release 1.8.

  • The Mapping improperly includes InProgressCommit data when loading ontology properties and classes. This issue will be fixed in Release 1.8.

  • SPARQL queries against datasets that include SPARQL keywords as variable names cause a parsing exception. This issue will be fixed in a future release.

  • Classes that subclass each other should result in an equivalence relationship. This is not properly rendered in the Ontology Editor and produces errors. This issue will be fixed in a future release.

  • The Mapping Tool does not correctly handle mapping object properties with no range. The tool allows you to select the object property, but produces an error when trying to determine the target class type. This issue will be fixed in a future release.

  • The Mapping Tool does not correctly save mappings that have had their name changed. This issue will be fixed in Release 1.8.

Release Notes for MatOnto 1.6

MatOnto 1.6 released on May 8, 2017. This release includes many bug fixes and performance improvements for the ontology editor as well as various improvements to the mapping tool and user management page.

General Improvements and Fixes

  • Google groups link added to help menu

  • User management user list now displays full name if available

  • Access to user management page restricted to admins only

  • Support added to list a user’s groups in the profile page

  • Fixed an issue where targeted spinner would lock up the application in several places

  • Fixed an issue where admin tags were not displayed correctly in the user list of the user management page

Ontology Editor

  • Support added for a click-to-copy feature for ontology entity IRIs

  • Support added to render complex class expressions and restrictions using Manchester Syntax in Axioms panel

  • Support added to render complex class expressions and restrictions using Manchester Syntax in Search panel

  • Support added to include imported entities in class, property, and individual list

  • Support added to roll-up large number of entity usages into a link to increase performance

  • Support added to render individuals of subtypes of skos:Concept in the concept hierarchy of the vocabulary editor

  • Support added to implement virtual scrolling on all entity lists, dramatically improving performance for large ontologies

  • Support added to render individuals as a tree based on their class hierarchy

  • Support added to implement ontology caching, dramatically improving performance when loading and editing large ontologies

  • Support added to immediately render icons associated with ranges of properties in the property hierarchy and overview tab

  • Fixed an issue where deleting an ontology did not delete the underlying revision data

  • Fixed an issue where creating and deleting classes sometimes resulted in incomplete class data remaining in the ontology

  • Fixed an issue where import statements were not correctly displayed in the changes tab

  • Fixed an issue where adding and deleting multiple imports did not correctly delete the specified import

  • Fixed an issue where deleting individuals did not always remove them from the individuals list

  • Fixed an issue where axiom values were not displayed properly in dropdowns

  • Fixed an issue where the String datatype was being removed from an individual’s data property when committing

  • Fixed an issue where modification badges would not be removed after performing a commit

  • Fixed an issue where the project tab would not update on branch change

Mapping Tool

  • Support added for editing full IRI in IRI templates

  • Support added to ignore property mappings for empty cells when mapping in delimited and excel files

  • Support added to ignore class mappings for empty rows when mapping in delimited and excel files

  • Support added to trim white space from values inserted into IRI templates

  • Support added to show a preview of mapped data in the property mappings list

  • Fixed an issue where the edit and delete buttons for property mappings would not work in Firefox

  • Fixed an issue where the user could not create a new class mapping when editing a previously created mapping resource

  • Fixed an issue where previewing mapping results intermittently did not display correctly

  • Fixed an issue where using an ontology with the same class defined in the ontology and one of its imports resulted in an empty dropdown when adding a class mapping

  • Fixed an issue where page leave confirmation message was displayed when downloading a mapped data

Datasets

  • Support added to associate datasets with ontologies that describe the data within them

Release Notes for MatOnto 1.5

MatOnto 1.5 released on April 4, 2017. This release contains the first features for MatOnto datasets and many improvements to the Ontology Editor user experience.

Datasets

A new feature in 1.5, MatOnto Datasets provide collections of RDF graphs that can be managed and queried independently of other data stored within MatOnto repositories.

  • Datasets consist of a collection of RDF graphs that act as default named graphs or named graphs per the SPARQL 1.1 recommendation for RDF Datasets.

  • Java and REST services are now available for creating, managing, and querying datasets. The services ensure all operations on the Dataset are isolated to that specific set of RDF graphs.

  • A new UI module provides capabilities for creating and managing datasets.

Ontology Editor

  • Support added for displaying and editing language tags on string literals.

  • Support added for displaying and selecting if a property is functional.

  • Support added for importing ontologies from a URL. When adding an import, the editor will confirm the URL is resolvable and reload the ontology with the imported entities.

  • The Commits tab now renders a commit history chain with links to view the commit changes.

  • Added support for loading spinners over specific UI components when waiting on asynchronous calls to load data. This can be seen in the entity usages block.

  • All entity hierarchy trees are now sorted alphabetically.

  • When rendering labels for entities in hierarchy trees or detail blocks, a "pretty-print" label is displayed using the rdfs:label, dc:title, or the local name of the IRI in that order.

  • The editor now supports passive saving. When an ontology entity is modified, the ontology is automatically saved.

  • Modified entities are now highlighted using a modification badge and bold formatting.

  • Support added for creating custom Annotation Properties.

  • Each entity now displays a list of its rdf:type.

Mapping Tool

  • Integration with MatOnto Datasets provides the capability to upload transformed data to a Dataset.

  • Removed the idea of a "Base Class" from the mapping configuration. You now select from a list of classes in an order to create class mappings.

SPARQL Query Editor

  • Integration with MatOnto Datasets provides the capability to limit a query operation to a particular Dataset.

  • Malformed queries now properly display a message describing the parsing error.

  • New feature allows user to download the results of a SPARQL tuple query in CSV, TSV, or Excel format.

General Improvements and Fixes

  • User management tool now allows an admin to reset a user’s password.

Known Issues

  • Double-clicking an entity in the Ontology Editor search results wil not remove the loading spinner. Reload the browser tab to clear this issue.