Oslc links & TRS

Hello,

I’m having issues figuring out the right way to implement links.
I implemented an OSLC AM provider and I’m doing some tests with Polarion.

For now I can link requirements to my AM resources (I don’t know how Polarion store this information).
On the AM side, I would just store the URI of the requirement in the corresponding AM resource (without using OSLC AM model)
I saw that there is a linkType Resource, should I create a linkType Resource for each links ?
linkType Resource does not specify a “source” and “target” for the link, should I add theses properties ?
Are the links meant to be bidirectional ? Like if I create a link in Polarion, should I create the opposite in my AM resource ?

About tracked resource set, I’m not sure how it is used. Is the goal to regroup resource by a criteria ?

I hope my questions are somehow understandable.

I may not be answering the right question, but will take a stab at it. If I understand the in-work 3.0 link guidance, the “source” is the Subject (link initiator) and the “target” is the Object with the link type being the Predicate. The guidance also states that links should only exist once, so they’re not bidirectional. In fact, section 2.1.3 (Store link information in once place) goes into some good detail about why you don’ t want that. Hope that helps some.

I believe by LinkType you are referring to is OSLC Architecture Management Version 3.0. Part 3: Constraints. This seems to have a different intention than what you are trying to do. And, indeed it does not have source/target properties (again, because it is meant to be used to define types of links. and not links themselves).

But from the AM:resource (OSLC Architecture Management Version 3.0. Part 3: Constraints) have you considered using any of the already defined properties such as jazz_am:refine, jazz_am:elaborates, `jazz_am:trace, etc.

These seem to me to be where you might want to store the link back to the Polarion requirement.

Otherwise, it also seems to me that there is some confusion between how to store links to other resources and how to expose them when sharing an OSLC resource.

How to store them should be completely up to your application. The above tips relate to how to share the link to the Requirement from the AM resource,

Finally, agree with Jim that links should only exist once, so they’re not bidirectional. So, if Polarion creates a link to your AM resource, you should avoid having that Link handled from the AM resource.
Having said that, I do also know that Polarion sends a PUT request to your AM provider with the created link so that you can update the AM resource accordingly. (But I normally ignore handling the request. There are no expectations to update the target resource)

Bidirectional links are essentially links without semantic directionality. For example, you might say change request A --relatedTo–> change request B, or change request B --relatedTo–> changeRequest A, and they semantically mean the same thing. For reporting on bidirectional links, you usually query both directions.

On the subject of Tracked Resource Set, I recommend you read Tracked Resource Set 1.0 Primer as it explains usage with examples, and is much easier to get started with than the normative spec itself.

Hi @Michael.C

Below are some opinions based on more than a few OSLC implementations we’ve done at SodiusWillert.

Since you are targeting Polarion, I would have a different take on this.

  1. Polarion does not support global configuration, so pretty much like in ELM: if you are not in GC context, you are totally right creating links AND backlinks. Polarion does not support link discovery, so you are not expected to create a TRS feed to help in that area. It will not.
  2. Polarion does not provide support for TRS. If you were into reporting rather than just linking, I would recommend looking at the reporting features in the latest Polarion releases that provide some support for doing reporting over OSLC links available in Polarion. They have link appearance like we do in OSLC Connect for Jira, as well as Tables. We’ve built a help desk for our customers and more with pretty good knowledge about OSLC tools usage (and obviously how all of that goes with our implementations!). You can read our Siemens administration specific articles at Siemens Tools. This is a work in progress help desk, it’s growing every other week, so you can also check back from time to time.

Hope that will help :slight_smile:

1 Like