Link Search Menu Expand Document
Start for Free

Stardog Designer

This chapter discusses Stardog Designer - a no-code, visual tool for creating and maintaining your Knowledge Graph.

Page Contents
  1. Overview
  2. Projects
    1. Project settings
  3. Data Modeling
    1. List and Graph Views
    2. Define Inference Rules
    3. Managing Multiple Data Models
      1. Defining a New Data Model
      2. Using an Existing Data Model
  4. Mapping Project Resources
    1. CSV Upload Options
    2. Virtual Graph Options
    3. Mapping Capabilities
      1. Mapping multiple fields to an attribute
      2. Mapping suggestions
      3. Primary identifiers
      4. Inherited relationships and attributes
  5. Publishing
  6. Created Data Model Definition
  7. Additional Notes
  8. Getting Support
  9. Learning More

Overview

Stardog Designer is the visual environment for creating and maintaining your Knowledge Graph data model and data. For the best experience in Stardog Designer, use Stardog version 7.9.0 or above.

Projects

Stardog Designer uses projects to help users organize their data modeling and mapping efforts. Projects may use existing data models in a Stardog database to jump-start the data modeling process.

Work completed in Designer can be exported to your local filesystem or published directly to a Stardog endpoint. A file with the extension .stardogdesigner is included in the export. To import a project, upload the file with the extension .stardogdesigner.

Projects

Project settings

  • Project name
    • The project name sets the namespace of a project and is used to identify the project throughout Designer.
    • The project name can be updated, and the project namespace will be automatically updated to match. Changing the project namespace will not change any existing model concepts or the namespace of model concepts from imported data models. All new model concepts will use the updated project namespace.
  • Advanced project details
    • Set a custom instance data namespace. All projects have a default instance data namespace of tag:stardog:designer:[PROJECT NAME]:data:, where [PROJECT NAME] is the name of the project. This namespace will be used for all instance data mapped through Designer unless a custom IRI is defined.
    • Infer class types based on shared properties. By default, Designer does not infer class types based on shared properties. When enabled, a class can be inferred to also be another class that shares the same properties. For example, if ClassA shares the same properties as ClassB, instances of ClassA can be inferred to also be of type ClassB. Setting to Custom per property allows changing this option at the relationship and attribute level.
    • Set a custom data model namespace. All projects have a default data model namespace of tag:stardog:designer:[PROJECT NAME]:model:, where [PROJECT NAME] is the name of the project. This namespace will be used for all model concepts defined through Designer unless a custom IRI is defined. When managing multiple data models, all model namespaces are editable.

Projects

Data Modeling

The data models created in Designer use OWL and RDFS standards to ensure data models are compatible with open source semantic tools.

The toolbar can be used to create classes and add new relationships. When the new object is selected, a right-hand panel opens with additional editing capabilities. For classes, this includes defining parent and child classes, relationships, and attributes.

When managing multiple data models, each model concept may be assigned to one or more data models.

Relationships are edited on the canvas by hovering over either end of the relationship. If the relationship does not have a source or a target, the relationship can be clicked and dragged to an existing class. If the relationship already has a source or target, the source or target can be unlinked from the source or target by hovering over the end of the relationship and selecting the unlink icon. Relationships, like classes, can also be edited in the right-hand panel.

Classes and relationships can be modified in their detail drawers by double-clicking a class or relationship. The detail drawer may also be opened by right-clicking the class or relationship and selecting Edit. Attributes can be modified by clicking on an attribute from any class detail drawer for which the attribute is associated with. You may change the IRI of any model concept by hovering over the concept’s name, selecting Show IRI, and editing the IRI displayed. IRIs of concepts created in a project begin with [Project namespace], which represents the namespace defined in the Project Settings.

Classes are automatically assigned a Stardog color which will be used in the Designer canvas and in Explorer. The color of a class may be changed by opening the class detail drawer and clicking on the colored circle to the right of the class name.

Class details

List and Graph Views

Designer supports viewing your Data Model in List or Graph view. The Graph view is selected by default.

The List view provides tabs to search, edit, and review Classes, Relationships, and Attributes. Clicking on any Class, Relationship, or Attribute will open the detail drawer to edit or review more details about the model concept.

When multiple data models are managed in a Designer project, each data model will be shown as a column and each model concept will be marked as present in a model (filled circle) or not present (outlined circle). When a model is hidden, the model concept will be shown in a lighter color.

List view

Define Inference Rules

Inference rules can be defined to capture business and domain logic in your data model. To add and edit inference rules associated with your data model, click the Rules option in the toolbar. Inference rules follow an If… Then… format to add attributes, connect instances through relationships, and classify instances as additional class types. You can learn more about the Stardog Inference Engine here.

Managing Multiple Data Models

Multiple data models may be managed in Designer. All Designer projects have a default data model created when a project is created. Designer requires at least data model to be defined at all times. More data models may be added to your project by clicking the plus icon next to Data Models on the left hand panel. You may either define a new data model or import an existing data model.

