Skip to end of metadata
Go to start of metadata

Page Contents

Lineage Model Utilities

To perform various kinds of operations on a particular Lineage Model, open its name-link in the Lineage Models home listing. This shows the Lineage Model's assets view/edit page, with the menu bar on top of the page. The menu bar screenshot below shows the edit/view page as the first, selected tab. The name of the first tab will vary depending on the type of the collection.

Following the first tab, multiple additional tabs provide access to categories of utilities or operations. Each of these tabs is described below.

The tabs and operations on the tabs you will actually see for a specific Lineage Model, will depend on two factors:

  1. You privileges for a specific Lineage Model. Some tabs are only shown to users with manager privileges.
  2. Whether any configuration of the tab operations has occurred. For example, asset collection managers can remove some of the operations by selecting Configure Features option on the Manage tab. It is also possible to add new operations and further configure existing ones.

Dashboard View

An asset collection's dashboard summarizes various kinds of status and quality measurements that are relevant for that type of collection. You will also see and be able to change collections's description.

Completeness and Validity

The Completeness and Validity charts summarize any data-quality issues found from running the collection's Reports > Problems and Suggestions. This includes issues such as missing values for required properties (incompleteness) or other types of rules violations. (Required properties are set by the cardinality checkboxes of a property form.) To update the dashboard charts or to see the issue details, run the Problems and Suggestions report.

Process

Process summarizes information about tasks and workflows.

Settings View

The Settings view provides access to asset collection's metadata. It also lets you view and modify asset collections that are included in this collection. 

Included-By and Includes

These sections show the references (owl:imports) from and to other collections. Users with editor privileges for this Lineage Model can modify its includes. The choice of collections-to-include is restricted to collection types that are either required or permitted for the current Lineage Model. See the main Lineage Models page (under Home > Create) for additional information.

Crosswalks

This item only appears if the Lineage Model is referenced by any Crosswalk mappings. It lists links to the associated Crosswalks.

Includes based on Subject Area

Asset collections that enable this function will automatically include other collections contained in the same governance area and its sub-areas (both business and data-subject areas). By default, each collection has these auto-includes disabled. Auto-includes should only be enabled for governance areas having a reasonably small number of collections.

Namespaces and Prefixes

This view lists the collection graph's namespace prefixes, which can be used in SPARQL queries, etc. Users with manager privileges for this Lineage Model can edit them using Turtle notation.

