Skip to end of metadata
Go to start of metadata

Page Contents

View or Edit

If an Ontology is associated with some governance area, every user with any governance role in this are will be able to, at least, view it. For any other user to view or edit assets contained in an Ontology, a manager must use the Ontology's utilities > User Roles settings (see documentation) to grant them permissions.

Note that different workflows that process changes to an Ontology can have their own role-permission settings (for background, see Workflow Overview: Asset Collection Permissions: ...).


Edits made directly in an asset collection are visible to all other collections that include it and to any workflows. In contrast, edits made as part of a workflow are only visible within the working copy managed by the workflow until and unless workflow changes are committed.

To edit (or view) an Ontology, navigate to either a production or workflow copy and select the Edit (or View) link adjacent to its name.

Ontology Editor

Classes vs. Instances

Beginning in version 5.4, EDG implements the recommend practice that instances in asset collections should be separated from their class definitions, which are included via one or more ontologies. Only ontologies should define classes, properties, and shapes (SHACL constraints) and all other asset collection types (e.g., taxonomy, etc.) should only contain instances. If any non-ontology collection needs special classes (e.g., subclasses of skos:Concept in a taxonomy), then it should include them (via owl:import) from one or more ontologies. The ontology editor still supports both class-level definitions as well as instances, which might be needed in certain cases. However, any manager of an ontology can use Manage > No-Instances Mode to block the further creation or modification of instances, allowing the editing of only classes and their properties (attributes, relationships, constraints). Separating instance collections from their ontology definitions provides flexibility in using the models. NOTE: EDG Administrators can disable this restriction via the Enable Ontology Optimizations parameter; see Server Configuration Parameters > Advanced Parameters for details.

Overview

The editor view has three vertical panes, where the left and right panes can each be collapsed/expanded by clicking the shaded control section in the center of the vertical separator/border column. Mousing over most buttons pops up its function label.

Class Hierarchy

The editor's left pane shows the hierarchy of classes with their properties (attributes, relationship, constraints) shown as nodes in the tree. If the ontology has or allows instances, then the lower hierarchy pane is a sub-pane showing instances of the selected class if any. Note that classes and properties that come from included models are represented by icons with muted colors. You will be able to add information to these items, but you will not be able to delete them or modify information that comes from the included model. The hierarchy shows up to 1000 nodes.

Custom root-class

The root class of a hierarchy can be set to a desired element via Manage > Root Class of Hierarchy. This might be desired, for example, if the ontology specializes a standard one, and you don't want to show the ancestor classes of your main custom class. Replace the default class-name "Thing" with the name of the preferred root class. Autocomplete assists in entering the class-name.

Quick search

The Class Hierarchy and Instance window each have their own quick search field. It lets you look up items displayed in the tree and items displayed in the Instance window. The lookup in the Class Hierarchy is limited to classes only. It doesn't support search for properties associated with classes.

Find class or property by text

The ellipsis button  opens a dialog for a general text-search of all classes or properties containing the given search string in any property. Clicking on a row tries to select that resource in the tree.

Hierarchy Nodes and Buttons

Colored icons on the tree show you what they represent: Light brown circles are classes, green rectangles are attribute properties, blue rectangles are relationship properties, and open-center rectangles are constraints.

A class. Under the hierarchy root each of these is a subclass of its parent node on the hierarchy. See Creating a new class and Editing class, attribute, or relationship definitions for more information.
An attribute property of the class represented by the shape's parent node on the hierarchy. See Adding a new attribute or relationship property to a class for additional information.
A relationship property of the class represented by the shape's parent node on the hierarchy. Adding a new attribute or relationship property to a class for more about these.
N/AProperty shapes (SHACL constraints) no longer explicitly appear as nodes in the hierarchy. They are represented in the detail forms of their applicable properties and classes. (See below for details.)

At the top of the class hierarchy, next to the quick search field, managers and editors of the ontology have colored buttons that let them create a (sub)class , an attribute property , a relationship property , or add a property constraint , to the selected class. After creating a property, one can set the range of its values. For an attribute property, these are typically data types, such as "integer" for an attribute "age"; for a relationship property, the range would be a class such as "Country" for a "country of birth" relationship.