Using the three dot menu for each Data Model, you can:

  • Use for new concepts
    • All new model concepts and rules will be added to this data model
  • Hidden/Shown
    • Please note, data models used for new concepts cannot be hidden
  • Rename
    • Rename the data model
  • Manage settings
    • Edit the namespace for the data model
  • Deleted
    • Only model concepts defined solely in the deleted data model will be deleted. If a model concept is used in multiple data models, the model concept will not be deleted.

Defining a New Data Model

To define a new data model, you must specify a Data Model name. A Data Model namespace will be suggested based on your data model name and may be edited before creation or afterwards in the Settings panel.

Using an Existing Data Model

Existing data models can be imported from Stardog endpoints. To do so, simply select the plus icon next to Data Models in the left-hand panel and follow the screens to confirm your endpoint connection and data model selection.

Mapping Project Resources

Designer facilitates mapping new data sources to Stardog. Designer currently supports mapping data from CSVs and relational database data sources.

CSV Upload Options

  • Local CSV files can be uploaded as project resources. Only CSV files below 2 Mb will be stored as part of a project; as a result, CSV files above 2 Mb must be uploaded again when publishing.
  • When uploading a CSV file, the resource name, separator character, quote character, and escape character can be customized.
  • If a CSV file has duplicate columns in the first row, the first row of the file may not be used to indicate column headers.

Virtual Graph Options

  • Virtual graphs can be created for any data source type for which a driver is installed on your Knowledge Graph endpoint.
    • To define a new data source when adding a virtual graph, select the data source type, and then the option to Create new Data Source. You can see an example configuration (using the example data source properties found here) below:
      • add MySQL RDS
    • Please note that new data sources will be created for your Knowledge Graph endpoint when added as project resources.
    • To publish your virtual graph, the data source used to create the project resource must be defined for the Knowledge Graph endpoint you are publishing to.
  • When creating a virtual graph, the resource name, scope, and properties (such as SQL quoting convention) can be customized.
    • The scope can be a single table from the selected data source connection or a custom SQL query.
      • Note: when a reserved SQL keyword is used as a schema or table name, you must write a custom SQL query with quotes around the reserved keyword to define a virtual graph. For example, if the virtual graph you want to define is from a schema named DEFAULT and a table named TABLE, a custom query would be required when defining the virtual graph. An example query for this schema and table pair is:
        SELECT * FROM 'DEFAULT'.`TABLE`
    • The project resource name will be used as part of the virtual graph name when published.
  • Only relational database data sources are supported at this time. Please see Supported Data Sources for the complete list.

Mapping Capabilities

Designer includes a data model view and a mapping view. The data model view is a canvas for creating, importing, and viewing model concepts and project resources. The mapping view is a structured interface for mapping project resources to model concepts.

Project resources are mapped to classes by adding a link from the toolbar when the project resource is selected. Once dragged to a class, the mapping link creates a mapping. When a mapping is started a class will show an outline mapping icon.

Incomplete mapping

For a mapping to be completed, a primary identifier is required and is used to identify unique class instances. The mapping icon will become filled when a primary identifier has been set in order to show that the mapping is complete.

Complete mapping

Mapping to relationships and attributes is part of the class mapping pages. When mapping a relationship, you must first select the source or target class type and then define the primary identifier for the source or target.

If a project resource is mapped to both a source and target for a relationship, the relationship will be automatically mapped for the user based on the defined source and target primary identifiers.

Mapping multiple fields to an attribute

If you wish to map multiple project resource fields to the same attribute, you can select Duplicate mapping from the three dot menu in the row of the attribute. The duplicated attribute enables you to map an additional field from your resource to that attribute. Mapping to a duplicated attribute can be done any number of times.

Mapping suggestions

Designer also provides a suggestion service to suggest mappings between a project resource and a class. To approve a suggestion, click on the green check icon. To reject a suggestion, click on the red cross icon. All mappings, including those you have approved from the suggestion service, may be modified by clicking on the field dropdown and clearing the selection (removing the mapping to the attribute) or selecting a new field (replacing the field mapped to the attribute).

Primary identifiers

Designer enables multi-field and static text input to be used when setting a primary identifier. The primary identifier must include at least one input field from the mapped project resource. Field inputs are shown in dark grey, and static text inputs are shown in a light gray. Once an input field from the mapped project resource is selected, a preview of the primary identifier is shown.

Inherited relationships and attributes

If your data model contains parent and child classes, there might be scenarios where you want to map to the parent relationship and attributes when creating an instance of the child class. For example, let’s imagine you have a data model containing a class Person with a single attribute for First Name and a subclass Employee. In a Knowledge Graph data model, the attribute First Name is inherited by the Employee class because Employee is a subclass of Person. This parent-to-child inheritance applies for all attributes (e.g., if Person also had an attribute for Last Name) and across multiple parent-child associations (e.g., Manager subclass to Employee subclass to Person, Manager also inherits the attributes of Person).

