Mobi Logo

Mobi is a decentralized, federated, and distributed graph data 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

Mobi is available as a preconfigured Docker image on Docker Hub: https://hub.docker.com/r/inovexis/mobi/

The easiest way to get started with Mobi on Docker is to download and install Docker and Docker Toolbox. Docker Toolbox provides Kitematic, a simple GUI for managing docker containers.

Kitematic Main Screen
Figure 1. Kitematic Main Screen

You can find the Mobi image by searching for our organization "inovexis" in the search bar.

Kitematic Mobi Image
Figure 2. Kitematic Mobi Image

Once you’ve created a container with the Mobi Docker image, you may configure the web port from the random default value to the more traditional 8443.

Kitematic Port Configuration
Figure 3. Kitematic Port Configuration

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.

Kitematic Mobi Container
Figure 4. Kitematic Mobi Container

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 5. 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 6. 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 7. 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. 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 8. 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 9. 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 10. 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 11. 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 12. Ontology upload results.

Supported ontology file types are .owl, .ttl, .xml, .jsonld, .owx, .trig, .json, .n3, .nq, .nt, and .rdf. 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.

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 13. 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 14. 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. 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 15. 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. 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 16. Ontology Editor Classes Tab

The left side of the tab contains a hierarchal 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. 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 17. Ontology Editor Properties Tab

The left side of the tab contains a hierarchal 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. 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.

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. 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 hierarchal 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. 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 hierarchal 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. 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
Figure 25. Check Out Select box
check out select commit
Figure 26. Check Out Select box with commit
check out tag
Figure 27. 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 28. 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 29. Pull in latest changes message
behind head
Figure 30. 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 31. 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 32. 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 33. 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 34. 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 35. Entity History view

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 36. 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 37. 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 38. 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 39. 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 40. Create Entity button
new snackbar
Figure 41. 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 42. 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 43. Add commit overlay

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

merge branch button
Figure 44. 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 45. 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 46. 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 47. 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 48. Upload Changes button

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 49. 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 50. 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 51. 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 52. 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 53. 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 54. 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 55. 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 56. 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 57. 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 58. 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 59. 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 60. Create Property Mapping Overlay for a Data/Annotation Property
create property mapping overlay object
Figure 61. Create Property Mapping Overlay for an Object Property
language selection
Figure 62. 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 63. 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 64. File Upload Page for Editing a Mapping
file upload edit missing columns
Figure 65. 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 66. File Upload Page for Running a Mapping
file upload run missing columns
Figure 67. 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 68. 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 69. 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 70. 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 71. 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 72. 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 73. 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 74. 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 75. 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 76. 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 77. 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 78. 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 79. Add New Property Filter overlay with Property select
search add property filter overlay 2
Figure 80. Add New Property Filter overlay with Object Property selected
search add property filter overlay 3
Figure 81. 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.

query full view
Figure 82. Query tab

There are two main blocks of the Query tab. The top block contains an editor to enter a SPARQL query, several configuration fields, and a Submit button. The Prefixes field contains a list of standard prefixes for commonly used ontologies. When selected, a prefix can be used within the text area when creating a SPARQL query. Selected prefixes are not used in the results display. 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 block with the results.

The bottom block contains the paginated results of your last SPARQL query against the Mobi repository in a table format. The headers of the table are the variables specified in the SPARQL query. Each row of the table represents a single RDF triple. To download the results of the latest query in a tabular file, click on the download button in the lower right and fill out the form in the overlay.

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 83. My Account link

The My Account page contains three 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 84. 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 85. 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 86. Password Tab

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 87. 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 88. 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 89. 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 90. 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 91. 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 92. 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 1. 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 2. 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 3. 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 4. 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.

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

6+

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

Google Chrome

76+

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.

OWL API Versus RepositoryCache

In 1.16, we introduced a repository based ontology manager that gives users the option to utilize a triplestore for managing ontology data instead of the original OWLAPI implementation which performed all processing in-memory. This allows for the reduction of allocated resources as ontologies get larger and more efficient processing when retrieving information from an ontology. The steps below outline how to switch implementations and revert back if need be.

Set OntologyCache to Use a Repository

By default, the cache of ontologies does not use a repository implementation. To enable this, the configuration must be modified include an ID of a repository in com.mobi.ontology.utils.cache.OntologyCacheConfiguration.cfg

com.mobi.ontology.utils.cache.OntologycacheConfiguration.cfg

id = ontologyCache

numEntries = 10

repoId = ontologyCache

Warning
If the repoId property is added to the configuration file after changing other configuration files, changed bundles should be refreshed.

Add/Remove Configuration Files

By default, Mobi utilizes the OWLAPI Ontology API implementation to represent Ontologies. In order to switch to the Repository implementation, Karaf configuration files must be altered.

Note
the commands below assume a Linux/Unix machine is being utilized

First, delete the old configuration file using the commands below:

cd ${MOBI_HOME}/etc
rm com.mobi.ontology.impl.owlapi.OntologyManager.cfg

Then create a configuration file for the Repository Cache implementation:

touch com.mobi.ontology.impl.repository.OntologyManager.cfg

Additionally, create a configuration file for the CacheRepositoryCleanup job:

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

And add the following to the file:

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

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

If you wish to revert back to the OWLAPI implementation, delete the two files created above and restore com.mobi.ontology.impl.owlapi.OntologyManager.cfg

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.

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: Release Notes

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.

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

  • 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 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.