If the ontology allows instances, then the bottom portion of the hierarchy pane will have the Instances of CLASSNAME pane. If the selected class in the hierarchy has any instances in this same model, then they will be listed here, and selecting any one of them will display it in the central details pane. Although instances do not appear in the hierarchy, managers and editors have the Create CLASSNAME... (Instance) button  at the bottom of this pane, which allows them to create a new instance of the selected class.

Editing Classes

When a node is selected in the hierarchy (class, instance, property, constraint), its details appear in the central pane, which lists its properties and makes them editable if the user has sufficient permissions. At the top of the details pane is a bar with buttons for various viewing and editing functions.

In addition to the Edit button, discussed above, the gear-wheel button lets you delete the current item. It also provides functions such as additional viewing, cloning, and customizing the form layout. The Show History checkbox displays the changes made to the item within its production or working-copy version, and it lets you revert particular change steps. The View/Edit Tasks button  lets you manage tasks associated with the item (see <collection type> Utilities > Tasks View). Likewise, the View/Edit Comments button  lets you associate comments with the item (see  <collection type> Utilities > Comments View). Note that both the Tasks and Comments buttons do not appear unless an administrator has activated those features (see Administration: EDG Configuration Parameters).

Creating a Class

Use the hierarchy to create a new class by first selecting the parent class and then click the Create Class... button . This displays a dialog box where you enter the name of your new Class and optionally edit the URI generated by EDG as an internal ID for the class. After you click the OK button, EDG adds the class's node to the hierarchy and displays it in the central property-details pane where you can edit its properties and constraints.

Adding a Property: Attribute or Relationship

After selecting a class on the Class Hierarchy, clicking the Create Attribute...  or Create Relationship...  button adds one of those properties to the selected class. EDG first displays a dialog box where you enter the name of your new property and optionally edit the URI generated by EDG as an internal ID for the property. After you click the OK button, EDG adds your new property to the Class Hierarchy and displays details about the property in an edit form on the right where you can edit these details.

After you define a new attribute or relationship property for a given class, you will see it as a custom property on edit and search forms for that class.

Adding a Property Shape

On either a class or one of its properties, clicking on the Add Property Shape...  button creates a SHACL constraint for the selected, or identified, property, and the shape is associated with the class. The shape is not represented in the hierarchy view, but its shown in the details view of the related property and class. When a property is selected, its shapes (if any) are listed in the details view, in the Local Property Characteristics section, labeled by each shape's class. When a class is selected, its shapes (if any) are listed in the details view, in the Constraints section, labeld as "property shapes". In either case, users can switch the details view to just the details of a single property shape by clicking on box that shows the desired shape. The shapes can also be edited within the details view, either within context of their associated property or class or from their own details view alone.

Viewing and Editing Information about an Asset

Information about selected asset is shown in a form, with fields organized organized into groups.

Checking data quality via Problems and Suggestions

When the Show Problems and Suggestions button  at the top of the form is selected, form will display any issues that are found with the selected resource together with suggestions on how to fix them. It will also display some additional facts TopBraid EDG finds with some degree of certainty - for example it may suggest a connection between a data element and a business term. You can then accept the suggestion or ignore it. When the Show Problems and Suggestions button  is de-selected, checking of values and making suggestions will happen only when information is modified and saved or when a user decides to run Problems and Suggestions report for the entire collection. This setting acts across all of the user's collections.

Editing Information about an Asset

The default viewing mode shows only the properties of an Asset that currently have values. Note that the New Tab button  opens the current details pane in a new browser tab.

 

Users with sufficient permissions can edit information in two ways: (1) per individual property via the pencil icon  that pops up as the cursor moves over a property; (2) all information on the form by pressing the Edit button  at the top of the page. 

Clicking a property's popup pencil icon  lets you edit "inline" values of that property.

The Edit-button  opens all available properties for editing. Showing fields that have values and those that do not yet have values.

  click to enlarge

