- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Fri, 6 Dec 2013 08:32:11 -0800
- To: Sandro Hawke <sandro@w3.org>
- Cc: "public-rdfjs@w3.org" <public-rdfjs@w3.org>
On Dec 6, 2013, at 5:57 AM, Sandro Hawke <sandro@w3.org> 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. It's a fair bit more complicated, I'm afraid. > 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. Not a bad idea. My own ruby parser generates essentially the same S-expressions as Jena ARQ. Doing this made it useful to separate parsing and expression generation from expression execution. Gregg > -- Sandro > >> If the "Turtle" used by SPARQL is not supposed to be CR-compatible, this argument is void of course. >> >> Best, >> >> Ruben > >
Received on Friday, 6 December 2013 16:32:43 UTC