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 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).
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.
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.
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.
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.
Thanks for all the replies and sorry for my late answer. I needed time to digest everything.
Concerning global configuration, I will have to implement it but I’m trying to make things work without it at first. I’m not sure about TRS yet as I need to understand more things about OSLC.
So, all the information was really useful. I’m now using the jazz_am for the types of links.
Also, I handled the put request from Polarion and created a back link.
Afterwards, I tried my implementation against DOORS next. It’s not working as expected. I found out that DOORS is using link discovery to find already existing links on the am side (I guess it parses all the resources inside my resource provider and tries to find some relevant links). I cheated and programmatically created a link to DOORS on the am, and it’s showing in DOORS (I have duplicate but that is not my main issue yet).
I now understand why backlinks are not necessary.
I don’t have an OSLC consumer yet, so I can’t use link discovery on my am yet, also I need the links to be created from the DOORS interface.
So I wonder if it’s possible to configure DOORS to send a put request to my provider when I try to create the link from DOORS.
From what I can see from the logs, after I try to create a link from doors like implemented_by. DOORS is performing 2 oslc query. The first one with something like dcterms:references in [] and a 2st one with *=.
What is the purpose of these requests ? Is it only to verify that the link already exists on the am side ? Should I create my link after the queries ?
