Hi Andy, again, you make very interesting remarks.
> Le 23 nov. 2015 à 11:00, Andy Seaborne <[email protected]> a écrit : > > On 22/11/15 14:17, François-Paul Servant wrote: >> Andy, >> >> I improved my test (running on the same file): several runs, RDFFormats >> variations… Results and code below (SSD disk, otherwise 5 years old mac >> powerbook) >> Main fact remains: JSON-LD serialization is slow (~10 times slower than >> turtle). But people want JSON-LD. I think I’ll have a look at javascript to >> convert turtle to JSON-LD in the browser. >> > > Do they really want idiomatic JSON and JSON-LD? i.e. JSON-LD that looks like, > and can be used as, JSON? well, maybe I should have said: people want JSON, and I want to give them RDF (they just still don’t know that they need RDF - but they do) ;-) > An RDF model output to JSON-LD is not very JSON-ish (depends on the RDF shape) > > To get the more natural JSON aspect, I've had some success with a simple > pipeline of SPARQL SELECT to JSON-LD (this is not CONSTRUCT as JSON-LD). > > SELECT ?var1 ?var2 ?var3 .... { > ?x :property1 ?var1 ; > :property2 ?var2 ; > :property3 ?var3 ; > ... > } > > and then output something like: > > { @context { ... } > "@id" : "request-id" , > "documentation_api" : "http://URL-of-API-documentation"; , > "documentation_data" : "http://URL-of-data-documentation"; , > "data" : { > "property1" : value-of-var1 , > "property2" : value-of-var2 , > "property3" : value-of-var3 > } > } > > which is a bit of metadata about the request and the data from the query. > It's more JSON-like and the details of syntax are more controlled which is in > keeping with JSON. It's predictable so JSON access by path can be used. yes, I have been thinking about something like that: (if I understand correctly) generating the JSON-LD “by hand”, which allows to control how it looks like. In my use-case, the results to be returned to the client are computed as a jena model : they are not the results of just one SELECT query, but the result of a more complicated process, involving SPARQL queries and computation using other services - something that “naturally" returns a jena model (for several reasons: because it’s well adapted to the problem, because I re-use old code built with jena, and because I like it!). So, the easiest thing to do was to just serialize the result with jsonld-java. > > c.f. XML and RDF/XML > > > // warm it up > > System.out.println("*** WARM-UP ***"); > > for (RDFFormat format : formats) { > > doIt(m, format, 1); > > } > > May not make a difference here but a warm-up of one is not enough to get all > the overheads accounted for. It will have caused class loading, a > significant cost, but not caused all the JIT work to have been done. > > For predictability, writing to a null output stream (or to /dev/null) > isolates the test from the vagaries of local I/O. thanks for the advices fps
