Hi,
Would it be possible to add new methods & constructors to Template.java
while leaving the existing methods/constructors in-place (reimplemented
in Template; that does not affect the SPARQL 1.0 parser). Then the
source code for the SPARQL 1.0 parser does not need change.
The main (and only, I think) use from the SPARQL 1.0 grammar is the
constructor "new Template(basic graph pattern)".
So if there is a constructor to match that, the generated source code
for SPARQL 1.0 does not need to change (it may need to recompiled but
that's happening anyway). Another constructor can take a QuadPattern.
getTriple/getBGP only returns the default graph related triples. A new
getQuads returns everything.
Is there some code on github for the changes to Template to look at?
If you drop some links here, I'll try to find some time to take a look soon.
Don't worry too much at this stage - If SPARQL 1.0 gets in the way too
much of you making progress, then delete it from your code (but note the
fact so we can be careful when merging pull requests later!!)
Andy
On 14/06/15 05:16, Ying Jiang wrote:
Hi Qihong,
It doesn't matter. For a temperate solution, just change the code of
SPARQL_10 manually to make the compiling work.
Please don't wait the answers from the list. Many of the questions do
not stop you from coding. We would be glad if you can deliver your
code as soon/often as possible.
Best regards,
Ying Jiang
On Fri, Jun 12, 2015 at 9:54 AM, Qihong Lin <[email protected]> wrote:
Hi,
If the checksum and grammar script is OK, I'd like to continue coding.
However, the grammar script only generates ARQ and SPARQL_11, without
touching SPARQL_10. If I change the code of, e.g. Template [1], it
will affect SPARQL_10. Shall I modify the code of SPARQL_10 manually,
change the sparql_10.jj grammar manually, or re-generate SPARQL_10
with the grammar script (and how?) ?
regards,
Qihong
[1]
https://github.com/confidencesun/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/syntax/Template.java
On Fri, Jun 12, 2015 at 12:10 AM, Ying Jiang <[email protected]> wrote:
Hi Qihong,
Have you modified any files? If the grammar file is identical, the
checksum of each generated java class should be the same.
Best regards,
Ying Jiang
On Mon, Jun 8, 2015 at 5:27 PM, Qihong Lin <[email protected]> wrote:
Hi,
The grammar has been modified for the problems you pointed out.
I've tried to run grammar script to generate arq.jj, sparql_11.jj and
their parser java classes, in cygwin with JavaCC 5.0. However the
generated java classes are different from those in the code base:
1) ARQParser
- the new generated one:
public class ARQParser extends ARQParserBase implements ARQParserConstants
- the old one in the code base:
public class ARQParser extends ARQParserBase
There's no such difference for SPARQLParser11 (both new and old ones
have "implements ...")
2) checksum for Token, ParseException, JavaCharStream and so on
- the new generated one (Token.java):
/* JavaCC - OriginalChecksum=335d1922781852977208d5cdca0fc164 (do not
edit this line) */
- the old one in the code base (Token.java):
/* JavaCC - OriginalChecksum=d9b4c8c9332fa3054a004615fdb22b89 (do not
edit this line) */
The log from grammar script seems OK:
$ ./grammar
---- Process grammar -- sparql_11.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file sparql_11.jj . . .
File "TokenMgrError.java" does not exist. Will create one.
File "ParseException.java" does not exist. Will create one.
File "Token.java" does not exist. Will create one.
File "JavaCharStream.java" does not exist. Will create one.
Parser generated successfully.
---- Create text form
Java Compiler Compiler Version 5.0 (Documentation Generator Version 0.1.4)
(type "jjdoc" with no arguments for help)
Reading from file sparql_11.jj . . .
Grammar documentation generated successfully in sparql_11.txt
---- Fixing Java warnings in TokenManager ...
---- Fixing Java warnings in Token ...
---- Fixing Java warnings in TokenMgrError ...
---- Fixing Java warnings in SPARQLParser11 ...
---- Done
---- Process grammar -- arq.jj
Java Compiler Compiler Version 5.0 (Parser Generator)
(type "javacc" with no arguments for help)
Reading from file arq.jj . . .
File "TokenMgrError.java" does not exist. Will create one.
File "ParseException.java" does not exist. Will create one.
File "Token.java" does not exist. Will create one.
File "JavaCharStream.java" does not exist. Will create one.
Parser generated successfully.
---- Create text form
Java Compiler Compiler Version 5.0 (Documentation Generator Version 0.1.4)
(type "jjdoc" with no arguments for help)
Reading from file arq.jj . . .
Grammar documentation generated successfully in arq.txt
---- Fixing Java warnings in TokenManager ...
---- Fixing Java warnings in Token ...
---- Fixing Java warnings in TokenMgrError ...
---- Fixing Java warnings in ARQParser ...
---- Done
Is that the expected behavior for the grammar script? Anything wrong?
regard,
Qihong
On Sat, Jun 6, 2015 at 11:05 AM, Ying Jiang <[email protected]> wrote:
Hi,
The grammar needs revisions in some way. For example, in your
proposal, the GRAPH token can be optional. Another problem for default
graph: both { ?s :p ?o } and ?s :p ?o are valid, so QuadsNotTriples
should be re-defined.
On the other hand, you can start playing with the code of master.jj.
There's no need to wait until the grammar is ready. Your code is
supposed to be delivered as soon as possible. We can have early
feedback from the end users. Merging early will also reduce any
problems with several people changing the same file.
Best regards,
Ying Jiang
On Fri, Jun 5, 2015 at 6:25 PM, Qihong Lin <[email protected]> wrote:
Hi,
I added the grammar draft at the end of [1]. There're actually minor
changes on the grammar of ConstructQuery, which are marked red. Much
of the grammar from SPARQL INSERT can be reused, related to Quads. Any
comments?
regards,
Qihong
[1]
https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0
On Tue, Jun 2, 2015 at 10:10 PM, Ying Jiang <[email protected]> wrote:
Hi Qihong,
Your grammar in the proposal is not formal. Why not compose a BNF/EBNF
notation one, so that others can provide more accurate comments? e.g,
the WHERE clause for the complete form and short form are quite
different. No complex graph patterns are allowed in the short form).
Best regards,
Ying Jiang
On Thu, May 28, 2015 at 10:59 PM, Qihong Lin <[email protected]> wrote:
Hi,
Ying,
I'll stick to the list for discussion. Thanks for your guide! I
re-created a fresh new branch of JENA-491, which did not contain hp
package any more.
Andy,
You mention that the GRAPH grammar needs revisions. Please check the
following ones. I add the short form. Am I missing anything else?
Complete form:
CONSTRUCT {
# Named graph
GRAPH :g { ?s :p ?o }
# Default graph
{ ?s :p ?o }
# Named graph
:g { ?s :p ?o }
# Default graph
?s :p ?o
} WHERE { ... }
Short form:
CONSTRUCT {
} WHERE { ... }
regards,
Qihong
On Tue, May 26, 2015 at 11:12 PM, Ying Jiang <[email protected]> wrote:
Hi Qihong,
As Andy mentioned, the bonding period is for community bonding, not
just mentor bonding. I can help you with JavaCC for the project. But
much more work needs comments and discussions with others in the
community. For example, Andy just pointed out the design issue and the
timeline changes. It's required for you to think about it and make
revisions accordingly. If any questions, just ask on the mailing list.
You'll get answers from the right one, not just from me.
It seems that your JENA-491 branch still uses com.hp.hpl.jena. Have
you re-checked out the latest code?
Best regards,
Ying Jiang
On Mon, May 25, 2015 at 11:10 PM, Andy Seaborne <[email protected]> wrote:
Hi Qihong,
One of the reasons there is a community bonding period is to create the
right social context for the work rather than just being about technical
work. As other people may be working on the areas you need to modify, this
will help avoid problems.
Discussions should be on this list and there has been nothing. Discussions
are also here to help you. It's a large codebase, and some of it quite old.
It makes it hard to see what's important and what's not.
When it comes to decisions, the Apache catchphrase is "if it isn't on the
list, it does not exist". Given that the Jena development community only
exists via this list, you'll appreciate that this is quite important.
Please discuss with Ying about regular (minimum, weekly) on the list.
There are some changes to the plan if the javacc work is done first. Alos,
we have discussed a revised design with GRAPH inside the CONSTRUCT template.
Don't forget the case of CONSTRUCT WHERE { } shorthand form.
What does the timeline look like with these revisions? That changes the
"Week 1 - Week 3" slot. Some of that freed up time should go to announcing
the changes on the users@ list, I suggest just after the mid term
evaluation.
You will have noticed that the package structure in ARQ has changed. There
is no com.hp.hpl.jena anymore, it's all moved under org.apache.jena. You
are probably better off starting from a clean clone of Jena.
Andy
On 24/05/15 14:12, Qihong Lin wrote:
Hi,
Sorry for my late response. During the community binding period, I
studied the JavaCC grammar with my mentor's help. Now, I know how to
use JavaCC in this project.
A new branch of JENA-491 [1] has just been set up. I'll code there in
the first place, and finally merge the code into jena master.
In all, I think everything is ready. Let's begin coding!
regards,
Qihong
[1] https://github.com/confidencesun/jena/tree/JENA-491
On Tue, May 19, 2015 at 4:55 AM, Andy Seaborne <[email protected]> wrote:
On 05/05/15 11:52, Andy Seaborne wrote:
On 28/04/15 13:09, Ying Jiang wrote:
Hi all,
FYI, Google announced the accepted projects of GSoC 2015 yesterday. A
Jena project of "Extend CONSTRUCT to build quads (JENA-491) [1] is
among them.
Cheers,
Ying Jiang
[1]
https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit#heading=h.fwbztdn0y3zl
Hi,
What's the plan for the bonding period?
Andy
Ping?
