Oh, so I started working with the JavaCC grammar by running Fuseki, and later
wrote that main method, but I could have used qparse? I liked the main method
because I did not have to re-compile the project, since I could simply update
the JavaCC grammar and run the generated parser.
Can I get the same result with qparse? If so I will update JENA-632 :)
Thanks Andy!Bruno
From: Andy Seaborne <[email protected]>
To: [email protected]
Sent: Monday, April 13, 2015 12:44 AM
Subject: Re: Fwd: Proposal submitted [JENA-491]
The command line tools work with the extended ARQ syntax if:
1/ The file name ends ".arq"
or
2/ --syntax arq
so you can use qparse to test queries.
"qparse" also does some internal testing - it parses the query, prints
the parsed form (so it does query -> string), reparses and tests that
hash code and .equals work.
Andy
On 12/04/15 11:31, Bruno P. Kinoshita wrote:
> Hello,
> Chiming in just to say that if necessary I can help testing the JavaCC part.
> I was working on JENA-632, which is still being reviewed, but it included
> changes in ARQ and in the JavaCC grammar.
>
> One thing that could be helpful, I think, is extracting the main method
> created for JENA-632 [1] in the generated parser. It avoids having to re-run
> Fuseki to quickly test the modifications in the grammar. I will file an issue
> and extract that part later.
>
> All the best,Bruno
> [1]
> https://github.com/kinow/jena/blob/7b3b10134f4201314d5f6c6103a595181e82f997/jena-arq/Grammar/arq.jj#L39
>
>
> From: Qihong Lin <[email protected]>
> To: [email protected]
> Sent: Sunday, April 12, 2015 9:10 PM
> Subject: Re: Fwd: Proposal submitted [JENA-491]
>
> Hello,
>
> Please check my reply below:
>
> On Thu, Apr 9, 2015 at 12:07 PM, Ying Jiang <[email protected]> wrote:
>> Hi Andy,
>>
>> Now, we are at "proposal ranking phase 1: indicate willingness to
>> mentor", with the deadline of April 12 00:00 UTC. I've already
>> registered as a "Possible mentor" for Qihong's proposal. Not sure what
>> the next step is. Maybe, ranking all the proposals with scores. I'm
>> waiting for the notices from the mentors@.
>>
>> Hi, Qihong,
>> I think we should take Andy's advice to start discussion on dev@. The
>> proposal has been submitted, and you can not change it. But we can put
>> some posts below there to improve the proposal evaluation. So, I
>> suggest:
>> 1) Andy has made some comments about the project details on dev@ and
>> JIRA. You can summarize them and enrich your proposal in
>> google-melange. If you have any questions, just ask ASAP.
>
> I've modified the project proposal:
> https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit
>
>> 2) The project schedule can be adjusted, because the first half is
>> larger so it may not split at the mid-term evaluation.
>> 3) The javacc grammar changes should be done first. Have you learned
>> the document of how to use javacc? Have you tried the scripts in
>> cygwin?
>
> Yes, cygwin works for me. However I need some time to study the javacc
> grammar.
>
>
>
>> 4) You can also set up the project documentation in Github or
>> Jena-site. It's better to write the document of design now, like Andy
>> says.
>>
>> You should know that Apache strives for a 100% success rate of GSoC
>> project. It makes good chance to get accepted if we can get things go
>> on ASAP. I'd like to help you with pleasure. Good luck!
>>
>> Best,
>> Ying Jiang
>>
>>
>>
>> On Wed, Apr 8, 2015 at 9:18 PM, Andy Seaborne <[email protected]> wrote:
>>> Hi Ying,
>>>
>>> What is the next process step for GSoC this year?
>>>
>>> As mentor, you probably want to see this project as starting now. As you
>>> know, I don't have time to mentor this year and so can't really guarantee
>>> technical invovement at short notice.
>>>
>>> The proposal will updating for the comments; it also needs to be made
>>> consistent. This is better now as part of the submission process, not in
>>> the bonding stage. It'll improve the proposal evaluation.
>>>
>>> e.g,. the javacc grammar changes should be done first. Not much point
>>> hacking the generated java parser (it'll be over written by the grammar
>>> compiler).
>>>
>>> e.g. Documentation should arrive with a deliverable, not later (writing the
>>> document, which isn't going to be very large, helps check the design).
>>>
>>> Ying - do you want to work with Qihong to do that? As discussion on dev@?
>>>
>>> The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the
>>> first half is larger so it may not split at the mid-term evaluation.
>>>
>>> What will be important for this project is regular email traffic to dev@.
>>> It's all about making a smooth path for change. This isn't a new module,
>>> this is making changes to an area users depend on already. Several people
>>> here will want to know what's happening, hopefully comment; we should break
>>> the deliverables up to get them in piece by piece, not wait until the end.
>>>
>>> Using github and generating pull requests throughout the project will work
>>> best. There needs to be a fallback in case github is not accessible after
>>> our experiences of last year.
>>>
>>> Qihong - do you have any questions on the process?
>>>
>>> Andy
>>>
>>>
>>> On 07/04/15 15:00, Ying Jiang wrote:
>>>>
>>>> Hi Andy,
>>>>
>>>> Thanks for answering Qihong's questions! JENA-491 is not original from
>>>> my idea. So, I'm very grateful if you can help the student to clarify
>>>> the project goals and the scopes. Then, as the mentor, I can push the
>>>> project going on when it starts, with technical assistance regarding
>>>> Jena.
>>>>
>>>> For the first question, is it OK to expose Quad to end user in
>>>> querying? I mean, we have 2 layers of Jena API: the higher one of
>>>> Model/Statement/Resource, and the underlying Graph/Triple/Quad/Node.
>>>> It makes sense to me if we encourage the end users using the former as
>>>> much as possible. Currently, in the API, we already have:
>>>> Iterator<Triple> QueryExecution.execConstructTriples(). I have the
>>>> same doubt with it. What's your opinion?
>>>>
>>>> Best,
>>>> Ying Jiang
>>>>
>>>> On Sun, Apr 5, 2015 at 2:04 AM, Andy Seaborne <[email protected]> wrote:
>>>>>
>>>>> On 03/04/15 03:47, Qihong Lin wrote:
>>>>>>
>>>>>>
>>>>>> Hello Andy,
>>>>>>
>>>>>> It's submitted in time.
>>>>>
>>>>>
>>>>>
>>>>> Good.
>>>>>
>>>>> Ying - what is the next process step?
>>>>>
>>>>>> I saw your notes, thanks. Here're some further
>>>>>> questions.
>>>>>>
>>>>>> 1) API of QueryExecution
>>>>>> Does the API look like:
>>>>>> - Iterator<Quad> QueryExecution.execConstrucQuads()
>>>>>> - Dataset QueryExecution.execConstructDataset()
>>>>>
>>>>>
>>>>>
>>>>> Both. (One builds on the other anyway.)
>>>>>
>>>>> It should mirror how execConstruct/execConstructTriples are done unless
>>>>> there is a very good reason not to.
>>>>>
>>>>>> 2) master.jj
>>>>>> How does master.jj generate arq.jj? What tool? You mentioned "is
>>>>>> processed with cpp". What's cpp?
>>>>>
>>>>>
>>>>>
>>>>> cpp is the C preprocessor (yes!!) It rewrites one text file to another
>>>>> text
>>>>> file. ARQ does not cpp macros, it is just using defined symbols ARQ and
>>>>> SPARQL_11 to put in different blocks of text.
>>>>>
>>>>> It's also why there are no comments in arq.jj. cpp removes them and
>>>>> blank
>>>>> lines (the alternative is lots of blank lines - it's yuk).
>>>>>
>>>>> The script to drive it is jena-arq/Grammar/grammar (it's a bash script -
>>>>> I
>>>>> don't know how well it runs on MS Windows - it used to using cygwin).
>>>>> The
>>>>> script directs the output to the right place in the java source code.
>>>>>
>>>>> If you have trouble running it, edit arq.jj then run javacc.
>>>>>
>>>>> The SyntaxARQ parts that are not SPARQL 1.1, are in sections
>>>>>
>>>>> #ifdef ARQ
>>>>> ....
>>>>> #endif
>>>>>
>>>>>
>>>>>> 3) query string sytax
>>>>>> I went through TriG syntax.
>>>>>> - For our query string, can it construct a Dataset with multiple
>>>>>> graphs, or just one default/named graph?
>>>>>
>>>>>
>>>>>
>>>>> Multiple.
>>>>>
>>>>> A dataset is one default and zero or more named graphs.
>>>>>
>>>>> CONSTRUCT
>>>>> { GRAPH :g1 { ?s ?p ?o }
>>>>> GRAPH :g2 { ?s ?p ?o }
>>>>> GRAPH ?g { ?s ?p ?o }
>>>>> } ...
>>>>>
>>>>> only in real use the patterns will be bigger.
>>>>>
>>>>>> - Shall we consider using variables for named graphs? I mean "?g", not
>>>>>> ":g":
>>>>>> CONSTRUCT {
>>>>>> # Named graph
>>>>>> GRAPH ?g { ?s :p ?o }
>>>>>> } WHERE
>>>>>>
>>>>>
>>>>> Yes.
>>>>>
>>>>> Class Template can be made to work purely on quads. Where it current
>>>>> uses
>>>>> BasicPattern (which is triples), use QuadPattern.
>>>>>
>>>>> That will work for non-extended SPARQL 1.1 as well because "CONSTRUCT {
>>>>> no
>>>>> use of GRAPH }" will give a quad pattern of all quads for the default
>>>>> graph.
>>>>> There is a magic constant for "this quad is for the default graph" - see
>>>>> class Quad.
>>>>>
>>>>> So you don't need tow different sets of machinary - update Template to
>>>>> handle quads and the syntactic restrictions of SPARQL_11 will stop it
>>>>> getting named graph in CONSTRUCT.
>>>>>
>>>>> execConstruct/execConstructTriples then work on the default graph of a
>>>>> dataset.
>>>>>
>>>>> You may find it helpful to look at the TriG parser output. That parser is
>>>>> not Javacc (it's much faster). It's informing but you will need to write
>>>>> the javacc for this project.
>>>>>
>>>>>> regards,
>>>>>> Qihong
>>>>>
>>>>>
>>>>>
>>>>> Andy
>>>
>>>
>
>
>
>
