repitition of versioned artifacts in reports

When working with projects that are enabled for configurations, you should always use a global configuration if you are creating links between artifacts (requirements and test cases) that reside in different projects (or tools). The global configuration should be associated with a single stream (local configuration) from each project. Links (artifact references) must always be stored using the concept URI (not the versioned URI). This allows child streams in one or both projects to still find the links to the corresponding artifact in the child stream (a global configuration is associated with the child streams).

If your tool supports both configuration enabled projects and non-config projects you should only publish versioned resources (RDF graphs) for the artifacts for both types of projects. Meta-data such as resource shapes, can be published as un-versioned resources (although some tools like DNG publish versioned resource shapes ... one for each stream). When a query is run against a configuration (local or global), only the versioned resources referenced in the "selections" for that configuration are examined along with all unversioned resources. Therefore if a non-config project published un-versioned resources, a query running against a configuration could incorrectly pick up values from those un-versioned resources.

In a non-config enabled project, only one versioned resource should exist in LQE for any artifact. If the artifact is modified in the tool, either update the existing versioned resource in LQE or delete the existing versioned resource and create a new versioned resource.

In a config-enabled project, there can be multiple versioned resources for the same artifact (same concept URI) but any local configuration (stream or baseline) should only refer to a single version of an artifact. If the artifact is modified, a new versioned resource is published and the “selections” resource for that configuration must be updated by removing the reference to the previous version and adding the reference to the new version (this is typically done using a TRS patch event instead of updating the entire “selections” resource). If a previously published versioned resource is no longer referenced by any stream or baseline, it could be deleted from LQE, but the necessary bookkeeping to determine this could be complex.

In Report Builder, there are 2 types of LQE data sources: (a) the normal LQE that uses the “all-data” endpoint, and (b) the LQE scoped by a Configuration data source. The normal all-data LQE data source can see all resources, including the multiple versioned resources for a given artifact. Thus if you are running a report against projects that are not enabled for configurations, you must use the normal LQE data source in RB and MUST limit the scope to only those non-enabled projects. If you are running a report against projects that are config-enabled, you must use the LQE scoped by a Configuration data source. when you run the report, you are prompted to choose a configuration. When running traceability reports, you must always choose a global configuration that is associated with the local configurations from the corresponding projects.

In order to prevent empty traceability reports across projects, if a local configuration is associated with at least one global configuration, the RB configuration picker will not allow you to select that local configuration because it would restrict the results to only half of the resources in the traceability path.