ServiceProviderCatalog discovery not working with DNG


I am new to OSLC/lyo and the @Oslc… magic lyo is using. Bear with me, if I my mistake is obvious.

I use a recent DNG 7.0.2 and I try to use the ETMSample (changes certain locations from QM to RM) after fetching the rootservices it’s loading the catalog from ttps://

<?xml version="1.0" encoding="UTF-8"?>

xmlns:dcterms=“DCMI: DCMI Metadata Terms
<oslc_disc:details rdf:resource=“”/>
<jp:consumerRegistry rdf:resource=“”/>
<oslc_disc:services rdf:resource=“”/>


Which looks like this specification is followed:

If I read the class ServiceProviderCatalog I could easily imagine that this specification is followed:

In line 443 of OslcClient happens the magic to convert this response to a ServiceProviderCatalog
ServiceProviderCatalog catalog = response.readEntity(ServiceProviderCatalog.class);

In this catalog object the number of ServiceProviders is 0 (catalog.getServiceProviders().length==0).

Obviously lyo is expecting a newer version of the standard than what DNG is providing.

Is there a chance to have a switch to distiguish between these two ServiceProviderCatalog versions?

Could one construct a 150% ServiceProviderCatalog to also digest the DNG Version?

Can I solve this as a user of the lyo API?

How would one model the oslc_disc:entry?

Would one use an intermediate class entry and then the ServiceProvider or can I kind of “grab-all” ServiceProvider?

Is there a chance to peek into the response to “know” which class to use to decode the response?

Thanks for any help and Kind Regards


to hint someone in the future with the same problem:

DNG is serving the above file in the browser if asksd for RDF like oslc is doing, the right contents is served, with different structure.

The root cause was that the used user for testing didn’t have access to any Project Areas.

Kind Regards

1 Like

So is this problem solved? it was not an issue with Lyo after all?