Hi Andy, I've committed the code according to your suggestion. The server side only runs QueryExecutionBase::execConstructQuads().
I've also hacked QueryEngineHTTP to test the conneg of execConstructTriples() and execConstructQuads(). For execConstructQuads(), all of the content types in DEF.quadsOffer have been tested: if the client sends Accept content type of, e.g. TriG, the sever will response with the desired same content type. Please check the PR 91: TestQuery.query_construct_quad_conneg() regards, Qihong On Tue, Aug 18, 2015 at 4:26 PM, Andy Seaborne <[email protected]> wrote: > On 18/08/15 08:44, Qihong Lin wrote: >> >> Hi Andy, >> >> Thank for your comments! I can understand your idea of A/ B/ C/. But >> there'a problem in practice. >> >> In brief: >> For A/, at the server side, always call >> QueryExecutionBase::execConstructDataset() >> For B/, the problem is, there're overlaps between DEF.rdfOffer and >> DEF.quadsOffer, e.g. TriX, TriXxml and JSONLD. >> For C/, e.g. if the Accept lang is JSONLD, which should be written out >> by RDFDataMgr, model or dataset? Note that, the server side doesn't >> know which it's called from the client side, >> QueryEngineHTTP::exeConstructTriples() or exeConstructQuads(). > > > I wrote: >>> a combined DEF.rdfOffer+DEF.quadsOffer > > Create a new offer which combines all the languages you want. > DEF.constructOffer. > > If the language is quad-supporting, RDFLanguages.isQuads is true, process as > a dataset regardless. > > It does not matter if the client is asking for a model or a dataset because > in all syntax cases, a dataset of just the default (the unnamed) graph looks > like a single graph. This is while you can generalise to work in datasets > for much of the processing. The default graph in a datasets is written as > just triples without a graph field. > >> Also at the client side, if >> QueryEngineHTTP::exeConstructTriples()/exeConstructQuads() gets the >> content type of, e.g. JSONLD, it doesn't know whether it is a model or >> dataset. > > > If they call execConstructTriples, then either the CONSTRUCT query will only > have a default graph template or it's an extended syntax query and you want > the default graph. In both cases, parse to a steam of triples. The parsers > skip named graphs when they are asked for triples only. > >> So, that's why I introduce the DEF.pureRdfOffer to distinguish the >> triple format that is not a quad format. In my way, both the sever >> side and the client side separate model and dataset. It's kind of ugly >> in code. Any more suggestion? > > > That would probably also work but it is not what the code is doing in > SPARQL_Query. It just offers DEF.pureRdfOffer and then tests for *. There > is no datasets content negotation possible (e.g. n-quads vs Trig) because > the process can't get to ResponseDataset with application/n-quads set, say. > The only way I can see to get there is a Accept-type of "*" in SPARQL_Query. > > Try it in a debugger. > > hack to run Fusek2 clean in Eclipse (string names need changing): > > public class DevFuseki2 { > public static void main(String[] args) { > String DIR = "/home/afs/ASF/jena-491/" ; > System.setProperty("FUSEKI_HOME", > DIR+"jena-fuseki2/jena-fuseki-core") ; > String fusekiBase = > "/home/afs/ASF/jena-491/jena-fuseki2/jena-fuseki-core/run" ; > System.setProperty("FUSEKI_BASE", fusekiBase) ; > String runArea = Paths.get(fusekiBase).toAbsolutePath().toString() ; > // **** Delete any previous state. > // FileOps.ensureDir(runArea) ; > FusekiCmd.main() ; > System.exit(0) ; > } > } > > > Andy > > >> >> regards, >> Qihong >> >> On Mon, Aug 17, 2015 at 10:49 PM, Andy Seaborne <[email protected]> wrote: >>> >>> Thanks for the clarification. I had made a combined version to start >>> testing and hopefully it's a close approximation of the intended >>> deliverables. >>> >>> [ Ying - how's your testing going? ] >>> >>> A few things about the pull requests so far: >>> >>> 0/ More tests in TestQuery in Fuseki: >>> >>> For example, this should show up: >>> >>> 1/ QueryEngineHttp.execConstructDataset is not implemented. >>> >>> >>> 2/ SPARQL_Query: >>> >>> This line >>> >>> if ( ! rdfMediaType.getType().equals("*") ) { >>> >>> means that only "Accept: *" will trigger dataset results. >>> >>> then in ResponseDataset >>> >>> MediaType i = ConNeg.chooseContentType(request, DEF.quadsOffer, >>> DEF.acceptNQuads) ; >>> >>> will always choose TriG because the accept is "*" ("output=" works but >>> that >>> is overriding content negotiation). >>> >>> There is no way to ask for a specific syntax (n-quads, trig, JSON-LD) >>> using >>> "Accept:" >>> >>> e.g. "Accept: application/n-quads" >>> >>> >>> 3/ ResponseDataset is copy of ResponseModel yet the only differences >>> (after >>> reformatting) are different data values and >>> >>> < RDFDataMgr.write(out, dataset, lang) ; >>> --- >>> > RDFDataMgr.write(out, model, lang) ; >>> >>> It is not good to have copied code because it makes maintenance harder. >>> >>> >>> >>> (2) and (3) can be addressed by >>> >>> A/ SPARQL_Query: >>> >>> For CONSTRUCT, always work in datasets; execConstructDataset(). >>> No need for mention of Models. if it's a triples CONSTRUCT, treating as >>> a >>> dataset will simply put the results in to the default graph. >>> >>> QueryExecutionBase::execConstructQuads >>> >>> Following on from that, treating datasets as a natural extension of >>> models. >>> There is no need to test for extended syntax. If it's strict SPARQL 1.1, >>> a >>> dataset will just have only a default graph. >>> >>> >>> B/ Content negotiate for a combined DEF.rdfOffer+DEF.quadsOffer (I don't >>> underatand DEF.pureRdfOffer -- N-triples is a standard). >>> >>> C/ If it's a triple format (test the Lang), >>> >>> RDFDataMgr.write(out, dataset.getDefaultModel(), lang) ; >>> otherwise: >>> RDFDataMgr.write(out, dataset, lang) ; >>> >>> >>> Andy > >
