- From: Claus Stadler <cstadler@informatik.uni-leipzig.de>
- Date: Sat, 07 Dec 2013 02:32:06 +0100
- To: public-rdfjs@w3.org
Hi list, >> Kind of a random thought: If I needed a SPARQL parser in Javascript at this point, I'd probably take one of the open source yacc-based ones and compile it to JS with a tool chain ending in emscripten. I bet that'd be the least work and result in (by far) the fastest parser. Just to throw in another option: There is also this Antlr3 grammar: http://code.google.com/p/sparkle-g/source/browse/trunk/sparkle-grammar/src/main/antlr3/com/googlecode/sparkleg/Sparql.g Antlr3 supposedly has a JavaScript target, but I never used it before - however I used and adopted the grammar itself for one of my projects. In regard to Antlr3, I was extremely impressed by antrworks (http://www.antlr3.org/works/screenshots/editor.jpg), which greatly helps writing and debugging grammars. If someone is aware of a similar or even better tool like antlrworks, please tell me. Maybe I find a bit of time to try out whether this grammar works with the JavaScript target (unless you strongly disagree with this option :) ) I think its neither a good nor a productive idea to write a SPARQL parser from scratch and possibly even without a parser generator. If you have prior experience and successfully finished such a project: Awesome! I didn't have the endurance when I attempted this for a private project :) >> Of course there'd be some work in figuring out the right data structures for output from the parser. My personal biased preference would be for a SPARQL parser to yield a query object similar to that of Apache Jena [*] (or maybe Sesame - both are mature frameworks). For the Jassa project, I ported several classes that represent the syntax of SPARQL queries from Jena: https://github.com/GeoKnow/Jassa/blob/master/jassa-js/src/main/webapp/resources/js/sparql/syntax/jena-sparql-exprs.js https://github.com/GeoKnow/Jassa/blob/master/jassa-js/src/main/webapp/resources/js/sparql/syntax/jena-sparql-elements.js (Note: I wrote some parts nearly 2 years ago, so its not all polished up yet). The main point of these classes is, that e.g. in contrast to plain JSON, they support variable substitution and toString(), which is something at least I need. [*] In the Java world, there is essentially Jena and Sesame; I 'grew up' with the former. Cheers, Claus On 06.12.2013 14:57, Sandro Hawke wrote: > On 12/05/2013 06:27 AM, Ruben Verborgh wrote: >> Hi Claus, >> >>> Sorry if I missed a relevant part of the discussion, but would it be possible to re-use and extend an existing SPARQL parser? >> I don't know to what extent the "Turtle" inside SPARQL graphs is/should be compatible with the latest Turtle CR (with of course the exception of variables). > > The intent of the RDF WG in standardizing Turtle (and TriG) was to make them entirely compatible with SPARQL, where the functionality aligned. Hopefully that's how it's turned out in the grammars and test cases. > >> However, if it is/should be, I see parsing Turtle as a subproblem of parsing SPARQL. >> And since passing Turtle CR spec suite has been non-trivial for many parser authors (including myself), >> I wonder how easy it is to create SPARQL parsers. > > Kind of a random thought: If I needed a SPARQL parser in Javascript at this point, I'd probably take one of the open source yacc-based ones and compile it to JS with a tool chain ending in emscripten. I bet that'd be the least work and result in (by far) the fastest parser. Of course there'd be some work in figuring out the right data structures for output from the parser. > > -- Sandro > >> If the "Turtle" used by SPARQL is not supposed to be CR-compatible, this argument is void of course. >> >> Best, >> >> Ruben >> >> >> > > -- Dipl. Inf. Claus Stadler Department of Computer Science, University of Leipzig Research Group: http://aksw.org/ Workpage & WebID: http://aksw.org/ClausStadler Phone: +49 341 97-32260
Received on Saturday, 7 December 2013 01:32:39 UTC