I hope that you're using discovery to determine the URI of an appropriate OSLC query capability rather than hardcoding or manually constructing such URIs. You should start with the with rootservices document to discover the URI of the OSLC Service Provider Catalog.

For example, from https://jazz.net/jazz/rootservices the response includes:

  <jd:oslcCatalogs>
        <oslc:ServiceProviderCatalog rdf:about="https://jazz.net/jazz/oslc/workitems/catalog">
            <oslc:domain rdf:resource="http://open-services.net/ns/cm#"/>
        </oslc:ServiceProviderCatalog>
  </jd:oslcCatalogs>

A GET on https://jazz.net/jazz/oslc/workitems/catalog (the OSLC Service Provider Catalog) with Oslc-Core-Version=2.0, Accept=application/rdf+xml returns the OSLC Service Provider catalog for EWM Change Management. This includes multiple OSLC service providers - one for each project area. So you have to discover which is the service provider for the project area of interest. For example, the service provider for the "Jazz Reporting Service" project area (expressed in Turtle) is:

 <https://jazz.net/jazz/oslc/contexts/_wWBVEBErEeWivdxTwnA1kg/workitems/services.xml>
        a                          oslc:ServiceProvider ;
        jazz_disc:messageReceiver  <https://jazz.net/jazz/web/com/ibm/team/workitem/web/EWMWorkitemsCopyHandler.html> ;
        jfs_proc:consumerRegistry  <https://jazz.net/jazz/process/project-areas/_wWBVEBErEeWivdxTwnA1kg/links> ;
        jfs_proc:globalConfigurationAware "compatible"^^rdf:XMLLiteral ;
        jfs_proc:supportContributionsToLinkIndexProvider "true"^^rdf:XMLLiteral ;
        jfs_proc:supportLinkDiscoveryViaLinkIndexProvider "false"^^rdf:XMLLiteral ;
        oslc:details               <https://jazz.net/jazz/process/project-areas/_wWBVEBErEeWivdxTwnA1kg> ;
        dcterms:title              "Jazz Reporting Service"^^rdf:XMLLiteral .

A GET on https://jazz.net/jazz/oslc/contexts/_wWBVEBErEeWivdxTwnA1kg/workitems/services.xml with Oslc-Core-Version=2.0, Accept=application/rdf+xml returns the details of that service provider. That service provider defines an OSLC service which declares the following OSLC query capability (expressed in Turtle):

        oslc:queryCapability
           [ 
            a                   oslc:QueryCapability ;
            oslc:queryBase      <https://jazz.net/jazz/oslc/contexts/_wWBVEBErEeWivdxTwnA1kg/workitems> ;
            oslc:resourceShape  <https://jazz.net/jazz/oslc/context/_wWBVEBErEeWivdxTwnA1kg/trs/shapes/workitems/query> ;
            oslc:resourceType   <http://open-services.net/ns/cm#ChangeRequest> ;
            oslc:usage          oslc:default ;
            dcterms:title       "Change request queries"^^rdf:XMLLiteral
            ] ;

You can find information about OSLC discovery in OSLC Core Version 3.0: Part 2: Discovery.

A GET on that base URI with Oslc-Core-Version=2.0, Accept=text/turtle returns a query response in Turtle. You can choose application/rdf+xml or other supported RDF media types.

Note that since OSLC is a set of RDF-based specifications, you should be asking for RDF content in your Accept header. While some OSLC endpoints might accept application/json , this is not an RDF representation is therefore not defined by OSLC. The EWM query base shown above will accept Accept=application/json and return JSON, but the format of this is not defined by any OSLC specifications. Some endpoints might not accept application/json . There is a media type for RDF expressed as JSON: application/ld+json . However, not all REST endpoints might accept it. For example, the EWM query base above does not. OSLC clients should therefore ask for RDF content by specifying a supported RDF media type in the Accept header, and then parse the RDF in the response body.

The best way to debug things like this is to use a web browser plugin such as RESTED, Postman etc. Get that working first. Then if your Java client code is doing something different, you will have to debug your Java code.