It's all about the answers!

Ask a question

Is DNG regulating OSLC provider links?

Matthew Stone (2310) | asked Jun 05 '17, 3:25 p.m.

I'm getting the impression that DNG is regulating OSLC provider link resource types. 

One reason is the OSLC provider doesn't always show up as an option in the "Create Link" pop up window.  For example, if the link type is "Satisfies" the OSLC-CM provider is not an option.  But it is an option if the link type is "Affected By".  This doesn't make sense because I can select the option to create a "Web" link in the UI for almost every link type.

Another issue is I have a OSLC client that creates links in DNG and it works fine every time regardless of the link type.  The HTTP status is always 200 after I update the resource.  The problem is when you go to the DNG UI and look for the link and it's not there but for some link types like "Elaborated By" the link is there.  Why would DNG send back a 200 if the link isn't actually created?  Or maybe it does get created in the DNG DB but the UI filters it out.  Who knows?

Finally, while trouble shooting another issue I came across the JS code below where it appears DNG can only handle or expects certain OSLC spec types...

var _56=null;
var _57=null;
So what do you do as an OSLC provider that wants to create links via a Delegated UI to resources other than what's in the OSLC-RM/AM/CM/QM spec's?  What if I wanted to produce a OSLC-CM config provider and allow the DNG user to select a OSLC VersionReference as a "Satisfies" link?  It appears the client side JS just won't allow it.

Is there a list anywhere that reflects what OSLC provider specs DNG can consume?  Is there a list of what OSLC resource types can leverage what DNG link type?  Can DNG even support linking to the OSLC-CM config spec resources?

It's a lot to ask but I hope someone will enlighten me.

Accepted answer

permanent link
Bas Bekker (1.4k4) | answered Jun 12 '17, 7:57 p.m.
edited Jun 12 '17, 7:58 p.m.

Yes, DNG does control its OSLC link types (as do the other Jazz applications as RTC and RQM). If you look at the link types tab for DNG project/component properties, you can see that the OSLC links are system defined, and have a RDF URI that has a namespace of Likewise with the RM internal links types.

This enables DNG to ensure what kind of objects will be at the other end, which can be interrogated as Linked Data and  adheres to OSLC REST operations (GET/POST/PUT/DELETE) etc. And with that you can do proper querying and reporting, viewing artifacts with trace-ability and link validity, etc. With a web link, you have no guarantee what's at the other end of the link.

Probably someone can give a more formal answer, but this should give you a good idea.

Matthew Stone selected this answer as the correct answer

Matthew Stone commented Jun 13 '17, 11:33 a.m.

Bas,  thank you. That is very helpful.

Are there any limitations on which OSLC domains DNG is capable of consuming?

Bas Bekker commented Jun 13 '17, 1:09 p.m.

Actually Jim Amsden answer was good here, maybe somewhat heavy on details, but the crux is when you add an association between DNG and other application project areas (including other DNG instances), you can select an application on a friended server, select the project area artifact container to associate with, and by DNG will check which association types are available through the service provider and matching system defined OSLC links. I think the matching takes place on the RDF URI defined on the link types.

So far as I know, DNG can do OSLC linking with DNG itself, RTC, RQM, RDM, DOORS (Classic) and other applications while the implement their OSLC services properly, ie comply with the OSLC spec for the domain they cover. On this page you can see the OSLC domains currently available.

Bas Bekker commented Jun 20 '17, 9:07 a.m. | edited Jun 20 '17, 9:07 a.m.

Matthew, also see this Knowledge Center entry on links:  DNG link types

2 other answers

permanent link
Jim Amsden (22837) | answered Jun 06 '17, 9:20 a.m.

 RDNG (and all the jazz CLM apps) use Friend relationships to connect to other OSLC servers using OAuth authentication. When a friend is established, the rootservices URL to the server is provided, and the OAuth provisional consumer key is created, and accepted. The rootservices document, which is not part of the OSLC standard, specifies a number of links to OSLC Service Provider Catalogs that are provided by the Friend server. This is how the Jazz apps initiate OSLC discovery.

Once the Friend server is established, RDNG can use the service provider catalogs in the rootservices document to create artifact container associations with its project areas. These artifact containers provide the service provider and service OSLC resources that RDNG needs in order to discover the capabilities of the Friend server. The artifact container associations are displayed in the RDNG selection and creation dialogs and are used to get the the dialog iFrame contents from the Friend server. 

The actual links that can be created by RDNG are defined by the OSLC Requirements Management Domain specification. These links are implemented in RDNG to connect to the recommended service provider resource types as defined in the domain specifications. These are not mandatory by the domain specifications, but are followed by RDNG. 

When your tool creates a link from one of your resources to RDNG, the link is stored in your tool, not RDNG. For some  properties defined in the Requirements Management domain specification, there may be defined backlinks that RDNG supports. In this case it may store such a back link when asked to provide a selection dialog for your tools to create a link. The RDNG team will have to provide you with the details of what backlinks are supported.

Current versions of RDNG provide extensibility within an artifact container (project area) to extend artifact types, attributes and links (i.e., RDF properties). Extensibility across project areas and tools is a common enhancement request.

permanent link
Lonnie VanZandt (68216) | answered Jun 07 '17, 10:57 a.m.

 I defer to Jim here.


So what do you do as an OSLC provider that wants to create links via a Delegated UI to resources other than what's in the OSLC-RM/AM/CM/QM spec's?  What if I wanted to produce a OSLC-CM config provider and allow the DNG user to select a OSLC VersionReference as a "Satisfies" link?  It appears the client side JS just won't allow it.
Since you are already implementing an OSLC-CM (config) Provider and so have the opportunity to craft your own AM Resources with their own custom InstanceShapes, you may be able to accomplish your goal by wrapping your OSLC Config Component or Configuration resources (elements within the namespace) in OSLC AM wrapper Resources. If you satisfy all of the constraints for being a provider of AM Resources in a GC-controlled system then DNG might allow you to claim that one of its RM resources is satisfied by one of your AM+CM wrapper resources.

(If you code this up and it works, share here your implementation. Like you, I'm in the midst of trying to implement an OSLC AM Provider that is OSLC Config savvy which DNG happily couples with.)

Lonnie VanZandt commented Jun 07 '17, 11:12 a.m.

 By the way, slightly related curiousity here. I'm implementing the OSLC CM ServiceProvider and its OSLC CM Services. As a provider, I must expose a Creation Factory link to an LDP Container service (where the Components and the Baselines and Streams Configurations are to published).

I'm curious about what others in the community are doing. Are you, fellow OSLC CM Provider implementor, choosing to:
  1. Turn off GC and run away
  2. Roll your own LDP Server capabilities
  3. Stand up Apache Marmotta and delegate to it
  4. Stand up Eclipse Lyo LDP Server and delegate to it
  5. Use some other third-party LDP Server (which, may I ask?)
Fellow implementors can reply to me separately if this comment is regarded as highjacking the OP's intent.

Your answer

Register or to post your answer.