Ldx implementation for Configuration enabled CLM provider
I have developed a configuration enabled CLM provider. It is working fine and i can add artifacts from my provider to Jazz's QM module, all in the context of a Global Configuration.
I have followed the link for this implementation: https://jazz.net/wiki/bin/view/Deployment/IntegratingWithConfigurationManagementEnabledCLMApplications
This page says that your application should adopt ldx in order to get link information. What does this adopt mean, to consume or to provide ldx feed?
Currently the links between our artifacts and the artifacts from Jazz's QM module are not being stored in our application. My question is how can we store the links, in our application? Do we need to consume Jazz QM's ldx feed to get the link information? Should we also provide an ldx feed from our application, in order for Jazz's ldx module to consume it?
Another question is: if we delete some link (between qm's artifacts and our application's artifacts) from our application interface and reflect the change accordingly in our ldx feed, will jazz remove the link from it's QM module by processing our ldx feed?
@davidhoney @fryerk
I have followed the link for this implementation: https://jazz.net/wiki/bin/view/Deployment/IntegratingWithConfigurationManagementEnabledCLMApplications
This page says that your application should adopt ldx in order to get link information. What does this adopt mean, to consume or to provide ldx feed?
Currently the links between our artifacts and the artifacts from Jazz's QM module are not being stored in our application. My question is how can we store the links, in our application? Do we need to consume Jazz QM's ldx feed to get the link information? Should we also provide an ldx feed from our application, in order for Jazz's ldx module to consume it?
Another question is: if we delete some link (between qm's artifacts and our application's artifacts) from our application interface and reflect the change accordingly in our ldx feed, will jazz remove the link from it's QM module by processing our ldx feed?
@davidhoney @fryerk
Accepted answer
Hi Saqib,
Sorry, I am just seeing your question!
With unidirectional linking, one application stores the link with the resource/artifact, and publishes the link via TRS feed to the link index (LDX). The partner application does not store the link with the resource, but queries LDX when that resource is loaded/requested to see if there are any links to it, in which case, those links are rendered with the resource (so it looks like they are stored).
At this time, QM "owns" all of the links to RM. So to adopt the unidirectional model, your RM application would need to consume LDX to query the link information. You could also choose to provide a TRS feed to LDX for RM > RM links.
If a user creates a link in your RM artifact to a QM artifact, your application should request that QM create that link in its artifact. QM will then also post the link info to LDX, which your artifact can then retrieve. (The created link shows up quite quickly in DNG in this scenario, so there might be a shortcut to displaying the link initially, although I'm not sure of those details; subsequent retrievals would be via LDX.)
Similarly, if a user deletes the link from your RM resource/artifact, your application would tell QM to delete the link; the QM TRS feed would update LDX, and when your application checks LDX, there would be no link to show.
Does that make sense?
Sorry, I am just seeing your question!
With unidirectional linking, one application stores the link with the resource/artifact, and publishes the link via TRS feed to the link index (LDX). The partner application does not store the link with the resource, but queries LDX when that resource is loaded/requested to see if there are any links to it, in which case, those links are rendered with the resource (so it looks like they are stored).
At this time, QM "owns" all of the links to RM. So to adopt the unidirectional model, your RM application would need to consume LDX to query the link information. You could also choose to provide a TRS feed to LDX for RM > RM links.
If a user creates a link in your RM artifact to a QM artifact, your application should request that QM create that link in its artifact. QM will then also post the link info to LDX, which your artifact can then retrieve. (The created link shows up quite quickly in DNG in this scenario, so there might be a shortcut to displaying the link initially, although I'm not sure of those details; subsequent retrievals would be via LDX.)
Similarly, if a user deletes the link from your RM resource/artifact, your application would tell QM to delete the link; the QM TRS feed would update LDX, and when your application checks LDX, there would be no link to show.
Does that make sense?
5 other answers
Lonnie, check the OSLC TRS specification and OSLC Indexable Linked Data specification. I'm not aware of anything more specific on LDX integration at this time.
After studying a small sample of CCM, QM, and DM TRS traffic, it appears that LDX stores the "shape" of each TRS Change Resource URI in a separate named graph within the triplestore. Within these shapes are rdf#Statements that state the subject/object/predicate for a Link relationship. There does not appear to be a separate concept in the triplestore outside the named graph of shape resource for the Link instances. (This implies that LDX truly is just LQE with additional "business logic" on the outside to handle the requests for Link information.)
As you research what is the protocol (bits and bytes over the wires in particular sequences) for OSLC peers to LDX, I have recently become curious about how a peer is required to indicate which Global Configuration is the applicable context for the Change Event of a particular resource and for its Links.
As we know, there is no property in a resource itself for which Configuration applies (except for odd case of CCM that overloads the Found In or the Planned For properties to indirectly point to the Configuration through a Release paired with a Configuration).
Therefore, how should a GC-"compatible" OSLC peer publish a TRS Change Event for a resource that was updated only within the context of a specific GC Configuration? Again, what needs to published in the TRS Base and what must be found within the resources of those published URIs?
Not an Answer - a request for related information
@Kathryn where can we obtain a specification of the POST requests to LDX and of the TRS Change entries that a TRS publisher should include for Link change information?
This can be deduced with REST trials and errors and with a network packet filter - but documentation on the protocol would speed such integration work along.
Comments
I have found all the information regarding POST requests to LDX at following link:
https://jazz.net/wiki/bin/view/Main/BacklinkIndex
We have implemented this back link querying thing in our project and it is working as expected. I would be happy to answer any questions in this regard.
1 vote
Longer reply as an "Answer".
Saqib,
Thank you for the offer to share experiences.
Yes, I am aware of the BacklinkIndex page and agree it is informative. After reading it, however, I believed it was not quite applicable or sufficient. I may be wrong.
If we look at the CLM1 figure on that page, my current challenge is to get DNG1 to discover that it has a link from the "OSLC Third Party" into the "DNG1" resource. Neither the shown "Link 5" or "Link 6" is this same case.
I have observed that DNG uses a POST linkCache request to make its UI responsive while relying on eventual updates from its LDX. I have not been able to convince DNG through a combination of ServiceProvider properties to perform that linkCache update for its interaction with our ServiceProvider.
Furthermore, although I am publishing change events into the LDX (and LQE) for external resources that link with DNG resources, I have never observed even after long delays that DNG becomes aware of those links published (and queriable with SPARQL) in the LDX.
The BacklinkIndex article reads as if it would be very useful if: (1) I was implementing my own LDX or (2) my ServiceProvider was seeking to discover external links referencing its resources. Neither is my case at the moment.
Hi Lonnie,
I assume that your OSLC Third Party service provider is a DNG or RM provider not QM. Depending upon the types of service provider interacting, it is defined in following links who will own/keep the link:
Assuming that you are an third party RM provider and you are linking your resource with Jazz's DNG/RM provider in jazz's web interface. Then according to my experience, jazz only allows "References" link type for external RM resources. And in this case Jazz's DNG owns the link and it isn't supposed to query ldx/lqe to show the links at any time in the web interface. In contrast, Jazz's DNG is supposed to publish this link information to ldx via lqe. And then later on, you can query ldx and find the links to your resource (to find out with which Jazz's DNG resource it is linked). For the links that Jazz's DNG own, it queries its local database instead of ldx.
According to the above mentioned links, if your application own the link e.g. it is a third party QM provider then your service provider should have this property supportContributionsToLinkIndexProvider set to true and then you should publish your resources along with link information to lqe and then Jazz's DNG will query ldx for link information then it is supposed to show these link in its own artifacts. But I don't have practical experience of this thing, in our case Jazz's DNG owns links to our RM artifacts and it isn't supposed to query ldx for that matter.
In any case, if your providing trs feed to lqe then you can generate reports (that will include your detailed resource) which internally relies on lqe resources.
If you think Jazz's RM is supposed to show the links that your application owns and it is not showing then try rebasing the Jazz's RM trs feed
https://jazz.net/forum/questions/224236/rm-is-not-showing-links-to-the-qm-artifacts
https://jazz.net/forum/questions/224236/rm-is-not-showing-links-to-the-qm-artifacts
Comments
"... if your application own the link e.g. it is a third party [OSLC] provider then your service provider should have this property supportContributionsToLinkIndexProvider set to true and then you should publish your resources along with link information to lqe and then Jazz's DNG will query ldx for link information then it is supposed to show these link in its own artifacts..."
This is the behavior we are expecting and for which I fail to see DNG honor the protocol. Also, it is nowhere stated what DNG expects to see in the LDX TRS for such information. We can guess that it expects to see TRS Change triples whose "object" is a URI to an OSLC Resource and that additional triples have that OSLC Resource as "subject" with "predicates" of various link types with "objects" being DNG resources. But there are no examples of this.