On Tue, Jun 16, 2015 at 7:19 PM, Andy Seaborne <a...@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
>>
>
