There was no effect though, except for the “ResourceShape URL” opening a table which includes my “isReferencedBy”.
If I do a GET request on an JazzRequirement object, where I manually set some links, I do get an rdf+xml response, where isReferencedBy is included, similar to this:
<?xml version="1.0" encoding="TF-8?>
<rdf:RDF …>
<oslc_rm: Requirement rdf:about=“…”>
<dcterms:isReferencedBy rdf:resource:“…”/>
… and so on
I shortened it a bit, but essentially it is included in my response.
How would you change the 3 @Oslc fields for a custom class?
Also I found this error from IBM, which sounds exactly like mine:
Now that you linked that IBM page, I recall that DNG is very limited in its OSLC linking capabilities with non-DNG counterparts. See Links across OSLC domains for more details.
Eclipse Lyo is an unencumbered implementation of the open OASIS OSLC standards. As such, Lyo supports linking and no further work is needed in that area.
If you think that some IBM products implement OSLC not to the full extent, you can reach out and let them know that complete OSLC support, especially towards non-Jazz applications, is important to you as a customer.
Just for the record, DNG allows more than just link discovery. But as the links you and me posted show, there are quite a few caveats and limitations.
I agree, DNG probably allows both, but not for RM to external RM as it seems, which would explain why Change Tasks can be linked both ways, since according to the documentation, they do back links. My question was referring to if there already is an implementation of link discovery as code somewhere, so that I can extend my oslc-refImpl based application. Currently, my idea would be to use an OSLCClient to connect to the project area and check every requirement if it has a link to my application requirements. This however seems a bit excessive.
A code sample, which shows how to use the delegatedUI of DNG (or some other app) would probably work too, since you could set a link in my application to DNG. DNG should pick up the link from my requirements by using its link discovery (which I assume is fully implemented by IBM).
Regarding the implementation of link discovery, Jazz is the only known implementation to me. IBM has contributed the API outline to OSLC OP (see p.6 of this Google doc) but the implementation (and even access to) is still closed due to certain concerns. If this API is important to you, I also encourage you to reach out to your IBM contact and let them know you’d like them to prioritize this work.
Regarding the brute force way, I don’t think you have a way to avoid checking every requirement. However, I’d like to suggest you take a look at https://github.com/eclipse/lyo/tree/master/trs/client, which allows you to consume a stream of events representing changes to the OSLC resources from Jazz. While you will still have to do manual checks, you will have to check only the resources that were changed and do it only once for every change.
The discussion has now focused on Link Discovery. Did you solve the original problem @LyoUser then?
Link Discovery is an ongoing specification activity. So, Lyo may very well provide an implementation in the future. We will have to see once the specification is more stable.
Do you want to know about any links to any resource in your application? Or, are you searching for resources that point to a specific resource. If the later, then you should be able to call the OSLC Query operation, which should not be so expensive.
I believe Link Discovery is useful when you want to search for back-links across a number of applications. If you only have 1, Query should be sufficient.
Yeah, I am using OslcQuery with custom QueryParameters to get all requirements, which include links to my application. For now this should be enough. Therefore the original problem can be considered as solved.
Could you possibly provide a short summary of the final solution, since I am sure others might face a similar problems. This long thread explored many things, and I (for example) am not sure exactly what the solution was.
To me, it seems that the problem was that it was not possible to create a link from DNG using DelegatedUI from another OLSC Server! What did you finally do to make it work?
@jad
Sure. The inital problem was that I could not set links in DNG even though my custom provider application was showing up and displaying my custom requirements. This wasn’t a problem with either tool, I was just putting the link in the wrong field. For requirements it is the “referenced” field.
After I fixed that, I noticed that the link only existed in DNG but not in my application. At first I thought it was due to my requirements missing the field “referencedby”, which I fixed by extending the Requirements class from Lyo and creating a new one with the fields. However this did not solve the problem.
The reason for that is that there are two types of how the link communication can work. Either through “back links” or else through “link discovery”. “Back links” was what I was looking for, but DNG uses “Link discovery”. This means that DNG sets and saves the link in itself and then expects the other custom application to look up where it is connected to.
I solved this by using an “OSLCQuery” from eclipse lyo. The query gave back the DNG requirements to which I am linked too and I manually set them into the “referencedBy” field. It have it set to always look up the linked requirements every time the “requirement” website refreshes.