Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Setting URIs for Artifact Types and Artifact Attributes when using project to develop a template?

Questions
Tags
Users
Badges
Mary Miller
(87●2●32) Jan 31 '20, 10:16 a.m.

Good day,


I am considering setting up a project template for a small team of people to make things easier when they have to setup a project.  Given the number of things that need to be set up, it is very easy to accidentally introduce inconsistencies.  

One of the things that I have consistently impressed upon them is ensuring all Artifact Types, Artifact Attributes, and Attribute Data Types have a URI.  

We have a naming convention that starts with the url example:  https://<our RMS site>/<Project Name>_<attribute name>

However, the problem with this naming convention is that they would have to ensure the URI would be altered for every Artifact Type, Artifact Attribute, Attribute Data Type, and each of the values associated with the Attribute Data Type.  This would also be prone to inconsistencies as well (we are all human).  It would also be very tedious and repetitive.  NOTE:  I do not have access to scripting this.  I would prefer to have something set up to minimize the inconsistencies.

What naming convention do other people use for their URIs that can be used as part of a Project Template?

Sincerely,

Mary

0 votes

4 answers
1,513 views
0 votes

Accepted answer

Permanent link
Davyd Norris
(3.0k●2●19) edited
Feb 06 '20, 5:18 p.m.
The approach i have always used with my clients when defining URIs is:

https://<organisations web URL>/rm/<prefix>/<name of element in CamelCase>

where prefix is:

types = Artefacts
attrs = Attributes
dataTypes = Data Types
links = Links

and then for each enumeration I use:
https://<organisations web URL>/rm/dataTypes/<name of element in CamelCase>#<value name in CamelCase>

The key thing about using URIs is that if you don't explicitly add one, then a unique internal one is generated. This means that artefacts or attributes that are the same across project areas will be treated as unique when you try to copy artefacts between projects, in the Data warehouse, and in the LQE warehouse. It is also critical to have URIs when you export and import via ReqIF.

The implications for the latter are that DW reporting sometimes gives you strange results because you can't select the correct attribute, and in LQE reports the same attributes from different project areas won't end up in the same column by default.

When you are trying to manage a global RM schema for your organisation, adding a URI lets you establish that across your world.
Mary Miller selected this answer as the correct answer

0 votes

Comments
Mary Miller
Feb 06 '20, 1:13 p.m.

I really like this method.  This is very simple and clear.

3 other answers

Permanent link
Sean F
(1.3k●2●52●162) edited
Jan 31 '20, 10:47 a.m.

Hi Mary,

One of the key benefits that you get when you assign a URI to your artifact and attribute definitions in a DNG project is that you can then copy data to or from another project which is using the same schema using various methods and the data will then use the existing definitions (artifact or attribute) instead of trying to create duplicates.

When I set up a schema a normally assign the same database-wide common URI to attribute and artifact definitions in different projects for this reason, rather than creating project specific ones.

Creating project specific ones is also more time consuming (if the common URIs are in a template they can be easily re-used) and more prone to error.

0 votes

Permanent link
Mary Miller
(87●2●32) Jan 31 '20, 11:13 a.m.
Okay, that makes sense.  This brings up another question.

First, it sounds like it would be better to use the naming convention of https://<DOORS NG URL>/<Artifact Attribute Name>

Let's say I have the following scenario:
So, if I have a Project A that has the minimum attributes (where all URIs are set), and Project B that has the same minimum attributes (where all URIs are set).

However, Project A has a significant number of attributes that I want to use in Project B.  From Project B, I decide to Import Project Properties from Project A.

How would this impact this impact the URIs where the Artifact Types, Artifact Attributes, and Data Types are the same?

Also, for linking between projects or developing Reports across projects, how does DOORS NG know the difference between the URIs in the common, say, Artifact Attributes used in Project A and Project B?

I think there is a piece I am missing, and I want to make sure the URIs would not "clobber" each other.

Sincerely,

Mary

0 votes

Comments
Ian Barnard
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 03 '20, 10:15 a.m.
Hi Mary
> it would be better to use the naming convention of https://<DOORS NG URL>/<Artifact Attribute Name>
Note in particular that these say that you must not use the actual hostname of your server in your URIs.
The 7.0 version of that page shows that these limitations are being largely removed.

HTH
Ian

Ian Barnard
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 03 '20, 12:24 p.m.
And on the topic of managing your type system across many projects, there is an article here: https://jazz.net/library/article/92352

Many of the principles in that article still apply when Configuration Management isn't being used.

Mary Miller
Feb 05 '20, 10:03 a.m.

Okay, cool.  I think I am good to go now.  Thank you for the clarification!!

Permanent link
Sean F
(1.3k●2●52●162) Jan 31 '20, 12:13 p.m.

>>I decide to Import Project Properties from Project A.
What method would you be using to import project properties from A to B?

If it is ReqIF, then, having matching URIs means matching definitions will be recognised and will not create unwanted duplicates.

One of the key purposes of URIs is specifically to mark matching definitions across multiple projects as the same for this kind of operation.

>> how does DOORS NG know the difference between the URIs in the common, say, Artifact Attributes
There should not be any difference between attributes which share the same URI across multiple projects. You should keep them identical.

0 votes

Comments
Mary Miller
Jan 31 '20, 1:34 p.m.
There is an Import Project Properties button in the Project Properties part of the project.  It indicates that if both projects have properties with the same name, the properties will be merged in the current project.  No properties would be deleted from the current project. 

This is the hyperlink button next to the Migration tab/link.

It's a quick way to get various attribute elements copied from one project to another.  However, I don't plan on training anyone on using it since I haven't fully tested.

However, it sounds like if both projects are using the same attribute elements but the attribute elements have different URIs, you could end up with duplicate attribute elements which is not desired.

This might be something I have to test to fully understand URIs and how they work.

Thank you again!

Mary


Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,025

Question asked: Jan 31 '20, 10:16 a.m.

Question was seen: 1,513 times

Last updated: Feb 06 '20, 5:18 p.m.

Confirmation Cancel Confirm