NOTE: Although comments (#) are accepted, they are not preserved.

Default Namespace

The default namespace is used to construct URIs (unique identifiers) for the classes, properties and other resources in the Lineage Model. Changes to it will not impact URIs of already existing resources.

Graph URI

This is an internal identifier for any asset collection created by EDG. It can't be changed.

External Graph URI

This option defines a URI that automatically maps with EDG's internal Graph URI during imports and exports. RDF file import operation will automatically redirects any owl:imports statements in a file to the asset collections in EDG with external graph URIs that match those in the file's owl:imports statements. The inverse mapping happens when graphs are exported back to RDF files: their external Graph URI is used instead of the internal urn:x-evn-master:... URIs.

Metadata

This section lets you view or edit information about the Lineage Model. There is a rich selection of metadata fields, and it is easy to configure EDG to include additional fields if required. The metadata is organized into sections. The view mode only shows the sections and fields that contain information, while the edit mode shows all sections and all fields.

Overview

This section records descriptive properties of the Lineage Model, including its official name (if different from the common name or label).

subject area

This is the governance area (business or data-subject) to which this Lineage Model is assigned (if any).

Status

The Status section records the life cycle stages of the Lineage Model.


Users View

Lineage Model Permissions

For any asset collection and a working copy of a collection in a context of a workflow, access to its basic viewing, editing, and utility functions is controlled by the three nested permission profiles: viewereditor, and manager (where each profile is a superset of the preceding one). On each collection, these permissions are set for various users, either as individuals or as security roles (e.g., from LDAP).

Lineage Model Permissions section list users that have access to this specific Lineage Model or, in the context of a workflow, its working copy.  A blank setting indicates no access for the user or role.

Users with manager privileges can use this page to assign permission profiles to other users. For non-managers, this view is read-only.

In a context of a production copy, permissions can be set for any user. In a context of a workflow permissions can be set only for users that already have (at least) a viewers privileges for the production copy. A given user can have different permission profiles for the collection itself (production copy) and one of its workflow working copies. Similarly, they could have different permissions in the context of different workflows.  

For example, if Jane has manager permission profile for an asset collection, she can give John viewer privileges for it and editor privileges for one of its workflow copies. John can then make changes in the context of a workflow.

A user that has any governance role for a collection is automatically granted viewer privileges for the collection and any of its workflows.

A user with multiple permission profiles on a given collection or workflow receives the greatest level assigned. See Workflows - Rights Entailed by Permissions Profiles for details.

Lineage Model Governance Roles

This section lists governance roles assigned either directly for this Lineage Model or indirectly through a governance area it belongs to.

Users with manager privileges can use this page to assign governance roles to other users: as individuals, as security roles (e.g., from LDAP), or as organizations. For non-managers, this view is read-only. For details on governance roles, see Governance Model > Governance Areas (and Roles).


Import View

From any Lineage Model's production or working-copy home page, the Import functions lets you load data into the given Lineage Model from external sources such as RDF files, spreadsheets, etc. You will only see the Import View and its operations if you have edit privilege for the asset collection.

Import RDF File

Any Lineage Model can import data from an external RDF file (in a serialized format). The Import > Import RDF File link shows a screen where the Choose File button opens a dialog for picking the external source file.

Choose the source file and identify its format. Decide whether to record new triples in the change history (use with care!) and then click Finish to complete the import. A message will indicate whether the import was successful.

Note that if your file contains any schema definition (classes, properties, shapes), you will only be able to import it into an Ontology. If you have both instances and schema data in one file, either split the file before import or follow instructions in Refactoring Ontologies.

When importing RDF files into an Ontology or into a Taxonomy, EDG will perform some transformations:

  • For ontologies, "subclass of Thing" statements will be added for classes that have no parents. This is done to ensure that these classes are visible in the Class Hierarchy.
  • For taxonomies,  "narrower concept" relationships will be used to generate inverse "broader concept" relationships. This is done to ensure that such concepts are visible in the Concept Hierarchy. 

When importing RDF into a Working Copy, the addition of each triple can be added as an entry in the change history, where it will be available to all the relevant reports. When importing into a production copy, the Record each new triple in change history checkbox gives you the option of adding these to the change history; note that this is not recommended when importing large amounts of data.

Import Spreadsheet using Template

This screen lets you pick a spreadsheet and a template that will be used to convert the spreadsheet data into reference data. The template may be created using the mapping process explained in the ...using Pattern section, below.

The mapping can also be created using TopBraid Composer when the simple mapping described above is insufficient and you need to perform more complex transformations–for example, concatenation of values. TopBraid Composer's SPINMAP tool provides a drag-and-drop interface that makes it especially easy to create more complex mappings.

Templates developed with TopBraid Composer must be stored in files with ".tablemap." in their name (for example, myMapping.tablemap.ttl) and be uploaded to the EDG server to be available to EDG users. Spreadsheet imported using a template must have exactly the same structure as the spreadsheet used to develop the template. The names and order of the columns must be exactly the same. If multiple worksheets are used, the order and structure of each worksheet (even for worksheets that are not imported) must be the same.

Import Spreadsheet using Pattern

This link shows the following screen:

Click Choose File to pick the external spreadsheet file whose data you want to import into the Lineage Model. This may be an Excel file (file-type extensions: .xls or .xlsx), a tab-separated value (.tsv) file, or a comma-separated value (.csv) file. The file-name should have the expected extension. Because an Excel file may have more than one sheet of data, this screen lets you specify a sheet index value to identify which sheet to read in. The default is 1, for the first sheet.

The sheet index counts all sheets in an Excel workbook, including hidden ones. For example, if you enter a 3 here and EDG seems to import the second sheet, there may be a hidden one between the first and second sheet that made the third one look like it was the second one when Excel was displaying the workbook. The Excel online help explains how to check for the existence of hidden sheets.

The Entity type for the imported data field identifies what assets you will be importing. Each row in the spreadsheet will be brought into EDG as an instance of the selected class and you will be able to map spreadsheet columns to the declared properties of the class. Make the (1) file, (2) sheet index, and (3) entity type (class) selections and click  Next .

Select Spreadsheet Type

This view enumerates five possible (column-wise) layout patterns for the spreadsheet's row-item data, showing an example of each pattern.  For data explicitly structured into a hierarchy, like a taxonomy, there are four layout options.  For all other data, there is the No Hierarchy layout (#1). In the hierarchical layouts, each row item also indicates its hierarchical path, either explicitly (absolute path, #2, #3, #4) or implicitly (recursive path, #4, #5; note that lighter text in the layout patterns indicates optional data).

 

Note the header row of column labels in every layout. The imported spreadsheet should have such a header row.

Below the five layout options, the view shows a sample of the spreadsheet's actual data.  This following image shows a spreadsheet of airport codes.

Select the layout title link that most correctly corresponds to the chosen spreadsheet's structure.

Import Spreadsheet

This view defines the data-mapping rules from the spreadsheet's columns into the class and optional hierarchy structures chosen for the collection data. It also lets users to (1) preview the import, (2) save its settings as a template for future imports, and it (3) initiates the import processing.

Column Mapping

The Column Mapping settings specify which spreadsheet columns correspond to which properties in the target Lineage Model. Typically, the target properties belong to the target entity type (class or asset type) you have selected on the previous page. When column names are close to the property names, EDG will automatically propose the mapping.

The mapping also supports inverse relationships to the target entities. Any unmapped columns will be ignored during the import, their data will not be imported.

The following example shows a mapping page presented for the "No Hierarchy" pattern.

When importing attribute values, the spreadsheet column should contain cell-values that matching the datatype of the target attribute. If, as part of the mapping, you select an optional Language value, import will add the selected language tag.

When importing relationships EDG needs to understand which existing resources to build a link to. Alternatively, it can create a URI as a value of the relationship even if a resource with the URI does not yet exist in the asset collection. After you select a relationship from the dropdown, you will have the following methods for directing EDG on how to build relationship values:

  1. If the related class has a designated primary key (PK) constraint, no additional information is needed. EDG will use the data in the mapped column to form the URIs of related resources according to the primary key definition. This means that if the related class has a primary key defined, values in the column must correspond to the property used as the key. For example, in the screenshot above Airport has an "airport country" relationship to Country and Country has a primary key that uses 2 character country codes. Thus, we mapped the Country Code column in the spreadsheet to the "airport country" relationship and did not need to provide any additional information.
  2. If all the values in the column are recognized as valid URLs, then they can be used as-is as URIs of related resources, as indicated by the associated Use values as URIs label.
  3. Otherwise, you will see an option to select a property of the related class to match on. This property will be used to find resources at the end of the relationship. For example, if Country did not have a primary key, we could map either Country or Country Code to the "airport country" relationship. If we mapped the Country column, we would then select the "short name" as the property which values to use to identify the related resources. If we mapped the Country Code column, we would select "ISO 3166-2 alphabetic country code" as the property which value to use to identify the related resources. Unlike the first two options, this method will only create a relationship if it finds already existing resource it can connect to.

Option 3 is demonstrated in screenshot below by removing the primary key from the class Country.

For inverse relationships, the spreadsheet column represents some other class's reference to the imported entities. Similar to forward (non-PK) relationships, if an inverse relationship is the chosen mapping, then there is a further choice of which referring-class property to use to identify the referring instances.

Even if the referenced property is not designated as a primary key (PK), it is still assumed that all of the corresponding property-values are unique across all referenceable instances. If duplicate values exist, then the referenced instance will be assigned arbitrarily.

Also note that if the related class designates a primary key property or if column values are URLs, then imported rows will always construct a reference, regardless of whether referenced resources exist. On the other hand, if there is no such PK designation, then imported rows will construct a reference only if a matching instance exists.

As explained below, if the target of a relationship has the same entity type as the entity type for the imported data AND you are using matching on the property values to build a relationship, the Override existing values option must be unchecked. Otherwise, the relationship will not be created.

If the imported rows will create any new instances, as opposed to only adding data to existing ones, then one of spreadsheet columns should be mapped to the label property, which is used as the display name.

When importing into reference datasets, then one of spreadsheet column must map to the primary-key property that is designated for the dataset's  main entity class. For example, the screen image above identifies this field as the IATA code.

If the imported rows are adding new data values to existing instances and/or adding new instances, it is best to uncheck the Override existing values option. Checking this option has the following consequences:

  • If an instance already exists and has a value for any of the mapped columns, the value will be replaced with data coming from a spreadsheet.
  • Relationships between instances of the same type that rely on matching of values will not be created (because these values may be overridden as part of the processing).
  • When working with Taxonomies, a combination of checked Override existing values and the No Hierarchy pattern will always make imported instances top concepts of a new Concept Scheme, even if they already exist in the Taxonomy and have parent concepts.

Hierarchical spreadsheet types

If a hierarchical pattern was selected, then there will also be Hierarchy settings that specify how the spreadsheet represents the hierarchical relationships of its data items.

Note that one could still use the No Hierarchy import pattern for a taxonomy. This would import spreadsheet terms as separate concepts without connecting them hierarchically unless you can indicate some property to use to find broader concepts. The taxonomy's editors could then use the Concept Hierarchy view to manually arrange the imported nodes in the taxonomy's concept tree.

  • For Path with Separator spreadsheets, make sure to assign at least one column under Column Mapping as the preferred label. For other types, the importer can often infer the preferred label column. (See below about the Preview button.)
  • For Column-based Trees and Column-Pair Based Tree spreadsheets, specify the top and bottom levels of the hierarchy by picking the first and last column names.
  • For Path with fixed-length Segments spreadsheets, specify the column with the path values used as IDs and the length of the segments within the path IDs. In the Path with fixed-length Segments sample layout on the Select Spreadsheet Type screen, the Id column has the path values, and each two-digit segment of these values indicates a step of the hierarchy; removing the last two digits of any of those Id values shows the Id value for that term's parent. For example, Australia has an Id value of 010201, which has a parent value of Pacific (Id value 0102), which has a parent of World (Id value 01).
  • For Path with Separator spreadsheets, in which a spreadsheet entry such as "World > Europe > France" indicates the hierarchical structure above the term "France", specify the column storing these values using the Column containing the paths field and the Path separator character in the field with that name. If your spreadsheet also includes an ID column, the Hierarchy section includes a dropdown field to indicate this.
  • For Self-Join spreadsheets, there are columns to specify the Column containing the parent ids and the Column containing the child ids. In the Self-Join sample on the Select Spreadsheet Type screen, these would be the Parent and Term columns, respectively. A Hierarchy Property field also lets you set whether you want the "has broader" property used to identify relationships in the displayed hierarchy or something else.
  • The Generate in inverse direction checkbox will reverse the direction of how the property specified in Hierarchy property is applied.

Unique Identifiers

This section defines the URI for each imported row. Selecting Overwrite existing values will delete an existing value for a mapped property before adding its new (different) value; otherwise, new values will be added to existing ones. Selecting Record each new triple in change history (warning: not recommended for large files) prevents EDG from recording the addition of each new triple in the change history.

Preview button on the Import Spreadsheet form lets you see the RDF triples that would be generated with the currently configured settings. The browser's Back button returns to the form.

The Optional: Make this a reusable mapping template field lets you save all of the settings on this form so that you can later import other spreadsheets with a similar layout without filling out this form. Once you use this field to name a template of settings, if you later pick Import Spreadsheet using Template on the Import tab instead of Import Spreadsheet using Pattern, you'll see a drop-down list of the saved template names, a Browse button to pick a spreadsheet, and a Finish button to perform the actual conversion.

When you are satisfied with the sample data shown on the preview screen, click the Finish button. EDG will display a message about successful importing of the data along with a set of data that you can use as a mapping file for imports of spreadsheets with a similar structure in the future.

Validate and/or Import Standard Lineage Spreadsheet

See Import Standard Lineage Spreadsheet.

Export View

Export View provides access to various export options. You can also export data directly from the pages that let you view and edit Lineage Model, but this view provides more options. While the primary use of this tab is for running exports, it offers full query access via SPARLQ and GraphQL. This means that some of the utilities in this view will also let you modify data.

Export Lineage Model as a Graph

This operation lets you export collection's data in a standard RDF serialization format.

Creation of reports and exporting of data are available when working with both production and working copies of reference data to anyone with who has read access.

To export subsets of Lineage Model data according to custom criteria and sorting, note that EDG's Search screen provides fine-grained control over the data to display on the Search Results area. That form's gear menu offers several choices to export the results into spreadsheet-compatible formats (e.g., for Excel). See Lineage Model View or Edit for details on searching.

For any collection, to generate an RDF serialization of its contents, select Export > Export Lineage Model as a Graph and then an RDF format:  JSON-LD, N-TriplesRDF/XML, Turtle or TriG, with or without inferences ("with inferences" adds a dedicated graph named urn:x-topbraid:inferences, which has any triples inferred via SHACL or SPIN rules; note that this computes on-the-fly and might be very slow).

Browser interactions might vary: displaying the data directly or via a kind of view source command. Alternatively, instead of directly clicking a format link, the browser might provide (on the link) a right-click menu option to save the link target to a file (i.e., without explicitly displaying the link result in the browser). A dialog box will prompt for the file location and name.

SPARQL Endpoint

This allows users of the collection to run new or saved SPARQL queries on it and to optionally save queries for others. Saved queries can be deleted by their creators and by collection managers. If SPARQL updates have been enabled by an administrator, editors (and managers) can run them, but viewers cannot. Note that the Pivot Table and Geo functions can be slow on some platforms and are not supported for Internet Explorer.

Export using Saved SPARQL Query

This lists the SPARQL queries that have been saved for the collection. For each query, it provides a URL that will run it, along with an Export Query button that runs it and shows the results.

Publish Lineage Model for Explorer Users

On an EDG server that is paired with a TopBraid Explorer server (for read-only access), managers of an editable Lineage Model can publish it to the Explorer for viewing. Note that the working copies of all published asset collections might or might not be viewable, depending on the Explorer's administrative configuration.

Any manager of an asset collection can control its Explorer publication status by selecting Export > Publish Lineage Model for Explorer Users. The view shows a Status drop-down for the asset collection, which indicates whether the asset collection was ever Published or not (Unpublished).

It also lists any included asset collections that might also require publication.

Ensure that all included graphs are either already present on the Explorer server or published along with the asset collection.

Changing the status causes the following action.

Current StatusChosen OptionResult
UnpublishedPublishedSends a copy of the asset collection and selected includes to the Explorer server. Changes the source collection's status to Published.
PublishedUpdate Published CopyRe-sends a current copy and selected includes to the Explorer server, overwriting the previous version(s). Keeps the source collection's status as Published.
PublishedUnpublishedDeletes the asset collection on the Explorer server. Changes the source collection's status to Unpublished.

Export using Saved Search

The Saved Search link shows a screen listing your saved searches. These are searches that you have saved using the Save search option in the view/edit page.

   


Clicking  Export button will download the search results. Your saved searches are web services. They can also be used as an APIs by other systems.

GraphQL Queries

This allows users of the collection to run new or saved GraphQL queries on it. For users unfamiliar with GraphQL, there is an included link to a tutorial inside TopBraid EDG and TopBraid Composer. For more information on GraphQL visit https://graphql.org/.

Reports View

Reports View for Lineage Model lets you generate various standard reports for it. Custom reports are also possible.

Problems and Suggestions Report

For any Lineage Model (production copy or working copy managed by a workflow), Reports > Problems and Suggestions checks the current state of the Lineage Model against all of its applicable quality rules (i.e., its shapes and validity constraints they define) and enrichment rules. A message box shows the rule-processing progress and then shows the report. Note that the report results are also reflected in the Dashboard > Completeness and Validity display.

Validity checking also happens every time information about specific resource is update. In this case, validity is checked only for the updated resource. Users can also enable validity checking when they are viewing individual resources in the form. This setting is sticky, it will be remembered and applied across all of asset collections user works with. See the View or Edit documentation for details.

To develop custom extensions to this feature, see EDG Developer Guide > Extending the Problems and Suggestions Reports.

View Change History

Click Reports > View Change History to show the Change History view. For a production copy, this shows all the changes made since it has been created. For a workflow, this shows only changes made within the working copy managed by the workflow.

Clicking the Search button on the Change History screen displays a time-stamped list of the saves made in the Matching Changes panel, and clicking one of those lines displays details about what changes were made as part of that save operation in the Details of Selected Change panel. Below, the change made on July 30th has just been clicked, showing that three values were added and one was deleted as part of the change made with a particular save operation.

If you are logged in as a user who is editor or manager of the vocabulary/asset collection or a workflow where the change was made, then a link Revert this Change will appear in the bottom panel. Click on this link to undo this operation. This will in fact create a new "forward" edit in the change history, with yourself as author. Note that this feature should be used with care, because reverting some steps from the middle of the change history may lead to orphan resources in your model.

If you are logged in as a user who is editor or manager of an asset collection and look at a change performed in a working copy as part of a workflow, then a link Commit this Change to production will appear in the bottom panel. You can click on this link to move the change history entry (in the example above, the three additions and the deletion) out of the workflow copy and into the production copy, essentially cherry-picking which change from a workflow copy you want to accept. As with the Revert feature mentioned above, this feature should be used with care, because committing some steps from the middle of the change history may lead to creating data statements that are disconnected from the rest of the information. For example, when you commit a change that has modified some attribute of a newly created code, then you should also make sure that the change that created the code in the first place has also been committed.

Before you click the Search button, you can narrow the scope of the search by filling out any or all of the fields at the top of the form:

  • creator Enter the name of a particular EDG user to only see changes by that user. This field uses typeahead, so that if you have users named "Joe" and "Joan" and only type in "Jo", these two names will appear in a drop-down list for you to pick from.

  • date Enter a date in the first date field to see all changes after that date, a date in the second field to see all changes before that date, or in both fields to see the changes within a particular date range. (There's no need to actually type in the date value; clicking in either field displays a calendar where you can then click on the date you want to enter.)

  • status Enter "committed" or "uncommitted" to only list changes with one of these status values.

Comparison Report

For a production Lineage Model, this report shows its differences with another, user-selected Lineage Model. For a working copy, it shows the differences to its parent production version. Note that differences do not extend to the contents of included asset collections. The report will list each changed assets and properties that were changed, showing the changed values. If a value was added, it is shown in green. If it was deleted, it is shown in pink.

For example, the following shows what happens after the preferred label property for "South Korea" is edited, an alternative label is added, and a "Seoul" is added as a narrower value of the "South Korea" resource (renamed to "Republic of Korea").

The right hand side of each change contains a link View Change that displays a dialog box with details of the change log entry that caused that particular change. Depending on your permissions, you can revert or commit the change in that dialog box. See View Change History for further information on reverting and committing individual changes.

Property Value Rules

This shows the collection's property values that are inferred through SHACL: sh:defaultValue or sh:values (see Inferring Data with SHACL Property Value Rules for details). The inferred properties are depicted diagrammatically.

Statistics

For any Lineage Model (production or working copy), Reports > Graph Statistics displays details about the Lineage Model's node distribution. The following shows the statistics for the sample Reference Dataset: Country Codes.

Workflows View

This view allows users to start workflows, and it lists both the active and completed workflows, if any. (For general information about workflows, see Workflows).

Start new Workflow

This button opens a form for starting a workflow. If multiple workflow templates (types) are available, select the appropriate one. The new workflow requires a name and allows you to enter an optional description, both of which remain editable by managers. For more information, see Workflows Utilities and related pages.

Users can also create a workflow pertaining to a selected asset (see View or Edit > Actions > Additional asset actions). Such workflows record the identity of the selected asset but are otherwise ordinary.

Workflows in Progress

This section lists any active (uncommitted) workflows of the collection. To access a particular workflow, select its row and click Go to Workflow. You will see a page showing you the status of the workflow and, depending on the workflow's status and your role, allowing you to move the workflow to the next state.

Also depending on workflow's status and your role, you can view or edit the workflow and view or execute various utility actions on it. A workflow can be used to process changes to multiple assets or changes to one specific asset. Each workflow isolates its changes to its own workflow copy, which does not affect other workflows or the production version, until and unless the workflow is committed back into production.

If the workflow was created for a specific asset, its name will appear in the row. Selecting the row and clicking  Go to Asset will open the asset's details view, which workflow editors can also modify.

Completed Workflows

This table works similarly to Workflows in Progress except that it lists the workflows that reached the terminal state. Typically, this means that changes have been finalized and committed to the asset collection. Users can view the history of workflow transitions. Each completed workflow shows its number of changed statements (triples), giving users information about the volume of changes made as part of the workflow. For completed workflows with extensive changes, preserving such history of changed triples might occupy considerable space. Therefore, asset collection managers can select a completed workflow and use the Archive action to remove the audit trail from the change history. The change records are copied into a file in a new project that an administrator can access if the change history details are ever needed again. To browse these files, use the Base URI Management page in the Server Administration area. The files will be located in a project (or folder) called "Archive". If these are not longer needed you can move them off the server. 

Tasks View

The Tasks View shows all tasks associated with an asset collection. Tasks can be created for an asset in a collection and for an entire collection. In addition to showing all tasks, this view also lets you create a task for a collection as a whole.

If you do not see Tasks tab on the horizontal menu, then it may not be enabled for your system. See EDG Configuration Parameters for how an administrator can enable the Tasks activated configuration parameter.

Tasks for [Lineage Model NAME]

When viewing or editing a particular asset within a collection, the Tasks button on its details edit form allows viewing and creating tasks about the asset. The button also displays a number of tasks that are associated with the asset.

The Tasks management view of an asset collection shows the tasks associated with it at any level - individual assets or the entire collection. You can filter the list by status and assignee.

At the bottom of the view, the Create New Task button lets you create a task. Unlike tasks you can create using the view/edit page, this task will not be associated with a specific asset, but with a collection as a whole. Clicking on the button displays a dialog box where you can add a new task's description and user assignment. Once you click this dialog box's OK button, EDG adds the task to the list for this collection, where you can set its status or due date and make other modifications. 

EDG administrator can activate a feature to Send task emails in the EDG Configuration Parameters. When activated, users with an email address (e.g. via LDAP) will receive emails whenever a task gets assigned to them, or if there is a change in the assigned task. A user assigned a task can change its status and enter comments about the task. Collection's managers can re-assign the task.

Comments View

The Comments feature allows users to associate comments with asset collections and assets. If you do not see the Comments tab on the horizontal menu, then it may not be enabled for your system. See EDG Configuration Parameters for how an administrator can enable the Comments activated configuration parameter.

Recent Comments

When viewing or editing information about an asset, the Comments button shows how many comments have been added to it. Clicking the button displays a dialog box where you can see previous comments and add your own under the "Add Comment" title; click the OK button when you are finished.

Comments have a status such as "open," "declined" or "resolved." The status of those can be changed using a drop-down list to the right of each comment entry. If you also have the TopBraid Explorer (Viewer) application, the display can also include comments from those viewers, marked with (via TopBraid Explorer).

To get a list of of the most recent 100 comments for a production or workflow copy, select its Comments management view. These comments can be filtered by status, for example, to only display the "open" comments.


When resources are deleted, their comments are not automatically deleted with them. These are known as "orphan comments." If there are any orphan comments associated with a given asset collection, the Comments view will include a hypertext link saying "Delete the X orphan comments about entities that no longer exist," where X is the number of orphan comments associated with this asset collection. Clicking this link will delete these comments.

Manage View

Each collection's Manage view is only available to its managers.

Create a Cloned Version

Managers of a particular Lineage Model can use the Create a Cloned Version function to create one or more named clones of the Lineage Model. A new clone will have the same content and user permission settings as the original production instance. However, neither the change history, saved sparql queries nor the working copies will be cloned.

Cloning is often used to "branch off" a version of the Lineage Model, so that it can be referenced and imported separately from the current version. For example, one could start with a Lineage Model called "People." Then, on reaching a milestone, one could create a clone and call it "People 1.0." Now, any other Lineage Model that explicitly should only use terms from version 1.0 could change its includes to that version only, while the ongoing work towards version 2.0 will continue on the main "People" Lineage Model.

Clear

Managers can Clear a particular Lineage Model, which deletes all of its content, history, working copies, comments, and tasks. The empty Lineage Model itself and its user permission settings will be preserved. This feature can be used prior to file imports, to replace the whole content with an externally generated version.

Delete

Managers can delete a Lineage Model via its Delete link, which raises a message box to confirm the deletion. Clicking OK will delete the Lineage Model production instance and any working copies and history data.

A deleted Lineage Model is not recoverable.

Configure Notifications

For each Lineage Model, EDG can send notification messages to users in selected roles when certain kinds of changes happen to it. In order to receive email notifications the SMTP parameters in the Server Configuration must be configured. The Manage > Configure Notifications link provides a page listing all available Notification Events together with check-boxes to select the governance roles that will be notified:

The association of users with the governance roles for this collection is configured via governance areas. The user settings can be specified directly as individual users or indirectly as either user security roles or job titles. See Governance Model Overview for a discussion.

JIRA Project Key

Note that this item only appears if an administrator has setup the EDG Administration: JIRA Integration Parameters.

JIRA is Atlassian's web application for team issue-tracking. EDG's JIRA launch-in-context (LiC) feature allows users who are working in both EDG and JIRA to launch from editing particular EDG asset items into related JIRA searches and new items.

If the EDG JIRA feature has been administratively setup, then each collection manager can optionally set a JIRA project key string for the asset collection, where the JIRA-key identifies a specific project in the JIRA application. Setting the project key then enables JIRA LiC functions for collection editors. When editing any asset item, editors can use its gear menu to create or search for related JIRA issues. See Lineage Model View or Edit – Manage > JIRA Launch-in-Context for details.

Setting the project key also adds a JIRA link to the collection's utility view header, which launches into JIRA to show the configured project's open items.

Record Triple Counts only

Selecting this option disables retention of change history at the level of individual triples (for production graphs). It records summary counts of changed triples added or deleted. This significantly reduces storage and memory impacts at the cost of losing detailed change information and the ability to undo (revert) the changes. Working copy graphs and existing change histories are not affected by this setting.

Root Class (of Hierarchy)

For a given Lineage Model, Manage > Root Class of Hierarchy lets one reset which class will be the root of its Class Hierarchy whenever someone edits the Lineage Model (for example, if the Lineage Model specializes a standard class, perhaps its custom class's ancestors should not show).

Local Search Options

When searching a vocabulary or asset model, there is an option, Return local results only, which excludes results that come from other models via include references. (A local search only delivers resources having their rdf:type triple in the base graph.)

By default, users can choose for themselves whether to enable or disable this local results option on any particular search. However, managers of a given vocabulary/asset can permanently set this option as either always local or always global for all users. If set by a manager, then users will still see the setting value on their search panes, but they will not be able to change it.

Enable Per-Asset Governance Roles

When checked, this option allows editors to assign governance roles at the level of individual assets. When enabled, editing a selected asset shows a section Governance Roles for this Asset, which lists available governance roles, each of which is multiply assignable to users and security roles. The roles set on an asset will pertain to any workflows directly spawned from the asset (whereas collection-spawned workflows use the collection-level role settings).

Archive Working Copies on Commit

If true, then working copies will be archived automatically when committed. (Note that the archive will always contain the full history, regardless of the Record Triple Counts only setting.)

Include this asset collection in the index for Search the EDG

Enabling this adds the collection content into the Lucene index used by the Search the EDG function.

Enable Simple Search

For very large collections, enabling this reduces editor overloading by disabling both: (1) automatic table loading and (2) advanced filters (which can have a large impact). Text filtering, based on Lucene indexing, remains available.

Configure Features

This allows managers to selectively remove particular features (functions) that will be applicable for the particular Lineage Model. Performance-intensive features are indicated. Note that all features always remain for administrators.

  • No labels