You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Qihong Lin <co...@gmail.com> on 2015/06/15 12:36:17 UTC
[GSoC 2015 - JENA-491] Refactoring Template
Hi,
Please check my last 3 commits[1], related to refactoring Template.
master.jj is modified accordingly, *without* implementing the new
CONSTRUCT query function for quad. Just to make sure: the maven build
test for this jena-arq module is successful.
Here're some ideas for to discuss:
(1) Leaving the existing methods/constructors in-place , such as new
Template(basic graph pattern), so the source code for the SPARQL 1.0
parser does not need change.
(2) Add new constructors of Template(QuadAcc qp) for future use for
the new CONSTRUCT query for quad. I use QuadAcc here (instead of
QuadPattern), because other parts of master.jj use it for parsing
quads.
Anything inappropriate? If it's generally OK, I'd like to continue
working on master.jj.
regards,
Qihong
[1] https://github.com/confidencesun/jena/commits/JENA-491
Re: [GSoC 2015 - JENA-491] Refactoring Template
Posted by Qihong Lin <co...@gmail.com>.
On Tue, Jun 16, 2015 at 7:19 PM, Andy Seaborne <an...@apache.org> wrote:
> On 15/06/15 11:36, Qihong Lin wrote:
>>
>> Hi,
>>
>> Please check my last 3 commits[1], related to refactoring Template.
>> master.jj is modified accordingly, *without* implementing the new
>> CONSTRUCT query function for quad. Just to make sure: the maven build
>> test for this jena-arq module is successful.
>>
>> Here're some ideas for to discuss:
>>
>> (1) Leaving the existing methods/constructors in-place , such as new
>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>> parser does not need change.
>
>
> Good!
>
>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>> QuadPattern), because other parts of master.jj use it for parsing
>> quads.
>
>
> That's workable but it could be a bit neater with a builder pattern like the
> current Template(BGP).
>
> The original code had TripleCollectorBGP as the builder and when it's
> finished the parsing step for the CONSTRUCT template, there is a call of
> getBGP() that yields the BGP. They may not be a real copy - that's an
> efficiency hack, not a design issue.
>
> Template for quads should follow the same pattern. The constructor for
> Template can take List<Quad> (or add getQuadPattern to QuadAcc c.f.
> TripleCollectorBGP.getBGP)
>
> (Admittedly, the existing code should also do this in other places. Code
> grows organically over a long period. Consistency is "unlikely"!)
>
> Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
>
> Andy
Because our ('GRAPH' VarOrIri)? definition is optional. It requires
more flexible than QuadPattern. In QuadPattern, 'GRAPH' token can not
be omitted.
>
>>
>>
>> Anything inappropriate? If it's generally OK, I'd like to continue
>> working on master.jj.
>
>
> Great.
>
>
>>
>> regards,
>> Qihong
>>
>>
>> [1] https://github.com/confidencesun/jena/commits/JENA-491
>>
>
Re: [GSoC 2015 - JENA-491] Refactoring Template
Posted by Andy Seaborne <an...@apache.org>.
On 21/06/15 14:36, Qihong Lin wrote:
> Hi,
>
> Here some examples to try:
> https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java
>
(My mistake - I should have replied here, not the older large thread.)
The examples look good to me.
Andy
> You can see that SPARQL 1.1 remains unchanged, both for sparql_11.jj
> and the generated parser code.
>
> regards,
> Qihong
>
> On Tue, Jun 16, 2015 at 9:04 PM, Andy Seaborne <an...@apache.org> wrote:
>> On 16/06/15 12:19, Andy Seaborne wrote:
>>>
>>> On 15/06/15 11:36, Qihong Lin wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please check my last 3 commits[1], related to refactoring Template.
>>>> master.jj is modified accordingly, *without* implementing the new
>>>> CONSTRUCT query function for quad. Just to make sure: the maven build
>>>> test for this jena-arq module is successful.
>>
>>
>> Is there an example that I can try?
>>
>>>>
>>
>> You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone. It's
>> only the ARQ-extended form that should have your grammar. The SPARQL 1.1
>> parser (like the SPARQL 1.0 parser) will be unchanged although changes in
>> whitespace etc in the generated java will get in the way of seeing that.
>>
>> master.jj:
>>
>>
>> #ifdef ARQ
>> void ConstructQuery() ; { Template t ;
>> QuadAcc acc = new QuadAcc() ; }
>> ...
>> #else
>> void ConstructQuery() : { Template t ;
>> QuadAcc acc = new QuadAcc() ; }
>>
>> This second branch should be the same bytes as the existing master.jj:
>>
>> void ConstructQuery() : { Template t ;
>> TripleCollectorBGP acc = new TripleCollectorBGP()
>> ; }
>> {
>> ...
>>
>>
>> You can test from the command line using the arq.qparse tool. Either
>>
>> java -cp ... arq.qparse --syntax=ARQ --file=...
>>
>> or
>>
>> java -cp ... arq.qparse --file=Q.arq
>>
>> The .arq extension will change it to ARQ syntax.
>>
>> I'm looking forward to trying it out ...
>>
>> Andy
>>
>>
>>>> Here're some ideas for to discuss:
>>>>
>>>> (1) Leaving the existing methods/constructors in-place , such as new
>>>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>>>> parser does not need change.
>>>
>>>
>>> Good!
>>>
>>>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>>>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>>>> QuadPattern), because other parts of master.jj use it for parsing
>>>> quads.
>>>
>>>
>>> That's workable but it could be a bit neater with a builder pattern like
>>> the current Template(BGP).
>>>
>>> The original code had TripleCollectorBGP as the builder and when it's
>>> finished the parsing step for the CONSTRUCT template, there is a call of
>>> getBGP() that yields the BGP. They may not be a real copy - that's an
>>> efficiency hack, not a design issue.
>>>
>>> Template for quads should follow the same pattern. The constructor for
>>> Template can take List<Quad> (or add getQuadPattern to QuadAcc c.f.
>>> TripleCollectorBGP.getBGP)
>>>
>>> (Admittedly, the existing code should also do this in other places. Code
>>> grows organically over a long period. Consistency is "unlikely"!)
>>>
>>> Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
>>>
>>> Andy
>>>
>>>>
>>>>
>>>> Anything inappropriate? If it's generally OK, I'd like to continue
>>>> working on master.jj.
>>>
>>>
>>> Great.
>>>
>>>>
>>>> regards,
>>>> Qihong
>>>>
>>>>
>>>> [1] https://github.com/confidencesun/jena/commits/JENA-491
>>>>
>>>
>>
Re: [GSoC 2015 - JENA-491] Refactoring Template
Posted by Qihong Lin <co...@gmail.com>.
Hi,
Here some examples to try:
https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java
You can see that SPARQL 1.1 remains unchanged, both for sparql_11.jj
and the generated parser code.
regards,
Qihong
On Tue, Jun 16, 2015 at 9:04 PM, Andy Seaborne <an...@apache.org> wrote:
> On 16/06/15 12:19, Andy Seaborne wrote:
>>
>> On 15/06/15 11:36, Qihong Lin wrote:
>>>
>>> Hi,
>>>
>>> Please check my last 3 commits[1], related to refactoring Template.
>>> master.jj is modified accordingly, *without* implementing the new
>>> CONSTRUCT query function for quad. Just to make sure: the maven build
>>> test for this jena-arq module is successful.
>
>
> Is there an example that I can try?
>
>>>
>
> You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone. It's
> only the ARQ-extended form that should have your grammar. The SPARQL 1.1
> parser (like the SPARQL 1.0 parser) will be unchanged although changes in
> whitespace etc in the generated java will get in the way of seeing that.
>
> master.jj:
>
>
> #ifdef ARQ
> void ConstructQuery() ; { Template t ;
> QuadAcc acc = new QuadAcc() ; }
> ...
> #else
> void ConstructQuery() : { Template t ;
> QuadAcc acc = new QuadAcc() ; }
>
> This second branch should be the same bytes as the existing master.jj:
>
> void ConstructQuery() : { Template t ;
> TripleCollectorBGP acc = new TripleCollectorBGP()
> ; }
> {
> ...
>
>
> You can test from the command line using the arq.qparse tool. Either
>
> java -cp ... arq.qparse --syntax=ARQ --file=...
>
> or
>
> java -cp ... arq.qparse --file=Q.arq
>
> The .arq extension will change it to ARQ syntax.
>
> I'm looking forward to trying it out ...
>
> Andy
>
>
>>> Here're some ideas for to discuss:
>>>
>>> (1) Leaving the existing methods/constructors in-place , such as new
>>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>>> parser does not need change.
>>
>>
>> Good!
>>
>>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>>> QuadPattern), because other parts of master.jj use it for parsing
>>> quads.
>>
>>
>> That's workable but it could be a bit neater with a builder pattern like
>> the current Template(BGP).
>>
>> The original code had TripleCollectorBGP as the builder and when it's
>> finished the parsing step for the CONSTRUCT template, there is a call of
>> getBGP() that yields the BGP. They may not be a real copy - that's an
>> efficiency hack, not a design issue.
>>
>> Template for quads should follow the same pattern. The constructor for
>> Template can take List<Quad> (or add getQuadPattern to QuadAcc c.f.
>> TripleCollectorBGP.getBGP)
>>
>> (Admittedly, the existing code should also do this in other places. Code
>> grows organically over a long period. Consistency is "unlikely"!)
>>
>> Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
>>
>> Andy
>>
>>>
>>>
>>> Anything inappropriate? If it's generally OK, I'd like to continue
>>> working on master.jj.
>>
>>
>> Great.
>>
>>>
>>> regards,
>>> Qihong
>>>
>>>
>>> [1] https://github.com/confidencesun/jena/commits/JENA-491
>>>
>>
>
Re: [GSoC 2015 - JENA-491] Refactoring Template
Posted by Andy Seaborne <an...@apache.org>.
On 16/06/15 12:19, Andy Seaborne wrote:
> On 15/06/15 11:36, Qihong Lin wrote:
>> Hi,
>>
>> Please check my last 3 commits[1], related to refactoring Template.
>> master.jj is modified accordingly, *without* implementing the new
>> CONSTRUCT query function for quad. Just to make sure: the maven build
>> test for this jena-arq module is successful.
Is there an example that I can try?
>>
You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone.
It's only the ARQ-extended form that should have your grammar. The
SPARQL 1.1 parser (like the SPARQL 1.0 parser) will be unchanged
although changes in whitespace etc in the generated java will get in the
way of seeing that.
master.jj:
#ifdef ARQ
void ConstructQuery() ; { Template t ;
QuadAcc acc = new QuadAcc() ; }
...
#else
void ConstructQuery() : { Template t ;
QuadAcc acc = new QuadAcc() ; }
This second branch should be the same bytes as the existing master.jj:
void ConstructQuery() : { Template t ;
TripleCollectorBGP acc = new
TripleCollectorBGP() ; }
{
...
You can test from the command line using the arq.qparse tool. Either
java -cp ... arq.qparse --syntax=ARQ --file=...
or
java -cp ... arq.qparse --file=Q.arq
The .arq extension will change it to ARQ syntax.
I'm looking forward to trying it out ...
Andy
>> Here're some ideas for to discuss:
>>
>> (1) Leaving the existing methods/constructors in-place , such as new
>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>> parser does not need change.
>
> Good!
>
>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>> QuadPattern), because other parts of master.jj use it for parsing
>> quads.
>
> That's workable but it could be a bit neater with a builder pattern like
> the current Template(BGP).
>
> The original code had TripleCollectorBGP as the builder and when it's
> finished the parsing step for the CONSTRUCT template, there is a call of
> getBGP() that yields the BGP. They may not be a real copy - that's an
> efficiency hack, not a design issue.
>
> Template for quads should follow the same pattern. The constructor for
> Template can take List<Quad> (or add getQuadPattern to QuadAcc c.f.
> TripleCollectorBGP.getBGP)
>
> (Admittedly, the existing code should also do this in other places. Code
> grows organically over a long period. Consistency is "unlikely"!)
>
> Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
>
> Andy
>
>>
>>
>> Anything inappropriate? If it's generally OK, I'd like to continue
>> working on master.jj.
>
> Great.
>
>>
>> regards,
>> Qihong
>>
>>
>> [1] https://github.com/confidencesun/jena/commits/JENA-491
>>
>
Re: [GSoC 2015 - JENA-491] Refactoring Template
Posted by Andy Seaborne <an...@apache.org>.
On 15/06/15 11:36, Qihong Lin wrote:
> Hi,
>
> Please check my last 3 commits[1], related to refactoring Template.
> master.jj is modified accordingly, *without* implementing the new
> CONSTRUCT query function for quad. Just to make sure: the maven build
> test for this jena-arq module is successful.
>
> Here're some ideas for to discuss:
>
> (1) Leaving the existing methods/constructors in-place , such as new
> Template(basic graph pattern), so the source code for the SPARQL 1.0
> parser does not need change.
Good!
> (2) Add new constructors of Template(QuadAcc qp) for future use for
> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
> QuadPattern), because other parts of master.jj use it for parsing
> quads.
That's workable but it could be a bit neater with a builder pattern like
the current Template(BGP).
The original code had TripleCollectorBGP as the builder and when it's
finished the parsing step for the CONSTRUCT template, there is a call of
getBGP() that yields the BGP. They may not be a real copy - that's an
efficiency hack, not a design issue.
Template for quads should follow the same pattern. The constructor for
Template can take List<Quad> (or add getQuadPattern to QuadAcc c.f.
TripleCollectorBGP.getBGP)
(Admittedly, the existing code should also do this in other places.
Code grows organically over a long period. Consistency is "unlikely"!)
Why can't you use QuadPattern(QuadAcc) in ARQ-ConstructQuery?
Andy
>
>
> Anything inappropriate? If it's generally OK, I'd like to continue
> working on master.jj.
Great.
>
> regards,
> Qihong
>
>
> [1] https://github.com/confidencesun/jena/commits/JENA-491
>