More on the subject - After trying several options using Fuseki 1.3.0, I haven’t been able to arrive at one Accept header setting that results in the generation of JSON for both SELECT and CONSTRUCT queries.
It is conceivable that I could send different commands for CONSTRUCT (application/jd+json) versus SELECT (no header) but, as my system supports both SELECT and CONSTRUCT, that’s a bit inconvenient. FYI, using the Fuseki web ui, the CONSTRUCT with Output: JSON produces JSON-LD. Casting the same query as a SELECT, using Output: JSON, produces the expected resultset in JSON. Would you expect better outcomes using 2.3? If so, I’ll adapt my configs to work with 2.3 and try it. If what I’m seeing is the best outcome, I guess I’ll have to build out as you suggest. > On Sep 10, 2015, at 3:42 PM, Mark Feblowitz <[email protected]> wrote: > > >> On Sep 10, 2015, at 2:20 PM, Andy Seaborne <[email protected]> wrote: >> >> On 10/09/15 19:06, Mark Feblowitz wrote: >>> I didn’t quite care that it was JSON-LD - only that I could get json to be >>> emitted. the application/rdf+json worked for this. >>> >>> I’m using fuseki 1.0.1 at the moment. >> >> There wasn't JSON-LD in Fuseki 1.0.0 >> > > Upgraded to Fuseki 1.3.0. Seems to require Java 8. > > application/sparql-results+json returned RDF XML for me. > > The Accept header application/ld+json worked, and provides an option for > post-query transformation. > >>> >>> When you say it worked for you, was that with CONSTRUCT or SELECT? >> >> CONSTRUCT and DESCRIBE >> >> SELECT does not return graphs. >> >> application/sparql-results+json returns JSON rsult sets. >> >>> >>> >>> Now I have a wish: As I’m viewing the results as output using >>> application/rdf+json, I am noticing that it’s very basic triples. What the >>> consumer of this result really wants is a hybrid of triples and resultsets. >>> So, it produces triples as specified in the CONSTRUCT and it also >>> incorporates variable names into the JSON, as present in resultsets. >> >> Talis's RDF/json format is intentionally simple. >> >>> >>> That is, the emitted json is presented as URIs for the Subject, Predicate, >>> and Object (with additional syntax to handle sub-parts and arrays of >>> Objects). Tthe hybrid would somehow also incorporate variable names, so >>> instead of URI-S URI-P URI-O it would be something like >>> >>> { S : {id : URI-S, [ { P: {id: URI-P, [ O: {id: URI-O} ] ] }} ] } } >>> >>> where S, P, and O would be ?S, ?P, and ?O. >>> >>> Doable? Something JSON-LD might be able to handle? >> >> application/sparql-results+json ? >> >> Otherwise you'll need to add an output format. Though easier maybe 3-tier: >> use Fuseki as the database layer and have custom formatter as a webservice >> running as a logic layer. >> >> Or maybe Elda >> >> http://www.epimorphics.com/web/tools/elda.html >> >>> >>> Thanks >>> >>> >>> >>>> On Sep 10, 2015, at 1:39 PM, Andy Seaborne <[email protected]> wrote: >>>> >>>> On 10/09/15 18:20, Mark Feblowitz wrote: >>>>> Ok - >>>>> >>>>> I tested all forms that you recommended, and the one that does work is >>>>> application/rdf+json. >>>> >>>> Caveat - that's not JSON-LD. >>>> https://jena.apache.org/documentation/io/rdf-json.html >>>> >>>>> Thanks very much for the suggestion! >>>>> >>>>> Mark >>>>> >>>>>> On Sep 10, 2015, at 12:16 PM, Mark Feblowitz <[email protected]> >>>>>> wrote: >>>>>> >>>>>> That makes sense. But it doesn’t seem to work. I still get it in RDF XML >>>>>> format. >>>>>> >>>>>> I’m wondering whether the problem is with how I’m submitting the query. >>>>>> >>>>>> I’m using curl as follows: >>>>>> >>>>>> curl -v -H "Content-Type:application/sparql-query" -H “Accept: >>>>>> application/ld+json" -X POST http://host:port/ds/sparql >>>>>> <http://host:port/ds/sparql> -d … >>>> >>>> Works for me (Fuseki1 and Fuseki2, latest). >>>> >>>> Which version of Fuseki? (did it have JSON-LD?) >>>> >>>> Andy >>>> >>>>>> >>>>>> Should I instead be using a URL parameter? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>>> On Sep 9, 2015, at 1:33 PM, Colin Maudry <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hi Mark, >>>>>>> >>>>>>> This is because CONSTRUCT doesn't return query results (a table >>>>>>> structure), but a graph. >>>>>>> >>>>>>> Two possibilities : >>>>>>> >>>>>>> * If you want to stick to your CONSTRUCT query and want JSON out, you >>>>>>> should request JSON-LD[1] with "application/ld+json". You can also >>>>>>> try "application/json" or "application/rdf+json" to get RDF/JSON (I >>>>>>> never tried). According to the spec[2], you're encouraged to use >>>>>>> JSON-LD instead. >>>>>>> * If you really want JSON SPARQL results, that's a SELECT query that >>>>>>> you need to post. >>>>>>> >>>>>>> I hope it helps. >>>>>>> >>>>>>> Colin Maudry >>>>>>> >>>>>>> [1] http://www.w3.org/TR/json-ld/ <http://www.w3.org/TR/json-ld/> >>>>>>> [2] http://www.w3.org/TR/rdf-json/ <http://www.w3.org/TR/rdf-json/> >>>>>>> >>>>>>> >>>>>>> On 09/09/2015 18:58, Mark Feblowitz wrote: >>>>>>>> At my wits’ end here - when I invoke a SPARQL using curl to a local >>>>>>>> Fuseki server, and the query is a construct query, and I specify >>>>>>>> >>>>>>>> -H “Accept: application/sparql-results+json” >>>>>>>> >>>>>>>> or >>>>>>>> -H “Accept: application/sparql-results%2Bjson” >>>>>>>> >>>>>>>> I consistently get results back in RDF/XML >>>>>>>> >>>>>>>> <rdfs99:RDF >>>>>>>> xmlns:dp="http://dbpedia.org/property/ >>>>>>>> <http://dbpedia.org/property/>" >>>>>>>> xmlns:yago="http://dbpedia.org/class/yago/ >>>>>>>> <http://dbpedia.org/class/yago/>" >>>>>>>> xmlns:nsl="http://purl.org/ontology/storyline/“ >>>>>>>> <http://purl.org/ontology/storyline/%E2%80%9C> >>>>>>>> ... >>>>>>>> >>>>>>>> With no "-H Accept…”, I’m seeing triples format. >>>>>>>> >>>>>>>> In fact, no matter what I set the Accept header to, I see rdf/xml. >>>>>>>> Without an Accept: header, I see ntriples. >>>>>>>> >>>>>>>> Any ideas? >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >
