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 <a...@apache.org> 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
