Using my OSLC client I'm creating links from a external URI to a DOORS and DNG resource using every known link type in the OLSC-RM spec.  Both DOORS and DNG return a 200 http response indicating the link was created successfully but the fact is the tools don't behave the same way.  Nor actually persist the link in the case of DNG.

Anyway, both products suggest they support the following link types with the 200 status when the OSLC client updates the resource...

elaboratedBy
elaborates
specifiedBy
specifies
implementedBy
affectedBy
trackedBy
validatedBy
satisfiedBy
satisfies
decomposedBy
decomposes
constrainedBy
constrains

In reality they don't fully support them at all.  DNG doesn't render or store the following link types...

satisfiedBy
satisfies
decomposedBy
decomposes
constrainedBy
constrains

DOORS has issues with the same 6 link types as DNG but does a little better jobs.  It renders them in the UI as "External Links" but that means you can't distinguish between the link types.  It does do a good job of delivering back with the appropriate link type on a RDF GET.

So what is it with IBM and these particular link types?  Further why is a 200 response received when the tools aren't actually supporting them in the UI or storing them at all in the case of DNG?

Maybe there's an issue with the underling Lyo API I'm using to create these 6 link types.  But the fact is if a provider says it's successfully store then it should render appropriately.

It's has become increasingly clear to me these particular tools (especially DNG) are missing the mark on OSLC compliance.  See this, this and this.

Thoughts? Comments? Feedback is welcome.