Designer supports mapping to inherited relationships and attributes. All inherited relationships and attributes are identified by a reference below the relationship’s or attribute’s name, which includes the root parent class(es) from which the relationship or attribute was inherited. To limit the displayed relationships or attributes for a mapping, use the filter icon next to Edit Attributes.

Publishing

Designer supports publishing projects in two ways: to a zipped folder or directly to a Stardog endpoint. The zipped folder contains all the inputs needed to publish the data model and mappings to Stardog. The contents can be used in version control systems to document data model and mapping changes.

When publishing to a zipped folder, the contents will include:

  • A zipped folder with the name of the project.
  • A turtle (.ttl) document containing the data model.
  • A folder for each project resource with the name of the project resource. The folder will contain:
    • A Stardog Mapping Syntax 2 (SMS2) mapping file.
    • A properties file.
    • If the project resource was a CSV, the original CSV renamed to the project resource name.
  • A file with an extension of .stardogdesigner.
    • The file may be loaded into any Designer environment to re-create the project.

When publishing directly to a Stardog endpoint, there are four steps.

  1. Endpoint and Database Selection
    • Set the endpoint and database to which you want your project published.
  2. Data Properties
    • Enable Voicebox, if Stardog license allows.
    • Publish the namespaces of your project.
    • Publish sensitive property groups, if used.
  3. Data Model Configuration
    • If your project only contains one data model:
      • Specify if you want to create a new data model or replace an existing data model.
      • When creating a new data model, you may choose to modify the data model name or the schema graph a data model will be published to.
    • If your project contains more than one data model:
      • Specify if you want to publish data models as multiple data models or consolidate to a single model.
      • If publishing as multiple data models:
        • For each data model:
          • Specify if you want to create a new data model or replace an existing data model.
          • When creating a new data model, you may choose to modify the data model name or the schema graph a data model will be published
        • Option to add a Data Model Combo. Data Model Combos allows end users to reference one or more data models using a single identifier.
  4. Mappings Configuration
    • Only shown if there are valid mappings in a project.
    • Choose to create a new graph or replace an existing graph for each mapped project resource.
    • CSV sources are materialized to the database in the specified named graph.
    • All non-CSV project resources are published as virtual graphs, and the virtual graphs are published for the chosen database on the selected endpoint.

Created Data Model Definition

  • Classes are defined as: http://www.w3.org/2002/07/owl#Class.

  • Relationships are defined as: http://www.w3.org/2002/07/owl#ObjectProperty.
    • Relationship domains (e.g., sources), by default, are defined by https://schema.org/domainIncludes. If the project setting Infer class types based on shared properties is Yes or Custom per property and this option is set to Yes for a relationship, the relationship domain will be defined by http://www.w3.org/2000/01/rdf-schema#domain.
    • Relationship ranges (e.g., targets), by default, are defined by https://schema.org/rangeIncludes. If the project setting Infer class types based on shared properties is Yes or Custom per property and this option is set to Yes for a relationship, relationship range will be defined by http://www.w3.org/2000/01/rdf-schema#range.
  • Attributes are defined as: http://www.w3.org/2002/07/owl#DatatypeProperty.
    • Attribute domains, by default, are defined by https://schema.org/domainIncludes. If the project setting Infer class types based on shared properties is Yes or Custom per property and this option is set to Yes for an attribute, the attribute domain will be defined by http://www.w3.org/2000/01/rdf-schema#domain.
    • Attribute ranges, by default, are defined by https://schema.org/rangeIncludes. If the project setting Infer class types based on shared properties is Yes or Custom per property and this option is set to Yes for an attribute, the attribute range will be defined by http://www.w3.org/2000/01/rdf-schema#range.

  • Model concept labels are defined using: http://www.w3.org/2000/01/rdf-schema#label.

  • Model concept descriptions are defined using: http://www.w3.org/2000/01/rdf-schema#comment.

Additional Notes

  • To authenticate using Kerberos, both the Stardog endpoint and your browser must be correctly configured. Check out the detailed documentation on how.

  • Designer does not support project resources with field names that start with underscores, such as _columnOne. Underscores are supported in non-starting positions. For example, a field labeled column_one is supported.

  • To improve performance of inference rules which reference specific data instances, we recommend using the in property option and specifying the IRI of the instance(s) using backticks (`).

  • Inherited relationships and attributes are shown for subclasses.

  • When deleting a class, all attributes solely associated with that class will also be deleted. A warning message will be shown to the user listing the attributes to be deleted.

  • Class instances are only defined for mappings that have primary identifiers set. When mapping a project resource to a relationship, if you would like instances of classes created for both the source and target classes, the project resource must be mapped to each source and target class. It is not possible to only define relationship associations across source and target instances. Either, the source or target must have a primary identifier mapping and, therefore, instances of that class will be defined.

Getting Support

For questions, comments, or feature requests, please post in the Designer section of the Stardog Community.

Learning More

The Stardog blog includes posts about new Designer functionality. All of those posts are available under the Designer Tag.