Stardog Designer
This chapter discusses Stardog Designer - a no-code, visual tool for creating and maintaining your Knowledge Graph.
Page Contents
Overview
Stardog Designer is the visual environment for creating and maintaining your Knowledge Graph 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 model and mapping efforts. Projects may use existing models in a Stardog database to jump-start the modeling process.
Work completed in Designer can be exported to your local filesystem or published directly to a Stardog server. A file with the extension .stardogdesigner
is included in the export. To import a project, upload the file with the extension .stardogdesigner
.
Project settings
- Project name
- The project name is used to identify a project throughout Designer and sets the namespace of the project.
- 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 models. All new model concepts will use the updated project namespace.
- Advanced project details
- Set a custom project namespace. All projects have a default namespace of
tag:stardog:designer:[PROJECT NAME]:
, where[PROJECT NAME]
is the name of the project. - 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 asClassB
, instances ofClassA
can be inferred to also be of typeClassB
. Setting to custom per property allows changing this option at the relationship and attribute level.
- Set a custom project namespace. All projects have a default namespace of
Modeling
The models created in Designer use OWL and RDFS standards to ensure models are compatible with open source semantic tools.
The tool bar 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.
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.
Model concepts can be modified in their detailed drawers by double-clicking a model concept or right-clicking the concept and selecting Edit
. If you wish, 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.
Using an Existing Model
Existing models can be imported from Stardog servers. To do so, simply select the plus icon next to Models in the left-hand panel and follow the screens to confirm your server connection and 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 above 10 Mb will be stored as part of a project; as a result, CSV files above 10 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 then the first row of the file may not be used to indicate column headers.
Virtual Graph Options
- Virtual graphs can be created for any existing data source through Designer.
- 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 namedTABLE
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`
- 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
- The project resource name will be used as part of the virtual graph name when published.
- The scope can be a single table from the selected data source connection or a custom SQL query.
- Only relational database data sources are supported at this time. Please see Supported Data Sources - Relational Databases for the complete list.
Mapping Capabilities
Designer includes a model view and a mapping view. The 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 model concepts by adding a link from the toolbar when the project resource is selected. Once dragged to a model concept, the mapping link creates a mapping. A primary identifier is required when mapping to a class and is used to identify unique class instances. When creating a mapping for a relationship, the primary identifiers for the source and target of the relationship identify the pair of class instances connected by the relationship. The model concept will turn blue when all required fields are mapped.
Mapping multiple fields to an attribute
If you wish to map multiple project resource fields to the same attribute, you can select Duplicate attribute
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.
Publishing
Designer supports publishing projects in two ways, to a zipped folder or directly to a Stardog server. The zipped folder contains all the inputs needed to publish the model and mappings to Stardog. The contents can be used in version control systems to document 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 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.
- Please see SMS2 (Stardog Mapping Syntax 2) to learn more about SMS2.
- A properties file.
- If the project resource was a CSV, the original CSV renamed to the project resource name.
- A Stardog Mapping Syntax 2 (SMS2) mapping file.
- 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 server, there are three steps.
- Server and Database Selection
- Set the server and database to which you want your project published.
- Additionally, you can publish the namespace of your project.
- Model Configuration
- Specify if you want to create a new model or replace an existing model.
- When creating a new model, you may choose to modify the model name or the schema graph a model will be published to
- Mapping 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 server.
Created 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 settingInfer class types based on shared properties
isYes
orCustom per property
and setting this option toYes
for a relationship, the relationship domain will be defined byhttp://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 settingInfer class types based on shared properties
isYes
orCustom per property
and setting this option toYes
for a relationship, relationship range will be defined byhttp://www.w3.org/2000/01/rdf-schema#range
.
- Relationship domains (e.g., sources), by default, are defined by
- 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 settingInfer class types based on shared properties
isYes
orCustom per property
and setting this option toYes
for an attribute, the attribute domain will be defined byhttp://www.w3.org/2000/01/rdf-schema#domain
. - Attribute ranges, by default, are by
https://schema.org/rangeIncludes
. If the project settingInfer class types based on shared properties
isYes
orCustom per property
and setting this option toYes
for an attribute, the attribute range will be defined byhttp://www.w3.org/2000/01/rdf-schema#range
.
- Attribute domains, by default, are defined by
Additional Notes
-
To authenticate using Kerberos, both the Stardog server 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 labeledcolumn_one
is supported.
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.