The Edit-button mode also lets you log a message with the saved changes.

NOTE: When finished with Edit mode, be sure to click either the Save Changes or the Cancel button.

Show History

The Show History checkbox at the top of the page toggles the display of all saved changes made to the asset since it was first created. It lets you to undo or "revert" the changes back to what they were previously.

 

Editing Class Properties

On a class, when editing an attribute or relationship property, its domain identifies the class(es) with which it is associated (for example, which class forms the property will appear on), and the property's range identifies the potential values that can be assigned. Optionally, a property can also require value-settings by choosing a cardinality option from among those listed among the "Attribute Characteristics" or "Relationship Characteristics" on the editing form.

For example, the status relationship, below, has a domain of either the Country or the Market Identifier Code class and will thus status will appear as a property on forms for those classes and their instances, and it will limit values to those from its range, the Status class.

   

Setting a Primary Key for a Class

By default, when creating a new resource (class, property, reference data item), EDG automatically generates a URI to uniquely identify the resource by combining the default namespace specified for the ontology (the default being "http://example.org/ontologies/new#") with a user-entered label for the resource, with any characters that would cause problems in a URI being converted. For example, the URI generated for a resource with the label "Pat Smith" might be "http://example.org/ontologies/new#Pat_Smith". If the label is non-unique, EDG will append a number to create a unique identifier.

If you are planning to use an ontology class as the main entity for any reference datasets (see Create New Reference Dataset), then each dataset must designate one of the class's properties as the primary key of its main entity. Using labels as identifiers is not sufficient for several reasons; e.g., there is no guarantee that they are all unique. Any property used as a primary key must have unique values across all members of the class, e.g., an employee ID or a social security number for People, or the ISO alpha-2 character code for Countries. If any datasets using the same main entity class also use different properties as their primary key, then each dataset must designate its own primary key. But if all such datasets use the same property as their primary key, then users have the option of designating the primary key once, on the ontology class itself.

To do this, select the property in the hierarchy pane and choose Make primary key... from the gear menu  at the bottom of the edit form. A dialog box will show a default URI that the property's value will be appended to, like this:

Set it to whatever you like, click the Ok button, and in the Class Hierarchy pane EDG will show that the selected property is now the primary key:

Then, when you create a new instance of that class, the dialog box where you enter the initial data will also ask you for a value of the primary key property. As you enter it, you'll see that value added to the URI that will be used to identify that resource during its lifetime:

Cloning a Class, Property, or Instance

Managers and editors can clone (copy) any existing class, property, or instance by selecting it, then clicking the gear menu  button at the bottom of the central details pane. There is a clone action that will create a copy of the selected item. Note that cloning of a class will not include its subclasses.

Deleting Classes, Properties (attributes or relationships), and Instances

To delete a class, property, constraint, or instance select it in the hierarchy or instances pane and then select Delete... from its gear menu  in the details pane.

Deleting a property will also delete all values assigned to that property for all classes in the model. Deleting a class will recursively delete all of its properties, subclasses, and instances.

Changing a Class's Parent

In the Class Hierarchy, you can change a class's parent in order to refactor the class hierarchy. (This cannot be done for a class from an imported ontology, which will be represented with a lighter color circle on the Class Hierarchy.) Managers or editors can select a node in the Class Hierarchy, Edit it, and in the Class Characteristics section, they can change the sub-class of value by entering a new one:

The plus sign next to sub-class of means that you can add additional values for that property if you wish.

You can also change a class's parent by dragging it on the class hierarchy. In the following, Employee is being dragged, and the red X shows that the cursor is not yet in a valid new position for the Employee node of the tree:

 

With the mouse pointer on the Person class, it is a valid new position for the Employee class, as shown by the green check mark: 

Releasing the mouse button puts the Employee class at its new location:

Note that you cannot edit the class's parent class if it resides in an imported ontology.

Adding Constraints to a Class

NOTE: Constraints in TopBraid EDG are moving to the recent W3C recommendation: Shapes Constraint Language (SHACL) .  Users are encouraged to consult this tutorial on using SHACL in an ontology. For background, also see SHACL TUTORIAL: GETTING STARTED  (and this ).

