return rdf for construct query

[nbittich]

Issue Description

Currently, it seems that the service returns application/sparql-results+json in case of a CONSTRUCT query.

It would be nice if it returns RDF format instead, to mimic the behavior of the sparql service.

Step to reproduce:

Request headers:

Accept: text/turtle, application/n-triples, application/rdf+xml;q=0.9, application/turtle;q=0.8, application/x-turtle;q=0.8, text/rdf+n3;q=0.7, application/n3;q=0.6, text/n3;q=0.6, text/plain;q=0.5, */*;q=0.1
User-Agent: Apache-Jena-ARQ/3.17.0
mu-call-id: 674943706121
mu-auth-sudo: true
mu-session-id: http://mu.semte.ch/sessions/f31b0846-89c7-11eb-af07-0242ac130005
Host: db:8890

Request URI:

 /sparql?query=PREFIX++ext%3A++%3Chttp%3A%2F%2Fmu.semte.ch%2Fvocabularies%2Fext%2F%3E%0APREFIX++task%3A+%3Chttp%3A%2F%2Fredpencil.data.gift%2Fvocabularies%2Ftasks%2F%3E%0APREFIX++harvesting%3A+%3Chttp%3A%2F%2Flblod.data.gift%2Fvocabularies%2Fharvesting%2F%3E%0APREFIX++dct%3A++%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0APREFIX++adms%3A+%3Chttp%3A%2F%2Fwww.w3.org%2Fns%2Fadms%23%3E%0APREFIX++terms%3A+%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0APREFIX++cogs%3A+%3Chttp%3A%2F%2Fvocab.deri.ie%2Fcogs%23%3E%0APREFIX++mu%3A+++%3Chttp%3A%2F%2Fmu.semte.ch%2Fvocabularies%2Fcore%2F%3E%0APREFIX++nie%3A++%3Chttp%3A%2F%2Fwww.semanticdesktop.org%2Fontologies%2F2007%2F01%2F19%2Fnie%23%3E%0APREFIX++prov%3A+%3Chttp%3A%2F%2Fwww.w3.org%2Fns%2Fprov%23%3E%0APREFIX++oslc%3A+%3Chttp%3A%2F%2Fopen-services.net%2Fns%2Fcore%23%3E%0A%0ACONSTRUCT+%0A++%7B+%0A++++%3Fs+%3Fp+%3Fo+.%0A++%7D%0AWHERE%0A++%7B+GRAPH+%3Chttp%3A%2F%2Fmu.semte.ch%2Fgraphs%2Fharvesting%2Ftasks%2Fimport%2F6040A41457D6EC0008000044%3E%0A++++++%7B+%3Fs++%3Fp++%3Fo+%7D%0A++%7D%0A HTTP/1.1[\r][\n]"

Expected result:

RDF data in turtle/n3/rdf+xml/.. format

Actual result:

application/sparql-results+json format

[madnificent]

Hi, this is a great issue description. Kudos.

We're trying to limit the interfaces we supply for now, extending mu-authorization in other fields. Is this a show-stopper at this point? If not, I'd prefer to first focus on other features rather than this one, though I do think it's a sensible extension.

If we start supporting another format, I strongly suspect our best bet would be a JSON-based format. That would be the closest to the interface we supply now throughout the stack. I think JSON-LD tries to serve a different purpose. Is there another format than application/sparql-results+json that you'd prefer which neatly expresses the raw triples?

We should reconsider if this is (or starts) costing too much dev time.

[nbittich]

It is not a blocker as it can easily be replaced by a select query (tho it would be a really nice to have 😃 ).

The format sent back is not super important in the use cases I have, so json-ld would be perfect :)