# Data Model URIs

> Gives every artifact type, attribute, data type, enumeration value and link type of a project a consistent URI from one pattern, with a full preview before anything changes.

Source: https://widgets.doorsnext.com/widgets/data-model-uris/

- Discipline: Configuration and governance
- Works in: IBM DOORS Next module
- Supported products: RM (IBM Engineering Requirements Management DOORS Next (Requirements Management))
- Changes data
- Keywords: assigned URI, type system URIs, data model URIs, RDF URIs, artifact type URI, attribute URI, enumeration URI, OSLC, global configuration, reporting, naming convention, camelCase
- Version: 1.14 (Released 2026-10-27)
- Vendor: SmarterProcess (https://doorsnext.com, info@smarterprocess.pl)
- Workflow: 1. Open the project in a change set → 2. Enter the domain, prefixes and name formats → 3. Previews every URI and the conflicts (If needed: Conflicts: change a prefix or format) → 4. Set URIs: saved in the data model → 5. Change report in Excel

## What it is and why it exists
Every artifact type, attribute, data type and enumeration value in a DOORS Next project can carry a URI. These URIs are what reports, publishing templates, OSLC integrations and global configurations rely on to recognize "the same" attribute or type in different projects and streams. Without them, each project has its own internal identifiers and work across projects breaks down.

Setting URIs by hand in the project properties means opening every definition one by one, typing a URI and keeping the naming consistent. For a real data model that is hundreds of entries and hours of work in which typing errors creep in. Data Model URIs does it in one step, with one naming scheme for the whole model.

## Problems it solves
- Data models without URIs, so reports, integrations and global configurations cannot match types across projects.
- URIs typed by hand with inconsistent spelling, prefixes and capitalization.
- Duplicate URIs that block the data model or confuse reporting.
- Hours spent in the project properties for a task that follows a simple rule.

## Benefits
- **One pattern for the whole model:** your domain or server, a prefix per group and a name format (camelCase, PascalCase, snake_case or kebab-case).
- **See before you change:** live examples while you set the pattern, and a preview of every URI with its status.
- **Safe by design:** existing URIs are kept unless you choose to replace them, and conflicts are never written.
- **Enumeration values and link types included,** each enumeration value under the URI of its data type.
- **Excel exports** of the preview and of what each run changed, for review and audit.

## How to use
1. Open the project in a change set (recommended) or a stream. The widget reads its data model.
2. Click **Change** at **URI pattern** and enter your domain or server, for example `https://example.com/ns`, then choose a prefix and a name format for each group. The examples follow your choices.
3. Review the preview: new URIs, URIs already set, URIs kept and any conflicts. Tick **Replace URIs that are already set** if existing URIs should change. Export the preview to Excel if others should check it.
4. Click **Set URIs** and confirm. Progress is shown and you can stop at any time.
5. Download the change report with **Log** in the result block and deliver the change set when you are satisfied.

## Good to know
- We recommend working in a change set, so the new URIs can be reviewed and discarded before delivery. A baseline cannot be changed.
- Names are turned into clean URI words: accents are removed and spaces, dashes and capital letters separate words.
- Typical uses: preparing a project template, harmonizing projects before a global configuration, and enabling reporting and OSLC integrations.
- Definitions that DOORS Next owns, such as system attributes, are shown as read only and never changed. The states of workflows are not listed, because DOORS Next does not let their URIs be set this way.