As mentioned above, SHACL constraints now appear in the hierarchy as open-centered child nodes of their property (see the tutorial).


SPIN Constraints (deprecated)

EDG no longer lets you add new SPIN constraints to classes. If attempted, it will show message indication about using SHACL. To do so, select the desired class in the hierarchy view and then either: (a) click Add Property Shape..., to add a new SHACL-based constraint on a property of the class, or (b) click Edit in the class's detail view, which then shows any existing SHACL-based constraints.

Editing OWL Class Axioms

The Web Ontology Language (OWL) provides a notation called the Manchester Syntax that can be used to define restrictions on properties, intersections, unions and other logical class axioms. You can enter such expressions when you select Edit OWL class axioms from the drop down menu to the right of the input field for subclasses and equivalent classes. Note that in this syntax you need to surround property and class names using the ` character (not the plain ' apostrophe).

Displaying Relationships with NeighborGram and Class Diagrams

One can visually browse a resource's relationships to other resources (classes and instances) in an interactive graphical view called a NeighborGramTM. To launch this view from a resource's details pane, select the gear button  and select the Display NeighborGramTM... item. The views opens in a new browser tab.

 

 

When a resource node has many relationships, they will be shown in disjoint groups that are "pageable" via a selector with arrows and a counter. Selecting a node shows popup controls for making it the central resource, configuring links, or expanding links.

The form in the right pane shows details of the central resource. When that resource is a class, the form shows a Class Diagram section. Selecting that section link opens a nested form showing the class's associations in a UML-like diagram.

JIRA Launch-in-Context

If the JIRA LiC feature has been configured by an administrator, then for each asset collection, a manager can set an associated project-key string via Manage > JIRA Project Key (see documentation). Then, when the collection's editors are simultaneously logged into JIRA, they can launch from editor resources into related JIRA searches and new items in the collection's corresponding JIRA project. On a selected resource, use the gear button  in the details pane to select any of the following: Create JIRA Issue, Search URI on JIRA, or Search label on JIRA. The two searches will open (as browser popups) JIRA pages that search on the indicated resource string (URI or label). The create option will open the start of a new JIRA item. Note that if the browser is not logged into JIRA (or if the administered JIRA settings fail), then the launches can result in a Server Interaction Error.

Searching Within an Ontology

Advanced Search Form

The advanced search form provides many options in how you search and what you can do with your search results. For the selected class, the search form has a field for each property. One can use a combination of fields to match instances only on those properties. Properties with two hyphenated fields allow one to search on a range of values. The Search any Text field matches on any property of an instance (See the Configuring Search Text Properties section in the EVN Developer Guide for how to add this field to the search form for a given class and configuring which properties it should search). Each resulting instance must match all of the form's user-entered values (AND operator). Selecting Return local results only will deliver only resources whose rdf:type triple is in the base graph, thus excluding resources from included graphs. This search option will be presented if the vocabulary/asset manager has not pre-selected a choice.

 

Property matching

For each property, one can specify the type of match. Different properties can use different match types, all combining together to produce an overall search result.

Type of MatchHow a search value matches instance property-values
text contains

Text DEFAULT: Search text is a substring of a property- value (case-insensitive). Example: Search text "lis" on a city-name property would match instances having city-name values such as "Lisbon", "Lisboa", and "Minneapolis".

text equalsSearch text is exactly the same as a property- value (case-sensitive)
text matches regular expressionSearch text is a regular expression that matches a property-value (case-insensitive). Example: Search text "^lis" as a regular expression matches city-name values that begin with "lis", e.g., "Lisbon" and "Lisboa" but not "Minneapolis". Conversely, "lis$" would match only at the name's end.
any valueAt least one value exists for the search property (count >= 1). Example: See how extensively a property is used.
min/max number of valuesThe number (count) of property-values (occurrences) is within the search range, inclusive. Example: If most instances in a Ontology have labels in three languages, entering a label search with values-range 0 to 2 would return those instances with fewer.
no valueNo values exist for the search property (count = 0). Example: Use to clean up a Ontology and check for remaining work.
booleanBoolean DEFAULT: Search values restricted to true/false instead of free-text
equalsClass DEFAULT: Quick-search field for finding an instance of the property (object)
nested formAdds an embedded search form for properties whose type is another class
label matches regular expressionSearch text is a regular expression that matches the label of a property-instance (object)

Searching by relationship values

As you start typing a value in a relationship field, you will get a list of autocomplete options that match the text you've typed so far—a list of the names (labels) of any entities that begin with the typed letters.

The triangle next to each relationship field displays a menu that gives you several options for how EDG uses the value you enter in that field to search your reference data. The options are similar to the ones described above with a couple of exceptions: regular expression search is not available, but there is a nested form search option:

  • nested form displays a form where you can describe specific details about the items with the specified relationship to the reference data you're searching for. For example, if you wanted to search for all Market Identifier Codes associated with a MIC Country whose numeric code is between 600 and 640, you would enter those numbers on the nested form under mic Country like this:

  • label contains indicates that you want to search for codes that have the entered string anywhere in the label value for this resource. For example, if you search market identifier codes whose mic Country property has "land" in it, EDG will return resources with values such as Thailand, The Netherlands, and Switzerland.

  • any value indicates that you want to search for codes that have any value at all for this property.

  • min/max number of values search for any code whose number of values for this property fall in the range specified by the one or two numbers you enter.

  • no value indicates that you want to search for resources that do not have a value set for this property.

Displaying Columns in Results Tables

Columns in the results table are configured by properties

The columns displayed in the central results table are determined by a setting on each property in the search form. The display selector is located between each property's label and search field(s), and the display setting is independent of whether the property is used in a search.

SelectorDescription
(check-mark)This property will appear as a column in the results table
... (ellipsis)This property will not appear as a column in the results table
# (hash/number)

This property will appear as a count column in the results table (showing the number of property-values)

To change the table's columns, select or unselect fields in the search form (also see:  gear-button > Unselect all columns, below) and then press the Search button. The order of properties in the form determines the column-order of the table.

Setting the default columns

In subsequent editing sessions, the column settings will revert to their defaults. However, a manager can reconfigure the default for all users by selecting the columns and then clicking on the star button  at the bottom of the Search form. This preserves the current settings as the new default for all users.

A recommended practice is to set default columns (properties) on an ontology class, which is subsequently included by other vocabularies or assets, such as reference datasets. The resulting instance tables will have the ontology class's column settings as their initial default, which can then be overridden if desired.

Search Results Operations

The gear menu  below the search form gives you several options for what you can do with search results:

  • Batch edit search results... lets you edit property values for all the search results together. See Editing multiple codes together for further information.

  • Display chart of search results... generates a chart of your search results from your choice of formats.

  • Export results to SPARQL CSV spreadsheet creates a comma-separated value version of the search results that includes the URI of the resource represented by each result row in the first column. See the W3C SPARQL 1.1 Query Results CSV and TSV Formats standard for more details (although there aren't many more details—it's a very simple format).

  • Export results to SPARQL JSON file creates a text page of results in SPARQL Query Results JSON format.
  • Export results to SPARQL TSV spreadsheet creates a tab-separated value version of the search results that includes the URI of the resource represented by each result row in the first column. URIs are delimited by angle brackets.
  • Export results to SPARQL XML file creates an XML version of the search results that conform to the W3C SPARQL Query Results XML Format.

  • Export results to simple TSV spreadsheet creates a tab-separated value version of the search results, showing the preferred label of each resource instead of URIs. This creates a more human-readable version of the data than the SPARQL TSV spreadsheet.

  • Open faceted search dialog... displays a dialog box that lets you do a faceted search over the reference data for the selected entity.

  • Show SPARQL query... displays a pop-up window with the query that is being generated on the server when the search form is executed. Advanced users with knowledge of the SPARQL query language can copy and paste the resulting query string into a SPARQL execution window (for example, using TopBraid Composer) or send the query to the TopBraid Live SPARQL endpoint.

  • Unselect all columns clears all selected columns (check-marked or hash-counted) in the form, which removes all non-default columns from associated search-result tables.

Exported search results will be displayed in your browser. Select Save As from your browser's File menu to save the results as a text file.

Spreadsheet programs such as Excel can easily read tab-separated value files, so saving search results in a tab-separated format is a simple way to create custom reports for people with no access to your EDG installation.

Editing multiple results together

After executing a search with the search form, the Batch edit search results choice on the search form's gear menu  lets you edit all the search results at once with a single form.

For example, when selected after searching for all country codes that became valid in 1991, this menu choice displays the following form in a dialog box:

The form displays only values that all of the results have in common - in this case only the value for the "valid since" property. If you change this value, the change will apply to all resources in the search results. Any new values you will add will also apply to all search results.

Common values can be deleted all at once by clicking the X to the right of the value on the batch edit form, and new values can be added by entering them the displayed fields before clicking the Save Changes button.

 

Searching in No-Instances Mode

When the ontology is in the No-Instances Mode, the search form lets you find classes as opposed to their instances. You can also search for properties to find, for example, any property that has 'date' in its name or description. A dynamic icon on the search form's menu bar offers a way to toggle between the class search and property search.

Saving Searches

In the lower-right of the search pane, two buttons let you save and retrieve searches for later execution. In addition to executing these searches from within EDG, the saved search servlet lets other applications execute saved searches by using the appropriate URL. The "Save current search" button  displays a dialog box where you enter a name for the search that you'd like to re-use later. The "Show saved searches" button  displays a list of saved searches.

This dialog box has three buttons at the bottom:

  • The Select button closes the dialog box and fills out the search pane with the parameters set by the selected search so that you can execute it.

  • The Delete button deletes the selected search from the list of searches.

  • The Close button closes the dialog box.

Selecting a saved search on this dialog box also displays a URL in the Service URL (for copy and paste) field that can be used to retrieve the search results from another application that has HTTP access to EDG. This can be a browser, Excel (after picking Open from the File menu), or any application that can make a RESTful API call. (The default format of the returned data is comma-separated values, but this can be modified in the URL.)

Saved searches will also be available on the Export Saved Search list available via the Export tab.

Faceted Search

To do a faceted search for instances of the selected class, open the Faceted Search view through the gear button popup menu. The Add Property field lets one filter the instances based on their property values. (This does not show if there are no such instances.) Selecting Return local results only will deliver only resources whose rdf:type triple is in the base graph, thus excluding resources from included graphs. This search option will be presented if the vocabulary/asset manager has not pre-selected a choice.

Below, this field's drop-down list is being used to select the family name field.

 

In the next screen shot, the family name and gender properties have been added and the main form is showing information about the instances of the class. The > symbol to the right of the gender property has been selected, pointing it down and displaying all possible values stored with that property along with the number of instances that have those values. (Clicking the > to the right of the family name property would do the same for its values.)

 

Clicking "female" on the previous screen adds that as a faceted search criterion, so that the panel on the right only displays instances with a gender value of female:

 

Clicking the x next to "female" removes it as a search criterion, showing all the instances of the class that were shown before it was added. You can also narrow down the list of displayed names by entering a search string in the upper-left and clicking the magnifying class icon.

This example only scratched the surface of what you can do with faceted search. Using different combinations of properties and property values lets you do much more sophisticated searches of your instance data.

Editing form layouts

EDG provides a default layout for all data with a generic form that has sections for Annotations (labels and other textual descriptions), Properties (all other properties) and Incoming References. Within those sections, the properties are sorted alphabetically. EDG's web-based form layout editor lets you create custom forms where you can select which properties appear where, as well as what labels display with them.

To get started with this editor, choose a class on the Class Hierarchy and open its context menu at the bottom of the form. If the class already has a customized form layout, you will see the menu items Edit form layout... to open the editor and Reset form layout to delete the configured form. If the class does not have a customized form layout yet, you will see the menu item Create form layout... to open the form editor in a new browser tab as shown in the screenshot below. Note: Custom forms cannot be created for classes that already have a form defined in their schema file (or in some other graph that is included in the SWP ui:graph).

 

The default form created via Create form layout... consists of a single section called Properties that holds a widget for each property that is relevant for the selected class. The editor can be used to modify which properties appear where on the different form modes: Browse, Edit, Search and History.

The left hand side of the form editor, called Element Hierarchy displays a tree structure with user interface elements. Selecting an element in the hierarchy will display details on the right hand side. You can drag and drop elements within the tree to change the order of properties or move elements under a new parent.

Depending on the selected element, different buttons will appear underneath the tree, allowing the user to create new elements of the given class.

There are four types of form elements that you can add to your form:

  •  Section: this groups property widgets under a header label. You will need to explicitly list all the fields to place in the section. This can be configured to be openable by the user with a twistie. For example, the following shows a closed enumeration with the label "phone numbers":


    Here, we see that someone has clicked the triangle twisty to open the enumeration and display its property list:


  •  Objects Placeholder: represents a special section–a group of those property widgets that are not explicitly enumerated. If a property has not been allocated to another section and a Placeholder section exists, the property will be shown as part of the Placeholder group.

  •  Property widget: represents the values of a given property for the current instance. Details below.

  •  Inverse Property widget: represents the values of a given property for the current instance, but interpreted in the inverse direction. For example if the class Person has a property child pointing from parents to children, then using an inverse widget would point from a child to the parents.

Property widgets can be configured with the following settings:

  • property: indicates the property to display.

  • cardinality: defines how the user interface shall behave if multiple values are present for the property. This setting only makes a difference if the form is in edit mode. The cardinality determines whether a user can add more than one value for the given property. By default this is derived from the ontology (using RDF constructs such as owl:FunctionalProperty and owl:maxCardinality). In many cases, however, the ontology does not contain such constraints and the form layout can hold this information. Basically, if a property has no cardinality constraints (that is, it may have any number of values according to standard OWL semantics), then swa:Object would at most allow one value.

  • hide in modes: can be used to hide the widget depending on the mode (Edit, Search, View, or History) of the form. For example, setting this to search will prevent this property from appearing on the search form so that users cannot search for instances using this property.

  • label: The label that will appear with this property on the form

Note that the form layouts will not update automatically if properties are added or deleted. If a new property is added to a class and the class has a customized form, then you may want to double-check that the property is either explicitly enumerated or that an Objects Placeholder (see above) exists to catch all implicit properties.

 

Because all form definitions are stored in the same place (in a file called  server.topbraidlive.org/dynamic/uiconfig.ui.ttl ), form layouts for the same class (determined by the URI of the class) will be used globally, across all projects. For security reasons there is no global mechanism for end users to see all customized forms, but users in a Manager role can select the See Customized Forms link on the ontology's Manage tab. This opens up a page enumerating all classes from the Ontology that have customized forms, with options to navigate to those definitions and possibly to delete the forms.

The SWA source code for form layouts can be obtained by choosing the "Show Source Code" link in the upper-right of the application as shown in the figure. This is useful for developing custom views of data using the swa:Object and swa:Subject form layout. Details can be found at SPARQL Web Pages Application Components (SWA) Forms or in the interactive Help found in TopBraid Composer (with TBC-ME running, go to http://localhost:8083/tbl/swp?_viewClass=swadoc:Index#Objects).

To administrators: If you copy projects from one server to another, using the Send Projects to Another Server feature, there is an option to also copy the form definitions. For regular system back-ups or other maintenance tasks you may want to preserve and copy the uiconfig.ui.ttl file as well.

The form editor and SPARQL Web Application Components (SWA)

The layout of the forms used by TopBraid EDG is determined by form definitions represented in SPARQL Web Pages (SWP), in particular SWA Forms. Users familiar with SWP can take full control of form layouts by editing customized forms with TopBraid Composer and then uploading the form definitions as .ui.ttlx files to the EDG server. However, this process requires some detailed knowledge of how the system works as well as admin access to upload the files.

  • No labels