Re: GSoC 2015 Students: "Pencils Down" and Final Evaluation Dates Approaching

[Qihong Lin]

Hi Dr. Jiang,

Yes, the code have been submitted. Thanks for your kindly reminder.

regards
Qihong

On Tue, Sep 22, 2015 at 10:32 AM, Ying Jiang  wrote:
> Hi Qihong,
>
> Have you submitted the code sample? If not, you'd better do it right
> now, or you won't get the certificate.
>
> Best regards,
> Ying Jiang
>
>
> -- Forwarded message --
> From: 'Carol Smith' via Google Summer of Code Students List
> 
> Date: Tue, Sep 22, 2015 at 3:22 AM
> Subject: Re: GSoC 2015 Students: "Pencils Down" and Final Evaluation
> Dates Approaching
> To: GSoC students 
>
>
> Hi GSoC 2015 students,
>
> On Mon, Aug 10, 2015 at 8:41 AM, Carol Smith  wrote:
>>
>>
>> I have also updated the code submission guidelines for the program this 
>> year. Code submissions for passing students can happen any time after 28 
>> August if you have passed your final evaluations. They are due by 25 
>> September. Please look the guidelines over and let me know if you have any 
>> questions. One question students ask a lot is what portion of their code to 
>> submit if they made changes to an existing code base or their code interacts 
>> a lot with a system they didn't write. The answer is: use your best 
>> discretion. Submit the code that makes the most sense from a user's 
>> perspective.
>
>
> This is a reminder that the soft deadline for submitting your GSoC
> project code is this coming Friday, 25 September. If you would like to
> be included in our first round of shipments of t-shirts and
> certificates you need to submit your code by then. We do not consider
> your project "complete" until you have submitted this code.
>
> Thanks,
> Carol
>
> --
> You received this message because you are subscribed to the Google
> Groups "Google Summer of Code Students List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-summer-of-code-students-list+unsubscr...@googlegroups.com.
> To post to this group, send email to
> google-summer-of-code-students-l...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/google-summer-of-code-students-list.
> For more options, visit https://groups.google.com/d/optout.

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi Andy,

Thank for your comments! I can understand your idea of A/ B/ C/. But
there'a problem in practice.

In brief:
For A/, at the server side, always call
QueryExecutionBase::execConstructDataset()
For B/, the problem is, there're overlaps between DEF.rdfOffer and
DEF.quadsOffer, e.g. TriX, TriXxml and JSONLD.
For C/, e.g. if the Accept lang is JSONLD, which should be written out
by RDFDataMgr, model or dataset? Note that, the server side doesn't
know which it's called from the client side,
QueryEngineHTTP::exeConstructTriples() or exeConstructQuads().

Also at the client side, if
QueryEngineHTTP::exeConstructTriples()/exeConstructQuads() gets the
content type of, e.g. JSONLD, it doesn't know whether it is a model or
dataset.

So, that's why I introduce the DEF.pureRdfOffer to distinguish the
triple format that is not a quad format. In my way, both the sever
side and the client side separate model and dataset. It's kind of ugly
in code. Any more suggestion?

regards,
Qihong

On Mon, Aug 17, 2015 at 10:49 PM, Andy Seaborne a...@apache.org wrote:
 Thanks for the clarification.  I had made a combined version to start
 testing and hopefully it's a close approximation of the intended
 deliverables.

 [ Ying - how's your testing going? ]

 A few things about the pull requests so far:

 0/ More tests in TestQuery in Fuseki:

 For example, this should show up:

 1/ QueryEngineHttp.execConstructDataset is not implemented.


 2/ SPARQL_Query:

 This line

if ( ! rdfMediaType.getType().equals(*) ) {

 means that only Accept: * will trigger dataset results.

 then in ResponseDataset

 MediaType i = ConNeg.chooseContentType(request, DEF.quadsOffer,
 DEF.acceptNQuads) ;

 will always choose TriG because the accept is * (output= works but that
 is overriding content negotiation).

 There is no way to ask for a specific syntax (n-quads, trig, JSON-LD) using
 Accept:

 e.g. Accept: application/n-quads


 3/ ResponseDataset is copy of ResponseModel yet the only differences (after
 reformatting) are different data values and

   RDFDataMgr.write(out, dataset, lang) ;
  ---
   RDFDataMgr.write(out, model, lang) ;

 It is not good to have copied code because it makes maintenance harder.



 (2) and (3) can be addressed by

 A/ SPARQL_Query:

 For CONSTRUCT, always work in datasets; execConstructDataset().
 No need for mention of Models.  if it's a triples CONSTRUCT, treating as a
 dataset will simply put the results in to the default graph.

 QueryExecutionBase::execConstructQuads

 Following on from that, treating datasets as a natural extension of models.
 There is no need to test for extended syntax.  If it's strict SPARQL 1.1, a
 dataset will just have only a default graph.


 B/ Content negotiate for a combined DEF.rdfOffer+DEF.quadsOffer (I don't
 underatand DEF.pureRdfOffer -- N-triples is a standard).

 C/ If it's a triple format (test the Lang),

RDFDataMgr.write(out, dataset.getDefaultModel(), lang) ;
 otherwise:
RDFDataMgr.write(out, dataset, lang) ;


 Andy

Re: svn commit: r1696184 - /jena/site/trunk/content/documentation/query/construct-quad.mdtext

[Qihong Lin]

Hi Dr. Jiang

Thank you! I'll refine the doc following your instructions.

regards,
Qihong

On Tue, Aug 18, 2015 at 12:21 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 You can improve the doc:
 1)  The grammar table collapses. I can see a | in the first row,
 which needs to be escaped. Also, a table header is required.
 2) All of the special symbols (e.g. code, string, expression ) should
 be marked. You can refer to other docs in Jena website, e.g
 property_paths.html
 3) Add possible links in the doc, e.g. Fuseki (doc),
 ExampleConstructQuads.javad(code)
 4) some indent problems in the code fragment
 5) Add ARQ documentation index at the end of the page, just like the
 other ARQ docs.

 Last but not least, make sure make changes based on the latest source
 doc in svn (Andy modified it):
 http://svn.apache.org/repos/asf/jena/site/trunk/content/documentation/query/construct-quad.mdtext

 Best regards,
 Ying Jiang


 On Mon, Aug 17, 2015 at 4:52 PM, Andy Seaborne a...@apache.org wrote:
 On 17/08/15 00:36, jpz6311...@apache.org wrote:

 Author: jpz6311whu
 Date: Sun Aug 16 23:36:58 2015
 New Revision: 1696184

 URL: http://svn.apache.org/r1696184
 Log:
 compose doc for construct-quad.mdtext

 Modified:
  jena/site/trunk/content/documentation/query/construct-quad.mdtext


 Please check when making changes.

 The generated page was blank.

 I have fixed this (it seems that converting the content to UTF-8 did the
 trick) as well as some formatting issues I noticed.  I do not promise all
 formatting issues are fixed.

 Andy

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi Andy,

Let me clarify PR 89 and PR 91:

PR 89: confidencesun/jena/master - apache/jena/master
confidencesun/jena/master contains the commits of the 1st half part of
the project. It only involves jena/arq.

PR 91: confidencesun/jena/JENA-491 - apache/jena/JENA-491-construct-quad
confidencesun/jena/JENA-491 contains the commits of 1st and 2nd parts
of the project, i.e. that's everything.
Because the 2nd part of Fuseki support depends on the 1st part, so I
merged confidencesun/jena/master into confidencesun/jena/JENA-491 in
the first place, and then added the Fuseki support.
** If confidencesun/jena/JENA-491 contains only the commits of the 2nd
part, the java maven projects won't compile. **

If you want to check only the 2nd part, just compare
confidencesun/jena/master with confidencesun/jena/JENA-491, like this:
https://github.com/confidencesun/jena/compare/master...confidencesun:JENA-491
You can see that, there're 5 changed files, touching both arq and fuseki:
In jena-arq (client side of the Fuseki support): QueryEngineHTTP.java
( implement execQuads() and execConstructDataset())
In jena-fuseki-core (sever side): DEF.java, ResponseDataset.java,
SPARQL_Query.java, TestQuery.java
The implementation of the 2nd part is not complex. I don't see much
code that is necessary to be tested. I'll see what I can do with the
tests of different MIME types for the content negotiation. Thanks!

Finally, PR 91 contains everything to be merged into
apache/jena/master, and PR 89 can be ignored. Or, you can merge PR 89,
and then go with PR 91.

Hope it's clear.

regards,
Qihong

On Sun, Aug 16, 2015 at 9:14 PM, Andy Seaborne a...@apache.org wrote:
 Hi - there are some problems with PR 91.

 PR 91 contains changes to jena-arq as well as jena-fuseki-core. Does PR 91
 replace PR 89 or does PR 91 contain some out-of-date update now in PR 89? Or
 something else?

 (
 Line 1 of PR 91 as a diff is:
 diff --git a/jena-arq/Grammar/arq.jj b/jena-arq/Grammar/arq.jj
 )

 Please produce a PR which is only the changes to fuseki, and should eb
 applied after the ARQ changes.

 Also: I can only see one new test in TestQuery.java - I was expecting more
 such as using different MIME types for the content negotiation.

 Andy


 On 15/08/15 10:21, Qihong Lin wrote:

 Hi,

 Please check my updates of the 3 tasks blow:

 1) jena/arq: in master branch (to be merged first)
 In PR 89, I added some more tests in TestAPI and TS_Script. The bug of
 construct quad projection on exeConstructTriples() has been fixed,
 with the tests of 4 cases (commit 03a321f).

 2) jena/fuseki: in JENA-491 branch
 In PR 91, see commit 0eb28d8. You can try out

 org.apache.jena.fuseki.TestQuery.query_construct_01()/query_construct_quad_01()

 3) doc: in jena web page (wiki)
 I can see the staging page [1]. But when I try the Improve this Page
 with [1], it redirects me to [2]. I can not find construct_quad.mdtext
 under [2]. I also try to open [3], with Not Found error. Could you
 help me please?

 regards,
 Qihong

 [1] http://jena.staging.apache.org/documentation/query/construct-quad.html
 [2] https://cms.apache.org/jena/wc/edit/anonymous-LWMAVL/trunk/
 [3] http://jena.apache.org/documentation/query/construct-quad.html

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi,

Please check my updates of the 3 tasks blow:

1) jena/arq: in master branch (to be merged first)
In PR 89, I added some more tests in TestAPI and TS_Script. The bug of
construct quad projection on exeConstructTriples() has been fixed,
with the tests of 4 cases (commit 03a321f).

2) jena/fuseki: in JENA-491 branch
In PR 91, see commit 0eb28d8. You can try out
org.apache.jena.fuseki.TestQuery.query_construct_01()/query_construct_quad_01()

3) doc: in jena web page (wiki)
I can see the staging page [1]. But when I try the Improve this Page
with [1], it redirects me to [2]. I can not find construct_quad.mdtext
under [2]. I also try to open [3], with Not Found error. Could you
help me please?

regards,
Qihong

[1] http://jena.staging.apache.org/documentation/query/construct-quad.html
[2] https://cms.apache.org/jena/wc/edit/anonymous-LWMAVL/trunk/
[3] http://jena.apache.org/documentation/query/construct-quad.html

On Tue, Aug 11, 2015 at 10:35 AM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 You may have received the reminder email from Google that the final
 evaluation of the GSoC project is approaching. The soft deadline is
 17 August, with the hard one on 21 August. It means there're only 2
 weeks left for your remaining work. The tests of arq need improving,
 as Andy points out. You can also deliver the Fuseki part in the other
 branch for review in the mean time. Meanwhile, the documentation can
 be composed in jena web page (wiki). In order to save time, I suggest
 the 3 parts of the work go on simultaneously:
 1) jena/arq: in master branch (to be merged first)
 2) jena/fuseki: in JENA-491 branch
 3) doc: in jena web page (wiki)

 Best regards,
 Ying Jiang


 On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne a...@apache.org wrote:
 I've managed to integrate the latest updates.

 The scripted ones look, at first glance OK, but the data isn't very rich.

 Also, please can we have some API tests in TestAPI.  These are JUnit tests
 in java.  These should be have comprehensive coverage.

 I also tried out execConstructTriples(), I noticed that the result is from
 all graphs.  When just triples are asked for, only those in the default
 graph should be returned.  Template.getTriples calls Quad.asTriple.  But it
 needs to deal with just the default graph, and c can't rely on
 Quad.asTriple.

 Andy


 On 10/08/15 12:44, Qihong Lin wrote:

 Hi,

 I've enriched the syntax tests with short form and default graph
 cases.

 For execution tests, I add the test support in QueryTest for construct
 quad with the scripts files and data files in TRIG (see
 jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
 be part of the construct of ARQ. So I add the execution tests in
 jena-arq/testing/ARQ/Construct/manifest.ttl.

 The fuseki part of construct quad has been implemented (not committed
 yet). I'll submit the code as soon as the PR 89 [1] being merged.
 Anything to be improved for PR 89 from your reviews?

 regards,
 Qihong

 [1] https://github.com/apache/jena/pull/89


 On Thu, Aug 6, 2015 at 8:55 PM, Andy Seaborne a...@apache.org wrote:

 Hi - looking better - I see the syntax tests I provided.

 Does that set of tests cover all cases of the new syntax?

 Next, we need execution tests for ARQ.

 There will need to be execute tests in jena-arq as well. These can be
 Junit tests in java and do not need to be external script files.
 This is separate from testing in Fuseki.



 Do you have any other constraints on your time over the next 2 weeks?

  Andy


 On 06/08/15 04:18, Qihong Lin wrote:


 Hi,

 I've fixed the bugs related to syntax checks. Please see my latest
 commits. Here're the output of the syntax files through qparse (you
 can also run ExampleConstructQuads.java to get the results). Are
 these with the expected behaviors, especially for
 syntax-quad-construct-07.arq?

 run-construct-quad-test:  File: syntax-quad-construct-01.arq
 PREFIX : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}  Output of qparse
 --file syntax-quad-construct-01.arq PREFIX  : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o .} } WHERE {  }  File:
 syntax-quad-construct-02.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }  Output of
 qparse --file syntax-quad-construct-02.arq PREFIX  :
 http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o .} } WHERE { ?s  ?p  ?o } 
 File: syntax-quad-construct-03.arq PREFIX : http://example/

 CONSTRUCT { :s :p :o } WHERE {}  Output of qparse --file
 syntax-quad-construct-03.arq PREFIX  : http://example/

 CONSTRUCT { :s :p :o . } WHERE {  }  File:
 syntax-quad-construct-04.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p
 ?o } }  Output of qparse --file syntax-quad-construct-04.arq
 PREFIX  : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . } WHERE { GRAPH ?g { ?s
 ?p  ?o } }  File

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi Andy,

I can not find the branch of JENA-491-construct-quads in Jena git repository:
https://github.com/apache/jena/branches

regards,
Qihong

On Tue, Aug 11, 2015 at 4:12 PM, Andy Seaborne a...@apache.org wrote:
 On 11/08/15 03:35, Ying Jiang wrote:

 Hi Qihong,

 You may have received the reminder email from Google that the final
 evaluation of the GSoC project is approaching. The soft deadline is
 17 August, with the hard one on 21 August. It means there're only 2
 weeks left for your remaining work. The tests of arq need improving,
 as Andy points out. You can also deliver the Fuseki part in the other
 branch for review in the mean time. Meanwhile, the documentation can
 be composed in jena web page (wiki). In order to save time, I suggest
 the 3 parts of the work go on simultaneously:
 1) jena/arq: in master branch (to be merged first)
 2) jena/fuseki: in JENA-491 branch
 3) doc: in jena web page (wiki)

 Best regards,
 Ying Jiang


 I have created a branch in the Jena git repository
 'JENA-491-construct-quads' for doing this.

 Andy

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi Andy,

I've got the idea of projection. The bug has been fixed. I'll deliver
more tests.
Thanks!

Qihong

On Tue, Aug 11, 2015 at 4:52 PM, Andy Seaborne a...@apache.org wrote:
 On 11/08/15 09:11, Qihong Lin wrote:

 hi Andy,

 I'll further enrich the test data and add JUnit tests in TestAPI for
 better coverage.

 I'm thinking of the problem you mentioned. In fact, there're 2 types
 of query strings:
 a) Query String without Construct Quad, e.g. CONSTRUCT { ?s ?p ?o }
 WHERE { ?s ?p ?o };
 b) Query String with Construct Quad, e.g. CONSTRUCT { ?s ?p ?o GRAPH
 :g1 { :s1 ?p :o1 } } WHERE { ?s ?p ?o }
 Also, the users can choose to execute 2 kinds of query methods:
 1) IteratorTriple execTriples()
 2) IteratorQuad execQuads()

 These make 4 cases:
 a)+1): No problem, original ARQ construct query


 and execContructQuads returns quads with the default graph set.
 and the execContructDataset contains a dataset with triples in the default
 graph.

 b)+2): No problem, new construct quad query

 Yes

 a)+2): The result quads are in the default graph? Or just throw
 exception saying the query string not working with the query method?


 Quads, with graph field being for the default graph.

 b)+1)(you mentioned): The result triples contain only the ?s ?p ?o
 part, ignoring construct GRAPH :g1 { :s1 ?p :o1 }? Or just throw
 exception saying the query string not working with the query method?
 Could you please tell me your opnions about the last 2 cases?


 The effect should be triples in the default graph (?s ?p ?o).  it's a
 projection.  The same happens if you parse, say TriG, into a model : just
 the default graph is seen.

 There is a general abstraction here (CONSTRUCT template to dataset). It's a
 matter of how to handle the two API forms that deal with a restricted form
 (triples/model).  Seeing the default graph in each case is the way to deal
 with it.

 Andy



 regards,
 Qihong

 On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne a...@apache.org wrote:

 I've managed to integrate the latest updates.

 The scripted ones look, at first glance OK, but the data isn't very rich.

 Also, please can we have some API tests in TestAPI.  These are JUnit
 tests
 in java.  These should be have comprehensive coverage.

 I also tried out execConstructTriples(), I noticed that the result is
 from
 all graphs.  When just triples are asked for, only those in the default
 graph should be returned.  Template.getTriples calls Quad.asTriple.  But
 it
 needs to deal with just the default graph, and c can't rely on
 Quad.asTriple.

  Andy


 On 10/08/15 12:44, Qihong Lin wrote:


 Hi,

 I've enriched the syntax tests with short form and default graph
 cases.

 For execution tests, I add the test support in QueryTest for construct
 quad with the scripts files and data files in TRIG (see
 jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
 be part of the construct of ARQ. So I add the execution tests in
 jena-arq/testing/ARQ/Construct/manifest.ttl.

 The fuseki part of construct quad has been implemented (not committed
 yet). I'll submit the code as soon as the PR 89 [1] being merged.
 Anything to be improved for PR 89 from your reviews?

 regards,
 Qihong

 [1] https://github.com/apache/jena/pull/89

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

hi Andy,

I'll further enrich the test data and add JUnit tests in TestAPI for
better coverage.

I'm thinking of the problem you mentioned. In fact, there're 2 types
of query strings:
a) Query String without Construct Quad, e.g. CONSTRUCT { ?s ?p ?o }
WHERE { ?s ?p ?o };
b) Query String with Construct Quad, e.g. CONSTRUCT { ?s ?p ?o GRAPH
:g1 { :s1 ?p :o1 } } WHERE { ?s ?p ?o }
Also, the users can choose to execute 2 kinds of query methods:
1) IteratorTriple execTriples()
2) IteratorQuad execQuads()

These make 4 cases:
a)+1): No problem, original ARQ construct query
b)+2): No problem, new construct quad query
a)+2): The result quads are in the default graph? Or just throw
exception saying the query string not working with the query method?
b)+1)(you mentioned): The result triples contain only the ?s ?p ?o
part, ignoring construct GRAPH :g1 { :s1 ?p :o1 }? Or just throw
exception saying the query string not working with the query method?
Could you please tell me your opnions about the last 2 cases?

regards,
Qihong

On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne a...@apache.org wrote:
 I've managed to integrate the latest updates.

 The scripted ones look, at first glance OK, but the data isn't very rich.

 Also, please can we have some API tests in TestAPI.  These are JUnit tests
 in java.  These should be have comprehensive coverage.

 I also tried out execConstructTriples(), I noticed that the result is from
 all graphs.  When just triples are asked for, only those in the default
 graph should be returned.  Template.getTriples calls Quad.asTriple.  But it
 needs to deal with just the default graph, and c can't rely on
 Quad.asTriple.

 Andy


 On 10/08/15 12:44, Qihong Lin wrote:

 Hi,

 I've enriched the syntax tests with short form and default graph
 cases.

 For execution tests, I add the test support in QueryTest for construct
 quad with the scripts files and data files in TRIG (see
 jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
 be part of the construct of ARQ. So I add the execution tests in
 jena-arq/testing/ARQ/Construct/manifest.ttl.

 The fuseki part of construct quad has been implemented (not committed
 yet). I'll submit the code as soon as the PR 89 [1] being merged.
 Anything to be improved for PR 89 from your reviews?

 regards,
 Qihong

 [1] https://github.com/apache/jena/pull/89


 On Thu, Aug 6, 2015 at 8:55 PM, Andy Seaborne a...@apache.org wrote:

 Hi - looking better - I see the syntax tests I provided.

 Does that set of tests cover all cases of the new syntax?

 Next, we need execution tests for ARQ.

 There will need to be execute tests in jena-arq as well. These can be
 Junit tests in java and do not need to be external script files.
 This is separate from testing in Fuseki.



 Do you have any other constraints on your time over the next 2 weeks?

  Andy


 On 06/08/15 04:18, Qihong Lin wrote:


 Hi,

 I've fixed the bugs related to syntax checks. Please see my latest
 commits. Here're the output of the syntax files through qparse (you
 can also run ExampleConstructQuads.java to get the results). Are
 these with the expected behaviors, especially for
 syntax-quad-construct-07.arq?

 run-construct-quad-test:  File: syntax-quad-construct-01.arq
 PREFIX : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}  Output of qparse
 --file syntax-quad-construct-01.arq PREFIX  : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o .} } WHERE {  }  File:
 syntax-quad-construct-02.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }  Output of
 qparse --file syntax-quad-construct-02.arq PREFIX  :
 http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o .} } WHERE { ?s  ?p  ?o } 
 File: syntax-quad-construct-03.arq PREFIX : http://example/

 CONSTRUCT { :s :p :o } WHERE {}  Output of qparse --file
 syntax-quad-construct-03.arq PREFIX  : http://example/

 CONSTRUCT { :s :p :o . } WHERE {  }  File:
 syntax-quad-construct-04.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p
 ?o } }  Output of qparse --file syntax-quad-construct-04.arq
 PREFIX  : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . } WHERE { GRAPH ?g { ?s
 ?p  ?o } }  File: syntax-quad-construct-05.arq PREFIX :
 http://example/

 CONSTRUCT { ?s ?p ?o GRAPH ?g { :s :p :o } } WHERE { GRAPH ?g { ?s ?p
 ?o } }  Output of qparse --file syntax-quad-construct-05.arq
 PREFIX  : http://example/

 CONSTRUCT { ?s ?p ?o . GRAPH ?g { :s :p :o .} } WHERE { GRAPH ?g { ?s
 ?p  ?o } }  File: syntax-quad-construct-06.arq PREFIX :
 http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s
 ?p ?o } ?s ?p ?o . ?s ?p ?o GRAPH ?g { ?s ?p ?o } } WHERE { GRAPH ?g
 { ?s ?p ?o } }  Output of qparse --file
 syntax-quad-construct-06.arq PREFIX  : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi,

I've enriched the syntax tests with short form and default graph cases.

For execution tests, I add the test support in QueryTest for construct
quad with the scripts files and data files in TRIG (see
jena-arq/testing/ARQ/Construct/*.trig). I think construct quad should
be part of the construct of ARQ. So I add the execution tests in
jena-arq/testing/ARQ/Construct/manifest.ttl.

The fuseki part of construct quad has been implemented (not committed
yet). I'll submit the code as soon as the PR 89 [1] being merged.
Anything to be improved for PR 89 from your reviews?

regards,
Qihong

[1] https://github.com/apache/jena/pull/89


On Thu, Aug 6, 2015 at 8:55 PM, Andy Seaborne a...@apache.org wrote:
 Hi - looking better - I see the syntax tests I provided.

 Does that set of tests cover all cases of the new syntax?

 Next, we need execution tests for ARQ.

 There will need to be execute tests in jena-arq as well. These can be
 Junit tests in java and do not need to be external script files.
 This is separate from testing in Fuseki.


 Do you have any other constraints on your time over the next 2 weeks?

 Andy


 On 06/08/15 04:18, Qihong Lin wrote:

 Hi,

 I've fixed the bugs related to syntax checks. Please see my latest
 commits. Here're the output of the syntax files through qparse (you
 can also run ExampleConstructQuads.java to get the results). Are
 these with the expected behaviors, especially for
 syntax-quad-construct-07.arq?

 run-construct-quad-test:  File: syntax-quad-construct-01.arq
 PREFIX : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}  Output of qparse
 --file syntax-quad-construct-01.arq PREFIX  : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o .} } WHERE {  }  File:
 syntax-quad-construct-02.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }  Output of
 qparse --file syntax-quad-construct-02.arq PREFIX  :
 http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o .} } WHERE { ?s  ?p  ?o } 
 File: syntax-quad-construct-03.arq PREFIX : http://example/

 CONSTRUCT { :s :p :o } WHERE {}  Output of qparse --file
 syntax-quad-construct-03.arq PREFIX  : http://example/

 CONSTRUCT { :s :p :o . } WHERE {  }  File:
 syntax-quad-construct-04.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o } WHERE { GRAPH ?g { ?s ?p
 ?o } }  Output of qparse --file syntax-quad-construct-04.arq
 PREFIX  : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . } WHERE { GRAPH ?g { ?s
 ?p  ?o } }  File: syntax-quad-construct-05.arq PREFIX :
 http://example/

 CONSTRUCT { ?s ?p ?o GRAPH ?g { :s :p :o } } WHERE { GRAPH ?g { ?s ?p
 ?o } }  Output of qparse --file syntax-quad-construct-05.arq
 PREFIX  : http://example/

 CONSTRUCT { ?s ?p ?o . GRAPH ?g { :s :p :o .} } WHERE { GRAPH ?g { ?s
 ?p  ?o } }  File: syntax-quad-construct-06.arq PREFIX :
 http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s
 ?p ?o } ?s ?p ?o . ?s ?p ?o GRAPH ?g { ?s ?p ?o } } WHERE { GRAPH ?g
 { ?s ?p ?o } }  Output of qparse --file
 syntax-quad-construct-06.arq PREFIX  : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g {
 ?s ?p ?o .} ?s ?p ?o . ?s ?p ?o . GRAPH ?g { ?s ?p ?o .} } WHERE {
 GRAPH ?g { ?s  ?p  ?o } }  File:
 syntax-quad-construct-07.arq PREFIX : http://example/

 CONSTRUCT { GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .} } WHERE
 {}  Output of qparse --file syntax-quad-construct-07.arq PREFIX
 : http://example/

 CONSTRUCT { :s :p :o . } WHERE {  }  File:
 syntax-quad-construct-08.arq PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o } GRAPH ?g1 { :s :p :o } } WHERE { }
  Output of qparse --file syntax-quad-construct-08.arq PREFIX  :
 http://example/

 CONSTRUCT { GRAPH ?g { :s :p :o .} GRAPH ?g1 { :s :p :o .} } WHERE {
 }

 On Sun, Aug 2, 2015 at 9:14 AM, Ying Jiang jpz6311...@gmail.com
 wrote:

 Hi Qihong,

 I re-checked the code you commited. Most of the hashCode issues
 for arq.qparse that Andy pointed out are due to the incorrect
 serialization of the Template. The code can only deal with the
 quads with the same graph node, for which it may not always be the
 case in practcial terms. Please make sure each example syntax file
 can pass the checking process of arq.qparse.

 It's August now. You'd better hurry up and make the project
 completed on time in the remaining weeks.

 Best regards, Ying Jiang

 On Thu, Jul 30, 2015 at 6:03 AM, Andy Seaborne a...@apache.org
 wrote:

 Output of * each examnple syntax file (the queries are nonsense
 in practcial terms!) * running arq.qparse on the file * notes on
 what seems to be going on

 Andy

  File: syntax-quad-construct-01.arq PREFIX :
 http://example/

 CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}  Output of
 qparse --file syntax-quad-construct-01.arq PREFIX  :
 http://example

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi,

I've fixed the bugs related to syntax checks. Please see my latest
commits. Here're the output of the syntax files through qparse (you
can also run ExampleConstructQuads.java to get the results). Are
these with the expected behaviors, especially for
syntax-quad-construct-07.arq?

run-construct-quad-test:
 File: syntax-quad-construct-01.arq
PREFIX : http://example/

CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
 Output of qparse --file syntax-quad-construct-01.arq
PREFIX  : http://example/

CONSTRUCT
  {
GRAPH :g
  { :s :p :o .}
  }
WHERE
  {  }
 File: syntax-quad-construct-02.arq
PREFIX : http://example/

CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
 Output of qparse --file syntax-quad-construct-02.arq
PREFIX  : http://example/

CONSTRUCT
  {
GRAPH ?g
  { ?s ?p ?o .}
  }
WHERE
  { ?s  ?p  ?o }
 File: syntax-quad-construct-03.arq
PREFIX : http://example/

CONSTRUCT { :s :p :o } WHERE {}
 Output of qparse --file syntax-quad-construct-03.arq
PREFIX  : http://example/

CONSTRUCT
  {
:s :p :o .
  }
WHERE
  {  }
 File: syntax-quad-construct-04.arq
PREFIX : http://example/

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   ?s ?p ?o
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }
 Output of qparse --file syntax-quad-construct-04.arq
PREFIX  : http://example/

CONSTRUCT
  {
GRAPH ?g
  { :s :p :o .}
?s ?p ?o .
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 File: syntax-quad-construct-05.arq
PREFIX : http://example/

CONSTRUCT {
   ?s ?p ?o
   GRAPH ?g { :s :p :o }
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }
 Output of qparse --file syntax-quad-construct-05.arq
PREFIX  : http://example/

CONSTRUCT
  {
?s ?p ?o .
GRAPH ?g
  { :s :p :o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 File: syntax-quad-construct-06.arq
PREFIX : http://example/

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   ?s ?p ?o .
   ?s ?p ?o .
   GRAPH ?g { ?s ?p ?o }
   ?s ?p ?o .
   ?s ?p ?o
   GRAPH ?g { ?s ?p ?o }
   }
WHERE
   { GRAPH ?g { ?s ?p ?o } }
 Output of qparse --file syntax-quad-construct-06.arq
PREFIX  : http://example/

CONSTRUCT
  {
GRAPH ?g
  { :s :p :o .}
?s ?p ?o .
?s ?p ?o .
GRAPH ?g
  { ?s ?p ?o .}
?s ?p ?o .
?s ?p ?o .
GRAPH ?g
  { ?s ?p ?o .}
  }
WHERE
  { GRAPH ?g
  { ?s  ?p  ?o }
  }
 File: syntax-quad-construct-07.arq
PREFIX : http://example/

CONSTRUCT {
   GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .}
   }
WHERE {}
 Output of qparse --file syntax-quad-construct-07.arq
PREFIX  : http://example/

CONSTRUCT
  {
:s :p :o .
  }
WHERE
  {  }
 File: syntax-quad-construct-08.arq
PREFIX : http://example/

CONSTRUCT {
   GRAPH ?g { :s :p :o }
   GRAPH ?g1 { :s :p :o }
   }
WHERE
   { }
 Output of qparse --file syntax-quad-construct-08.arq
PREFIX  : http://example/

CONSTRUCT
  {
GRAPH ?g
  { :s :p :o .}
GRAPH ?g1
  { :s :p :o .}
  }
WHERE
  {  }

On Sun, Aug 2, 2015 at 9:14 AM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 I re-checked the code you commited. Most of the hashCode issues for
 arq.qparse that Andy pointed out are due to the incorrect
 serialization of the Template. The code can only deal with the quads
 with the same graph node, for which it may not always be the case in
 practcial terms. Please make sure each example syntax file can pass
 the checking process of arq.qparse.

 It's August now. You'd better hurry up and make the project completed
 on time in the remaining weeks.

 Best regards,
 Ying Jiang

 On Thu, Jul 30, 2015 at 6:03 AM, Andy Seaborne a...@apache.org wrote:
 Output of
 * each examnple syntax file (the queries are nonsense in practcial terms!)
 * running arq.qparse on the file
 * notes on what seems to be going on

 Andy

  File: syntax-quad-construct-01.arq
 PREFIX : http://example/

 CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
  Output of qparse --file syntax-quad-construct-01.arq
 PREFIX  : http://example/

 CONSTRUCT
   { GRAPH http://example/g {:s :p :o .}
   }
 WHERE
   {  }
  Issue:
 Minor: formatting of http://example/g should be :g

  File: syntax-quad-construct-02.arq
 PREFIX : http://example/

 CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
  Output of qparse --file syntax-quad-construct-02.arq
 PREFIX  : http://example/

 CONSTRUCT
   { GRAPH ?g {?s ?p ?o .}
   }
 WHERE
   { ?s  ?p  ?o }
 
 OK

  File: syntax-quad-construct-03.arq
 PREFIX : http://example/

 CONSTRUCT { :s :p :o } WHERE {}
  Output of qparse --file syntax-quad-construct-03.arq
 PREFIX  : http://example/

 CONSTRUCT
   { GRAPH urn:x-arq:DefaultGraphNode {:s :p :o .}
   }
 WHERE
   {  }
  Issue:
 Major: The output is contains GRAPH urn:x-arq:DefaultGraphNode

 Note: urn:x-arq:DefaultGraphNode is for internal use only.

 For syntax, that is a named graph just like http://example/g

  File: 

Re: Fwd: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi,

I've fixed the bugs of  arq.aparse and , with some minor
improvements for Java 7/8 you mentioned. Please check the PR 89. I
hope it can be merged into jena master ASAP, so that I can go on with
merging the code for  fuseki support.

regard,
Qihong

On Wed, Jul 29, 2015 at 11:54 AM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 You're requried to keep us posted of your work progress regularly.
 Last week, there were some comments for your code ( PR 89 ) from the
 community. Have you read them and refined your code accordingly? Any
 questions?

 Best regards,
 Ying Jiang


 On Tue, Jul 21, 2015 at 4:35 PM, Andy Seaborne a...@apache.org wrote:
 On 21/07/15 17:46, Ying Jiang wrote:

 Hi Andy,

 Does Qihong need to be an apache committer in order to have the commit
 access? Can you grant her the access right?

 Best regards,
 Ying Jiang


 When you press Improve this page it says

 please use the username anonymous and leave the password blank if prompted
 for credentials


 Before documentation makes sense, there needs to code updates.
 This is most important.

 http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3C55ABD740.9010101%40apache.org%3E

 1. Code and grammar changes
 2. Tests
 3. Pull requests
 4. Documentation

 http://mail-archives.apache.org/mod_mbox/jena-dev/201507.mbox/%3C559EF342.3010806%40apache.org%3E

 Andy



 -- Forwarded message --
 From: Qihong Lin confidence@gmail.com
 Date: Tue, Jul 21, 2015 at 9:25 AM
 Subject: Fwd: Final Deliveries of GSoC Project (JENA-491)
 To: Ying Jiang jpz6311...@gmail.com


 Hi, Dr. Jiang,

 How can I have the commit access to the svn server? I also tried the
 Improve this Page, which asked for user/password.

 The documentation seems to be wiki style. It's better to have preview
 of the doc when composing. The patch approach is not so convenient.


 regards,
 Qihong



 -- Forwarded message --
 From: Bruno P. Kinoshita ki...@apache.org
 Date: Sun, Jul 19, 2015 at 5:52 AM
 Subject: Re: Final Deliveries of GSoC Project (JENA-491)
 To: dev@jena.apache.org dev@jena.apache.org


 For 1), how to commit the documentation in Jena website?

 If you have commit access you can either edit the pages online by
 clicking on the link in the top right corner Improve this Page, or
 check out the source repository at
 http://svn.apache.org/repos/asf/jena/site/trunk/ and commit your
 changes.

 Or you can check out the SVN repository, create a patch and attach it
 to a JIRA issue.

 Changes to the web site are visible initially in
 http://jena.staging.apache.org/
 Hope that helpsBruno


From: Qihong Lin confidence@gmail.com
   To: dev@jena.apache.org
   Sent: Sunday, July 19, 2015 6:17 AM
   Subject: Re: Final Deliveries of GSoC Project (JENA-491)

 Hi,

 I've been taking some course exams for the last week. The current
 project status is ahead of plan. I'll continue the project next week
 after the exams.

 For 1), how to commit the documentation in Jena website?


 regards,
 Qihong



 On Wed, Jul 15, 2015 at 5:43 PM, Ying Jiang jpz6311...@gmail.com wrote:

 Hi Qihong,

 How is the project going?

 I've reviewed the code you committed last week. The function of Fuseki
 support of constructing quad is generally OK. The tests make sense to
 me, although just 2 tests. However, there's more deliveries for you
 final work. At least,

 1) Formal documentation of the goals, approaches, results and etc.
 I suggest creating a doc page in jena website [1], in the section of
 Advanced SPARQL use

 2) Pull requests from your code base into apache/jena ASAP
 Please split this up so that we can check your commits one by one.
 More details in the other thread advised by Andy.

 3) More tests for jena-arq and jena-fuseki-core following the original
 framework

 Please let me know if anything forgotten.


 Best regards,
 Ying Jiang


 [1] https://jena.apache.org/documentation/query/index.html

JENA-491 Pull Request (First Half Part)

[Qihong Lin]

Hi,

Please confirm the pull of the first half part work of the GSoC
project (JENA-491):
https://github.com/apache/jena/pull/88

Note that confidencesun/master firstly is updated/merged from
apache/master, and then merged from confidencesun/JENA-491. Now
apache/master can pull from confidencesun/master so that the JENA-491
functions can be applied.

If it's OK, I'll further deal with construct quad support of fuseki.
The code have done. I can merge them in the same way.

regards,
Qihong

Re: Final Deliveries of GSoC Project (JENA-491)

[Qihong Lin]

Hi,

I've been taking some course exams for the last week. The current
project status is ahead of plan. I'll continue the project next week
after the exams.

For 1), how to commit the documentation in Jena website?


regards,
Qihong

On Wed, Jul 15, 2015 at 5:43 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 How is the project going?

 I've reviewed the code you committed last week. The function of Fuseki
 support of constructing quad is generally OK. The tests make sense to
 me, although just 2 tests. However, there's more deliveries for you
 final work. At least,

 1) Formal documentation of the goals, approaches, results and etc.
 I suggest creating a doc page in jena website [1], in the section of
 Advanced SPARQL use

 2) Pull requests from your code base into apache/jena ASAP
 Please split this up so that we can check your commits one by one.
 More details in the other thread advised by Andy.

 3) More tests for jena-arq and jena-fuseki-core following the original
 framework

 Please let me know if anything forgotten.


 Best regards,
 Ying Jiang


 [1] https://jena.apache.org/documentation/query/index.html

Re: [ANN] GSoC 2015 Project Mid-term Evaluation (PASS)

[Qihong Lin]

Hi,

How to integrate my code into the code base? Which of the following
one is the desired approach:
1) confidencesun/jena:JENA-491 - apache/jena:master
2) confidencesun/jena:JENA-491 - confidencesun/jena:master -
apache/jena:master
3) confidencesun/jena:JENA-491 - apache/jena:JENA-491 - apache/jena:master

regards,
Qihong

On Tue, Jul 7, 2015 at 1:48 AM, Andy Seaborne a...@apache.org wrote:
 On 05/07/15 15:49, Qihong Lin wrote:

 Hi,

 Please check my latest commits [1].


 Hi Qihong,

 As in my other message, that has crossed over at the same time you sent
 this, it is time to work out the process for delivering to the Jena
 codebase.

 Let's start with changes to jena-arq.

 You will need to work with your mentor for this.  Please can we have the
 discussions regularly on this list.

 It will make integrating the code into the code base much easier - at the
 moment, it's quite hard to see how that can be achieved.

 The latest commit has 300+ changed files almost all from merging with Jena
 master not your changes.

 I'm afraid that finding the relevant parts to review from such a large
 number of files is somewhat difficult. It breaks the github review tools for
 a start!

 Andy


 I just completed the function of
 QueryEngineHTTP.execConstructQuads(). You can try out the example of
 query_construct_quad_01() in TestQuery [2].

 I'll improve the tests later on, with more questions in the other
 thread. Thanks!

 Regards,
 Qihong


 [1]
 https://github.com/confidencesun/jena/commit/07afdbf0fe635d41c302b25a9c51f43802ea903a
 [2]
 https://github.com/confidencesun/jena/blob/JENA-491/jena-fuseki2/jena-fuseki-core/src/test/java/org/apache/jena/fuseki/TestQuery.java

 On Sat, Jul 4, 2015 at 10:08 PM, Ying Jiang jpz6311...@gmail.com wrote:

 Hi all,

 FYI, Google announced the mid-term evaluation result of GSoC 2015
 project yesterday. The Jena project of Extend CONSTRUCT to build
 quads (JENA-491) passed the evaluation.

 Hi Qihong,
 Thanks a lot for your contribution last month! We expect your
 excellent work in the coming weeks.
 The status of the project is a little ahead of the schedule. But the
 rest work is also challenging. You're supposed to integrate JENA-491
 into Fuseki. In addition, the tests should be improved in accordance
 with the original test framework of jena-arq.
 Have fun!

 Cheers,
 Ying Jiang

Re: [GSoC 2015 - JENA-491] JavaCC with master.jj

[Qihong Lin]

Hi,

I've studied the jena tests. It looks like that the syntax tests are
generated by syn.sh. But the execution tests are not generated by
scripts, which are written by hand one by one. Is that true?

Since I have enough time, I'd like to directly go for the syn.sh and
syn-arq.sh to generate tests for constructing quads. Thanks!

regards,
Qihong

On Tue, Jun 16, 2015 at 9:24 PM, Andy Seaborne a...@apache.org wrote:
 On 16/06/15 09:06, Qihong Lin wrote:

 Hi,

 Thanks! I just marked GRAPH mandatory, and it worked without
 producing the warnings. I'll look into the details later.

 By the way, if the new parser is ready, how to test it? I mean, where
 to drop the unit test code and the query strings to be tested? I'm
 confused with org.apache.jena.sparql.junit.QueryTest (is that what I
 need to deal with?). Any guideline or documentation for arq test?

 regards,
 Qihong


 Most testing of queries is by externally defined manifest files
 (manifest.ttl)

 jena-arq/testing/ARQ

 For now, keep it clean and start a new directory

 jena-arq/testing/ARQ/ConstructQuads

 with both syntax and execution tests.  This is just to keep everything in
 one place for now.


 See jena-arq/testing/ARQ/Syntax/Syntax-ARQ/manifest.ttl and
 jena-arq/testing/ARQ/Construct/manifest.ttl.

 A manifest can have syntax and execution tests - it so happens that they are
 in separate places in the current test suite which was input the the working
 group.

 A syntax test looks like:

 :test_1 rdf:type   mfx:PositiveSyntaxTestARQ ;
dawgt:approval dawgt:NotClassified ;
mf:namesyntax-select-expr-01.arq ;
mf:action  syntax-select-expr-01.arq ;.

 to parse syntax-select-expr-01.arq, expecting it to be good, and an
 execution test is an action and a result:

 :someExecutionTest rdf:type   mfx:TestQuery ;
 mf:nameConstruct Quads 1 ;
 mf:action
  [ qt:query  q-construct-1.rq ;
qt:data   data-1.ttl ] ;
 mf:result  results-construct-1.ttl
 .

 an action is a query and a data file.

 There are different styles of layout in different places.  The test suite
 has grown incrementally over the years of SPARQL 1.0 and SPARQL 1.1. Some
 test come from outside the project.

 You can test from the command line using the arq.qparse tool.
 See other message.

 There is a command qtest for running manifests.

 Background FYI:

 You won't need this when put everything in
 jena-arq/testing/ARQ/ConstructQuads but to explain: the main test syntax
 suites are auto-generated by syn.sh

 Part of that is syn-arq.sh.

 But hand writing syntax easier for now.

 Andy

Re: [ANN] GSoC 2015 Project Mid-term Evaluation (PASS)

[Qihong Lin]

Hi,

Please check my latest commits [1]. I just completed the function of
QueryEngineHTTP.execConstructQuads(). You can try out the example of
query_construct_quad_01() in TestQuery [2].

I'll improve the tests later on, with more questions in the other
thread. Thanks!

Regards,
Qihong


[1] 
https://github.com/confidencesun/jena/commit/07afdbf0fe635d41c302b25a9c51f43802ea903a
[2] 
https://github.com/confidencesun/jena/blob/JENA-491/jena-fuseki2/jena-fuseki-core/src/test/java/org/apache/jena/fuseki/TestQuery.java

On Sat, Jul 4, 2015 at 10:08 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi all,

 FYI, Google announced the mid-term evaluation result of GSoC 2015
 project yesterday. The Jena project of Extend CONSTRUCT to build
 quads (JENA-491) passed the evaluation.

 Hi Qihong,
 Thanks a lot for your contribution last month! We expect your
 excellent work in the coming weeks.
 The status of the project is a little ahead of the schedule. But the
 rest work is also challenging. You're supposed to integrate JENA-491
 into Fuseki. In addition, the tests should be improved in accordance
 with the original test framework of jena-arq.
 Have fun!

 Cheers,
 Ying Jiang

Extend CONSTRUCT to build quads (JENA-491)

[Qihong Lin]

Hi,

The current W3C recommendation of SPARQL 1.1 supports the CONSTRUCT
query form, which returns a single RDF graph specified by a graph
template. The result is an RDF graph formed by taking each query
solution in the solution sequence, substituting for the variables in
the graph template, and combining the triples into a single RDF graph
by set union. However, it does not directly generate quads or RDF
datasets. In order to eliminate this limitation, I proposed a GSoC
2015 project [1], to extend the grammar of the CONSTRUCT query form
and implement the according Jena ARQ components, which will bring more
conveniences for the users manipulating RDF datasets with SPARQL.

Now the code has been delivered [2], with some examples here [3].
You're welcome to try them out. Any comments are appropriated.

Cheers,
Qihong Lin

[1] 
https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit#
[2] https://github.com/confidencesun/jena/tree/JENA-491
[3] 
https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java

Re: [GSoC 2015 - JENA-491] Refactoring Template

[Qihong Lin]

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 ListQuad (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

[Qihong Lin]

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 a...@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 ListQuad (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: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

Hi,

Please check my commits [1]. For quick answers below:

On Thu, Jun 18, 2015 at 6:18 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 You may have already received an email from Google, which reminded us
 of the mid-term evaluation for the GSoC project. The evaluation will
 start next Friday, 26 June. The deadline to submit your evaluation is
 19:00 UTC on Friday, 3 July. Please make sure not to miss it.

 More importantly, you're supposed to deliver your work according to
 the proposal before that. At least, I need to check the following
 output for the evaluation of your work:
 1) the grammar definition: normative definition of the syntax

It follows the proposal doc here [2].

 2) the new master.jj, arq.jj, with sparql_11.jj unchanged.

Yeah, sparql_11.jj is now unchanged.

 3) the code of new QueryExecution operations: execConstrucQuads(),
 execConstructDataset()

Done!

 4) some test code for the above, OR at least some examples/demos to
 prove your work

Here are some examples in ExampleConstructQuads.java [3]


 Best regards,
 Ying Jiang


[1] https://github.com/confidencesun/jena/commits/JENA-491
[2] 
https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit#
[3] 
https://github.com/confidencesun/jena/blob/JENA-491/jena-arq/src-examples/arq/examples/constructquads/ExampleConstructQuads.java


regards,
Qihong

Re: [GSoC 2015 - JENA-491] JavaCC with master.jj

[Qihong Lin]

Hi,

Thanks! I just marked GRAPH mandatory, and it worked without
producing the warnings. I'll look into the details later.

By the way, if the new parser is ready, how to test it? I mean, where
to drop the unit test code and the query strings to be tested? I'm
confused with org.apache.jena.sparql.junit.QueryTest (is that what I
need to deal with?). Any guideline or documentation for arq test?

regards,
Qihong


On Mon, Jun 15, 2015 at 11:45 PM, Ying Jiang jpz6311...@gmail.com wrote:
 Hi Qihong,

 In addition to Andy's explanation, You might take look at this
 tutorial for more details on javacc lookahead:
 https://javacc.java.net/doc/lookahead.html


 Best regards,
 Ying Jiang

 On Mon, Jun 15, 2015 at 10:42 PM, Andy Seaborne a...@apache.org wrote:
 Qihong,

 There is an ambiguity in the grammar if you make GRAPH optional.

 See rule 'Quads'

 Consider these two cases:

  :s :p :o .
  :z { :s1 :p1 :o1 } .

  :s :p :o .
  :z :q :o2 .


 when the parser get to end of the triple in the default graph:

  :s :p :o .

 there are two ways forward: more triples (TriplesTemplate) and end of the
 triples part, start of named graph.

 It looks ahead one token and see :z and needs to decide whether the next
 rule is more triples, the :z :q :o2 . case, or the end of the triples for
 the default graph and the start of a named graph the :z { :s1 :p1 :o1 } .
 where it exists TriplesTemplate and moves on to QuadsNotTriples

 If GRAPH then the entry to QuadsNotTriples is marked by a GRAPH which is
 never in triples.

 The grammar is LL(1) - a lookahead of 1 - by default.

 There are two solutions (I haven't checked exact deatils):

 1/ Use LOOKAHEAD(2) so it sees tokens ':z' and ':q' or ':z' (triples) and
 '{' which is the named graphs case.  I think this is in Quads somewhere.

 2/ Leave GRAPH required.

 (2) is fine for now - it will not be too unexpected to users because INSERT
 DATA requires a GRAPH and it is legal TriG, even if not the short form in
 TriG.

 You can come back and look at (1) later.  I'm keen for you to get something
 going as soon as possible, not get lost in details.

 

 Background:

 There is a third solution but it's not as so simple which is to introduce an
 intermediate state of MaybeTriplesMaybeQuads but if you do that, more of
 the grammar needs rewriting.  I'm not sure how widespread the changes would
 be.

 Jena's TriG parser (which is not JavaCC based see
 LangTriG::oneNamedGraphBlock2)

 has this comment:

 // Either :s :p :o or :g { ... }

 and does one look ahead to get the :s or :g (the :z above), keeps that
 hanging around, does another lookahead to see '{' or not, then calls
 turtle(n) if triples.

 In LangTriG:

 turtle() is roughly TriplesSameSubject
 turtle(n) is roughly  PropertyListNotEmpty

 Andy


 On 15/06/15 11:53, Qihong Lin wrote:

 Hi,

 I'm trying to play with master.jj. But the grammar script somethings
 prints warning messages. The behavior is strange. In order to simplify
 my question, I'd like to take the following example:

 In QuadsNotTriples(), line 691 in master.jj, in the master branch:
 
 GRAPH
 
 If I change it to optional (which is required in future
 implementations, for the new grammar):
 
 (GRAPH)?
 
 the grammar script goes like this:

 $ ./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 . . .
 Warning: Choice conflict in [...] construct at line 464, column 4.
   Expansion nested within construct and expansion following
 construct
   have common prefixes, one of which is: VAR1
   Consider using a lookahead of 2 or more for nested expansion.
 Warning: Choice conflict in [...] construct at line 468, column 6.
   Expansion nested within construct and expansion following
 construct
   have common prefixes, one of which is: VAR1
   Consider using a lookahead of 2 or more for nested expansion.
 Warning: Choice conflict in [...] construct at line 484, column 12.
   Expansion nested within construct and expansion following
 construct
   have common prefixes, one of which is: VAR1
   Consider using a lookahead of 2 or more for nested expansion.
 Warning: Choice conflict in [...] construct at line 759, column 3.
   Expansion nested within construct and expansion following
 construct
   have common prefixes, one of which is: VAR1
   Consider using a lookahead of 2 or more for nested expansion.
 Warning: Choice conflict in [...] construct at line 767, column 5.
   Expansion nested within construct and expansion following
 construct
   have common prefixes, one of which is: VAR1
   Consider using a lookahead of 2 or more for nested expansion.
 File TokenMgrError.java does not exist.  Will create one.
 File ParseException.java does not exist.  Will create one.
 File

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

Hi,

I just opened 2 new threads. Your comments are welcome!

regards,
Qihong

On Mon, Jun 15, 2015 at 4:45 PM, Rob Vesse rve...@dotnetrdf.org wrote:
 Folks

 Could you please either start new threads of change the subject line
 appropriately for future discussions on this

 The generic subject line makes it hard when catching up with emails to see
 at a glance what this thread is about

 Thanks,

 Rob

 On 14/06/2015 12:28, Andy Seaborne a...@apache.org wrote:

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 confidence@gmail.com
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 jpz6311...@gmail.com
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 confidence@gmail.com
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

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

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 jpz6311...@gmail.com 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 confidence@gmail.com 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 jpz6311...@gmail.com 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 confidence@gmail.com 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 jpz6311...@gmail.com 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

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

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 jpz6311...@gmail.com 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 confidence@gmail.com 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 jpz6311...@gmail.com 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 confidence@gmail.com 
 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 jpz6311...@gmail.com wrote:
 Hi Qihong,

 As Andy mentioned, the bonding period is for community bonding, not
 just mentor

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

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 jpz6311...@gmail.com 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 confidence@gmail.com 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 jpz6311...@gmail.com 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 a...@apache.org 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 a...@apache.org 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?

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

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 jpz6311...@gmail.com 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 a...@apache.org 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 a...@apache.org 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?

Re: [ANN] GSoC 2015 Accepts a Student Project for Jena

[Qihong Lin]

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 a...@apache.org 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?

Re: Fwd: Proposal submitted [JENA-491]

[Qihong Lin]

Hello,

Please check my reply below:

On Thu, Apr 9, 2015 at 12:07 PM, Ying Jiang jpz6311...@gmail.com 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 a...@apache.org 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:
 IteratorTriple 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 a...@apache.org 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:
 - IteratorQuad 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

Re: Fwd: Proposal submitted [JENA-491]

[Qihong Lin]

Hello Andy,

It's submitted in time. I saw your notes, thanks. Here're some further
questions.

1) API of QueryExecution
Does the API look like:
- IteratorQuad QueryExecution.execConstrucQuads()
- Dataset QueryExecution.execConstructDataset()

2) master.jj
How does master.jj generate arq.jj? What tool? You mentioned is
processed with cpp. What's cpp?

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?
- Shall we consider using variables for named graphs? I mean ?g, not :g:
CONSTRUCT {
# Named graph
GRAPH ?g { ?s :p ?o }
} WHERE


regards,
Qihong

On Wed, Apr 1, 2015 at 9:59 PM, Andy Seaborne a...@apache.org wrote:
 Hi there,

 What's the status on this?  Was it submitted?

 I've put some notes on JENA-491 that related to the proposal about the
 proposed syntax and the way to modify the grammar.

 One of the important things to make sure happens is that the work is visible
 on this list (confidence.sun@ is subscribed so that's a good start) through
 out the project.  It hard to have code appear at the end and integrate it in
 time and I'm working with the assumption that there will be change to the
 main codebase as a result of JENA-491 with no need for extension classes.

 (I looked at the github prototype
 https://github.com/confidencesun/jena/)

 For example, Template class becomes quad-aware and the SPARQL 1.1 usage is
 triples only because the strict syntax can't set things outside the default
 graph of the datasets.  Otherwise, the code is quads throughout.

 So if this going ahead, we should be building community from now on, through
 the bonding period and throughout the project lifetime.  That includes
 regular status and discussions here.  Qihong - After last year with
 Marmotta, I'm sure you know how things work at Apache.

 Andy

 On 25/03/15 13:10, Andy Seaborne wrote:

 Hi Ying,

 Have you signed up as a mentor yet? This is getting to be urgent.
 (instructions forwarded)

 On 03/25/15 01:32, Ying Jiang wrote:

 Hi,

 I can see it's a strong proposal. If possible, I'd be glad to be the
 mentor for this project.
 Andy, if other project is appropriate for Jena, I'm willing to be a
 mentor, or at least a co-mentor, depending on its scopes. Hope it
 helps!


 The two I know of are this one from Qihong and one mention by Dimuthu [*]

 The mentors signup to specific projects - it comes down to what you want
 to do.

  Andy

 [*]

 http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3CCAHzXhOimMQjHeCzdV%3Dp-jegVC-gxdPiXe%3D9QE_aGO%2BT3hfDknw%40mail.gmail.com%3E


 https://issues.apache.org/jira/browse/JENA-624


 Best,
 Ying Jiang




 On Tue, Mar 24, 2015 at 11:50 PM, Andy Seaborne a...@apache.org wrote:

 On 03/24/15 13:54, Qihong Lin wrote:


 Hi Andy,

 I just changed the settings. Is the proposal here [1] now visible
 for you?
 Dr. Ying Jiang mentioned to be the potential mentor. Is that OK?



 Sorry, no.  I'm afraid I don't have time to be a mentor this year.

  Andy




 regards,
 Qihong Lin

 [1]

 http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/confidence_sun/5639274879778816


 On Tue, Mar 24, 2015 at 6:23 PM, Andy Seaborne a...@apache.org wrote:


 Qihong,

 We can't read that URL.

 You need a mentor for the project and at the moment, Jena has very
 people
 with time to be a mentor this year which is severely limiting the
 capacity
 to take on GSoC projects.

   Andy


 On 24/03/15 01:51, Ying Jiang wrote:



 Hi,

 I can not open your proposal. Maybe you can mark it public to
 everyone?

 Although I can give some advice, you'd better also ask for feedback
 from other committers in the Jena community. It's vital to make clear
 the project details through discussion in the dev mailing list before
 GSoC project begins. Guys there are nice and helpful. So, just
 subscribe to it and post your ideas for comments. Good luck!


 Ying Jiang




 -- Forwarded message --
 From: Qihong Lin confidence@gmail.com
 Date: Tue, Mar 24, 2015 at 12:39 AM
 Subject: Proposal submitted
 To: Ying Jiang jpz6311...@gmail.com


 Hello, Dr. Jiang

 I've submitted a project proposal for GSoC 2015. Could you please
 help
 me improve it? Thanks.




 http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/confidence_sun/5639274879778816



 regards,
 Qihong

Re: Fwd: Proposal submitted

[Qihong Lin]

Hi Andy,

I just changed the settings. Is the proposal here [1] now visible for you?
Dr. Ying Jiang mentioned to be the potential mentor. Is that OK?

regards,
Qihong Lin

[1] 
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/confidence_sun/5639274879778816

On Tue, Mar 24, 2015 at 6:23 PM, Andy Seaborne a...@apache.org wrote:
 Qihong,

 We can't read that URL.

 You need a mentor for the project and at the moment, Jena has very people
 with time to be a mentor this year which is severely limiting the capacity
 to take on GSoC projects.

 Andy


 On 24/03/15 01:51, Ying Jiang wrote:

 Hi,

 I can not open your proposal. Maybe you can mark it public to everyone?

 Although I can give some advice, you'd better also ask for feedback
 from other committers in the Jena community. It's vital to make clear
 the project details through discussion in the dev mailing list before
 GSoC project begins. Guys there are nice and helpful. So, just
 subscribe to it and post your ideas for comments. Good luck!


 Ying Jiang




 -- Forwarded message --
 From: Qihong Lin confidence@gmail.com
 Date: Tue, Mar 24, 2015 at 12:39 AM
 Subject: Proposal submitted
 To: Ying Jiang jpz6311...@gmail.com


 Hello, Dr. Jiang

 I've submitted a project proposal for GSoC 2015. Could you please help
 me improve it? Thanks.


 http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/confidence_sun/5639274879778816


 regards,
 Qihong

Re: [GSoC] less 1 month left

[Qihong Lin]

Dear Sergio,

I'm sorry I can't understand you questions. It's appreciated if you
can help me clarify these:

1) If what changes in the new alternative CDI service is just the
invocations to the RepositoryConnection (I'd need to check the diff to
really assert that), would it still make sense to you to provide an
alternative CDIservice?
What do you mean by the new alternative CDI service, and an
alternative CDIservice? I'm now translating the CDI service
(LdpServiceImpl) into SPARQL implementation. If anything changes, I
can translate it accordingly. Is that enough?

2)  Or would be more maintainable to move the translation into an
RepositoryConnection wrapper or something like that?
What's an RepositoryConnection wrapper? Why do we need that (i.e.
why more maintainable )? Can you show me an example? Thanks!

Best regards,
Qihong Lin


On Mon, Jul 28, 2014 at 9:00 PM, Sergio Fernández wik...@apache.org wrote:
 Dear Qihong Lin,


 On 27/07/14 12:41, Qihong Lin wrote:

 I'm making documentation in git wiki:
 [1]
 https://github.com/confidencesun/marmotta/wiki/GSoC-2014-Project-(MARMOTTA-444)
 [2] https://github.com/confidencesun/marmotta/wiki/Developer-Documentation
 [3] https://github.com/confidencesun/marmotta/wiki/User-Documentation


 Perfect. Try to evolve as much as possible that documentation to start to
 prepare the final report.

 A conclusions chapter from your since would be nice. Think about what
 aspects are interesting to discuss.

 Taking a quick look to dev documentation, there is one aspect I'd like to
 hear from you about the mapping of method. If what changes in the new
 alternative CDI service is just the invocations to the RepositoryConnection
 (I'd need to check the diff to really assert that), would it still make
 sense to you to provide an alternative CDIservice? Or would be more
 maintainable to move the translation into an RepositoryConnection wrapper or
 something like that? Think about that, write down your conclusions, and
 ideally provide a proof-of-concept implementation.


 Currently, the SPARQL implementation is up to date to the ldp and
 develop branches. I'll make the translations soon after any new
 changes from upstreams, and report to you in time.


 Probably we'll finally do it early next week. I'll keep you informed.


 Cheers,

 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 660 2747 925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co

Re: [GSoC] less 1 month left

[Qihong Lin]

Dear Sergio,

I'm making documentation in git wiki:
[1] 
https://github.com/confidencesun/marmotta/wiki/GSoC-2014-Project-(MARMOTTA-444)
[2] https://github.com/confidencesun/marmotta/wiki/Developer-Documentation
[3] https://github.com/confidencesun/marmotta/wiki/User-Documentation

Currently, the SPARQL implementation is up to date to the ldp and
develop branches. I'll make the translations soon after any new
changes from upstreams, and report to you in time.

Best regards,
Qihong Lin


On Thu, Jul 24, 2014 at 9:59 PM, Sergio Fernández wik...@apache.org wrote:
 Dear Qihong Lin,


 On 24/07/14 14:06, Qihong Lin wrote:

 Thanks for your reminder! I've been watching the marmotta's branch
 refs/heads/develop (not much changes related to ldp service these
 days). As you pointed out, I just checked the ldp branch and updated
 my LdpServiceSPARQLImpl accordingly [1]. Now both LdpServiceSPARQLImpl
 and LdpServiceImpl passed my unit tests as expected.


 It'd be great if you can report the current status of the SPARQL
 implementation, as well as periodically report your progress.


 I'll keep a close eye on both the develop and ldp branches in the
 coming weeks. With previous experience in the first half part of the
 project, I think it's not difficult to translate the remaining changes
 to the SPARQL implementations. I'll check and translate the changes
 everyday. After the GSoC project, I can also offer contribution
 related to this work.


 That'd be great! That's one of the goals of GSoC is not always explored by
 the student. Hope you can continue collaborating with us after the program
 ends.


 In the meanwhile, I'll work on the documentations and the tests
 (performance, w3c test suite, etc), as you mentioned in the mid-term
 evaluation. I've been studying JMeter, TestNG and Rest-Assured. I'll
 have a try in the next week and keep you posted.


 Where are you documenting all your stuff? As I explained you, I'd appreciate
 to have access to it in advance.


 Cheers,

 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 660 2747 925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co

Re: [GSoC] less 1 month left

[Qihong Lin]

Dear Sergio,

Thanks for your reminder! I've been watching the marmotta's branch
refs/heads/develop (not much changes related to ldp service these
days). As you pointed out, I just checked the ldp branch and updated
my LdpServiceSPARQLImpl accordingly [1]. Now both LdpServiceSPARQLImpl
and LdpServiceImpl passed my unit tests as expected.

I'll keep a close eye on both the develop and ldp branches in the
coming weeks. With previous experience in the first half part of the
project, I think it's not difficult to translate the remaining changes
to the SPARQL implementations. I'll check and translate the changes
everyday. After the GSoC project, I can also offer contribution
related to this work.

In the meanwhile, I'll work on the documentations and the tests
(performance, w3c test suite, etc), as you mentioned in the mid-term
evaluation. I've been studying JMeter, TestNG and Rest-Assured. I'll
have a try in the next week and keep you posted.


Best,
Qihong Lin

[1] 
https://github.com/confidencesun/marmotta/commit/cff11e06c0c13bd8d8a10fea5e9eccf8d31f86ba

On Wed, Jul 23, 2014 at 3:45 PM, Sergio Fernández wik...@apache.org wrote:
 According the official time-line:

 http://www.google-melange.com/gsoc/events/google/gsoc2014

 August 18th is the official 'pencils down' date for GSoC this year.

 Please, Qihong Lin, remember to continue pushing hard. I did not see some
 much activity or reporting in the last weeks, and you still have so much to
 do for achieving the goals of the project.

 We had been working at the ldp branch, fixing details discovered by the W3C
 test suite. They mainly affect the web service layer, but I think we
 extended the service api with some new methods. Next week Jakob and myself
 we plan to continue working on that, with the idea of merging stable changes
 back to develop during the week. Please, stay tune to the changes, and
 decide whether you can afford or not to adopt them at this stage.

 Personally I'll offline 6th to 20th, so everything that you deliver before
 would make my final evaluation much easier.

 Thanks for your contribution to the Apache Marmotta project.

 Cheers,

 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 660 2747 925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co

Re: [GSoC] dev period

[Qihong Lin]

Dear Sergio,

I just figured out the reason of the problem 1). The bean.xml was not
copied into the building output folder, although was in the source
folder. I fixed it in eclipse. Everything works well now.

Could you please just help me with the problem 2)? Thanks a lot!

Yours,
Qihong Lin

On Tue, Jun 3, 2014 at 8:46 PM, Qihong Lin confidence@gmail.com wrote:
 Dear Sergio,

 I try to fix the problems you commented. The code have been just committed 
 [1].

 But there're some further issues to discuss:

 1) EmbeddedMarmotta
 I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
 is added at src\test\resources\META-INF. But it throws
 DeploymentException: WELD-001408 (see Apendix (1): stack trace for
 running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
 in marmotta-core also throws UnsatisfiedResolutionException:
 WELD-001308 at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
 EmbeddedMarmotta itself have some problems? Or am I wrong for any
 configuration mistakes of weld CDI? Finally, I have to restore the
 code to the ugly new LdpServiceSPARQLImpl() approach for testing.

 2) RDF resource VS. LDP-RS
 I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
 But it seems that most of the rules are out of the scopes of my SPARQL
 implementation work. For example, the rules like HTTP Link header
 and HTTP Request-URI for LDP-RS are not concerned in the level of my
 work. Is that correct?
 I try to make the equivalent method for LdpServiceImpl.exists(), which
 has only one sentence:
 return connection.hasStatement(resource, null, null, true, ldpContext);
 It uses ldpContext pointing to http://www.w3.org/ns/ldp#;, which is
 a graph name in the triplestore. Does it mean all of the LDP-RSs must
 be in the graph of http://www.w3.org/ns/ldp#;? I don't see this
 request in the W3C LDP documentation[3]. What's your opinion?
 It uses true for the 4th parameter of connection.hasStatement()
 method, which includes inferred ones during querying. But I see this
 in the W3C LDP documenation [3]:
 4.3.1.10 LDP servers must not require LDP clients to implement
 inferencing in order to recognize the subset of content defined by LDP
 ... The practical implication is that all content defined by LDP must
 be explicitly represented, unless noted otherwise within this
 document.
 Therefore, shall we change it to false to avoid inferred triples?
 Further more, should I care about SPARQL Entailment Regimes [4]? No?

 Best regards,
 Qihong Lin


 [1] 
 https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
 [2] 
 https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
 [3] http://www.w3.org/TR/ldp/#ldprs
 [4] http://www.w3.org/TR/sparql11-entailment/

 Appendix (1): stack trace for running LdpServiceSPARQLImplTest
 org.jboss.weld.exceptions.DeploymentException: Exception List with 4 
 exceptions:
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408:
 Unsatisfied dependencies for type ConfigurationService with qualifiers
 @Default
   at injection point [BackedAnnotatedField] @Inject protected
 org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
   at 
 org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)

 at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
 at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
 at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
 at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
 at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
 at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
 at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
 at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
 at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 Exception 0 :
 org.jboss.weld.exceptions.DeploymentException: WELD-001408:
 Unsatisfied dependencies for type ConfigurationService with qualifiers
 @Default
   at injection point [BackedAnnotatedField] @Inject private
 org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
   at 
 org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService

Re: [GSoC] dev period

[Qihong Lin]

Dear Sergio,

I try to fix the problems you commented. The code have been just committed [1].

But there're some further issues to discuss:

1) EmbeddedMarmotta
I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
is added at src\test\resources\META-INF. But it throws
DeploymentException: WELD-001408 (see Apendix (1): stack trace for
running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
in marmotta-core also throws UnsatisfiedResolutionException:
WELD-001308 at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
EmbeddedMarmotta itself have some problems? Or am I wrong for any
configuration mistakes of weld CDI? Finally, I have to restore the
code to the ugly new LdpServiceSPARQLImpl() approach for testing.

2) RDF resource VS. LDP-RS
I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
But it seems that most of the rules are out of the scopes of my SPARQL
implementation work. For example, the rules like HTTP Link header
and HTTP Request-URI for LDP-RS are not concerned in the level of my
work. Is that correct?
I try to make the equivalent method for LdpServiceImpl.exists(), which
has only one sentence:
return connection.hasStatement(resource, null, null, true, ldpContext);
It uses ldpContext pointing to http://www.w3.org/ns/ldp#;, which is
a graph name in the triplestore. Does it mean all of the LDP-RSs must
be in the graph of http://www.w3.org/ns/ldp#;? I don't see this
request in the W3C LDP documentation[3]. What's your opinion?
It uses true for the 4th parameter of connection.hasStatement()
method, which includes inferred ones during querying. But I see this
in the W3C LDP documenation [3]:
4.3.1.10 LDP servers must not require LDP clients to implement
inferencing in order to recognize the subset of content defined by LDP
... The practical implication is that all content defined by LDP must
be explicitly represented, unless noted otherwise within this
document.
Therefore, shall we change it to false to avoid inferred triples?
Further more, should I care about SPARQL Entailment Regimes [4]? No?

Best regards,
Qihong Lin


[1] 
https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
[2] 
https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
[3] http://www.w3.org/TR/ldp/#ldprs
[4] http://www.w3.org/TR/sparql11-entailment/

Appendix (1): stack trace for running LdpServiceSPARQLImplTest
org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject protected
org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
  at 
org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)

at 
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at 
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at 
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at 
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at 
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
  at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
  at 
org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService(LdpServiceImpl.java:0)

at 
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514

Re: [GSoC] community bonding period

[Qihong Lin]

Dear Sergio,

I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
resource. The unit test has been made as well.
Please check my last 2 commits:
https://github.com/confidencesun/marmotta/commits/MARMOTTA-444

However, the unit test seems to be ugly. You can see in
LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
object of LdpServiceSPARQLImpl. Is there other more elegant way to
test LdpServiceSPARQLImpl?
Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
ConfigurationService and ldpContext. How can I make the unit test by
injecting them into LdpServiceSPARQLImpl?

Best regards,
Qihong Lin


On Tue, May 20, 2014 at 4:47 PM, Sergio Fernández wik...@apache.org wrote:
 Hi Qihong,


 On 20/05/14 10:30, Qihong Lin wrote:

 I've already set up the development environment. I'm ready to begin
 coding in that fork.


 Great.


 The test suite and the test cases were removed from the code
 repository on 5th May. Could you please tell me why? Any problems with
 the tests? Can I reuse the removed test cases in my fork to ensure the
 expected behaviors of my code?


 The work on the test suite has been moved to github in collaboration with
 other member of the LDP WG:

   https://github.com/w3c/ldp-testsuite

 I've closed MARMOTTA-438 accordingly.

 Anyway, it still needs to be stabilized until it reports proper results. In
 the meantime you can use our custom unit tests, that's more than enough for
 the earlier phases.


 Cheers,

 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at

Re: [GSoC] community bonding period

[Qihong Lin]

Dear Sergio,

I've already set up the development environment. I'm ready to begin
coding in that fork.

The test suite and the test cases were removed from the code
repository on 5th May. Could you please tell me why? Any problems with
the tests? Can I reuse the removed test cases in my fork to ensure the
expected behaviors of my code?

Best regards,
Qihong Lin


On Mon, May 19, 2014 at 9:01 PM, Sergio Fernández wik...@apache.org wrote:
 Hi,

 according to the official timeline:

 http://www.google-melange.com/gsoc/events/google/gsoc2014

 today students begin coding for their Google Summer of Code projects;
 Google begins issuing initial student payments provided tax forms are on
 file and students are in good standing with their communities.

 I've saw some activity at the MARMOTTA-444 fork at github:

 https://github.com/confidencesun/marmotta/commits/MARMOTTA-444

 Please Qihong Lin, let me know if you have any question to actually start to
 work. I think we can privately talk for some internal details of your
 project (you can find me at skype as sergio.fernandez.lopez), but you should
 periodically report your progress here, probably according the project plan
 submitted with your proposal:

 http://www.google-melange.com/gsoc/proposal/review/org/google/gsoc2014/confidence_sun/5629499534213120

 Good luck!

 Cheers,


 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at

Re: [GSoC] community bonding period

[Qihong Lin]

Dear Sergio,

I follow your instructions to complete these task, with some questions:

1) I fork the mirror as confidencesun/marmotta [1], while
confidencesun is my github id.
I add you in the Collaborators of this repository [1]. Is that the
way you get the admin permissions?

2) I create a branch of MARMOTTA-444 from develop
I use eclipse (Juno), egit and m2e as the development tools to work it
out. Do you the same toolkit?

3) I clone the repository [1] to the local git.
I also try to import the local marmotta-ldp into eclipse as a maven
project. But at the step of Setup Maven plugin connectors, I get the
error:

No marketplace entries found to handle
maven-download-plugin:1.1.0:wget in Eclipse.  Please see Help for more
information.

I choose to resolve later, and pom of the project marmotta-ldp
shows the error:

Plugin execution not covered by lifecycle configuration:
com.googlecode.maven-download-plugin:maven-download-plugin:1.1.0:wget
(execution: download-ldp-test-cases, phase: process-test-resources)

It seems the m2e connector of maven-download-plugin is not installed
properly. I google for a long time, without successful solutions.
Could you please help me out?

4) I have to comment out the maven-download-plugin in the pom to
make everything compiles in eclipse. The project of marmotta-ldp and
its dependency projects look fine now in eclipse (see the attachment
picture). I think, the project of marmotta-ldp is the place I'd play
around, in this summer.

5) I push the modification of 4) to the remote github branch of
MARMOTTA-444. It seems OK. I think this is the way to commit code :)
Could you please make any modification to the upstream? I'd like to
test the pull synchronization.


Cheers,
Qihong Lin

[1] https://github.com/confidencesun/marmotta
[2] https://github.com/maven-download-plugin/maven-download-plugin




On Tue, Apr 29, 2014 at 5:46 PM, Sergio Fernández wik...@apache.org wrote:
 Hi Qihong Lin,


 On 26/04/14 15:13, Qihong Lin wrote:

 Thanks for your reminder! I'm so happy to be accepted by GSoC. I'll
 try my best in this summer to contribute to Marmotta.


 I'm sure you will ;-)


 In the first place, I'd like to set up the development environment.
 I've read the documentation of Marmotta development [1]. Could you
 please tell me where I should commit the code, in asf [2] or github
 [3]? Which branch am I supposed to work with, the hotfix branch,
 develop branch or the master branch? Shall I submit the patches to the
 community or directly commit the code to git?


 I do not have so much experience with GSoC, and as far as I've checked there
 is no common approach among all ASF projects...

 For me the best approach would be to use github for developing your project.
 So, you can:

   * Fork our mirror there [1] and give me (wikier) admin permissions.
   * Create, at least,  a branch from 'develop' for your project;
 according our development guidelines [2], I'd recommend you to
 use the issue [3] as name for the branch: MARMOTTA-444.
   * I'll closely follow your development there, using the comments on
 the code committed to provide you early feedback.
   * Create issues there for internal issues of the project.
   * But please use this mailing list for any further discussion.
   * Since your project is related with code that is still evolving,
 try to keep periodically updated your fork from upstream [4].

 Therefore, at the end we have all information to evaluate if your code it's
 suitable to be integrated with Marmotta, legally and technically.

 I think that could work. Before May 19, you still have some weeks to play
 with this environment, get used with Marmotta, and ask us any other
 question.

 Good luck!

 Cheers,


 [1] https://github.com/apache/marmotta
 [2] http://marmotta.apache.org/development
 [3] https://issues.apache.org/jira/browse/MARMOTTA-444
 [4] https://help.github.com/articles/syncing-a-fork


 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at

Re: [GSoC] community bonding period

[Qihong Lin]

Dear Sergio,

Thanks for your reminder! I'm so happy to be accepted by GSoC. I'll
try my best in this summer to contribute to Marmotta.

In the first place, I'd like to set up the development environment.
I've read the documentation of Marmotta development [1]. Could you
please tell me where I should commit the code, in asf [2] or github
[3]? Which branch am I supposed to work with, the hotfix branch,
develop branch or the master branch? Shall I submit the patches to the
community or directly commit the code to git?

Best regards,
Qihong Lin

[1] http://marmotta.apache.org/development.html
[2] git:https://git-wip-us.apache.org/repos/asf/marmotta.git
[3] https://github.com/apache/marmotta

On Wed, Apr 23, 2014 at 7:43 PM, Sergio Fernández wik...@apache.org wrote:
 Hi,

 in case you missed it, about two days ago Google announced which students
 got accepted into this year’s SoC:

 http://www.google-melange.com/gsoc/projects/list/google/gsoc2014

 From the 3 proposals submitted to Apache Marmotta, for different reasons
 only 1 has been finally accepted:

 Implementation of the LDP service for Apache Marmotta
 based on SPARQL 1.1, by Qihong Lin
 http://goo.gl/yX3fvi
 inspired by MARMOTTA-444

 Thanks for all the students who have spent time preparing proposals. Even
 without the granting from Google, the project would be still interested on
 implementing such features. So I'd like to invite you to join the project,
 as long as you are still interested.

 Now, until May 19, we are in the community bonding period:

 http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bonding-all.html

 During this period students should learn about Marmotta, our release
 processes, the Apache Way, how we do things around here, interact with the
 community and close any knowledge gaps they might have. Please, we encourage
 to actually use this extra month for the benefit of your projects.

 Next up will be start of coding on May 19 followed by the midterm
 evaluations between June 23 and June 27. I will inform you separately about
 this.

 Have a good SoC!

 Kind regards,

 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at

Re: Contribute to Marmotta in GSoC 2014 (Provide an alternative SPARQL-based implementation of the LdpService)

[Qihong Lin]

Dear Sergio,

Thank you! I saw your update of MARMOTTA-444 on the new deadline of 31 July.
I just submitted my proposal [1] to the GSoC website, with a project plan
conforming to the deadline. Any comments are welcome!

Cheers,
Qihong Lin

[1]
https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/confidence_sun/5629499534213120



On Mon, Mar 10, 2014 at 5:41 PM, Sergio Fernández wik...@apache.org wrote:

 Dear Qihong Lin,


 On 07/03/14 09:23, Qihong Lin wrote:

 I have been composing the project proposal draft these days. I find some
 GSoC proposal examples, most of which contain the time table parts. I'd
 like to include the project schedule as well in my proposal.

 Basically GSoC 2014 goes in this way:
 
 Begin coding: 19 May
 Mid-term evaluation: 27 June
 End coding: 11 August
 

 However I find that the due date of MARMOTTA-444 in Jira is 30 June. Does
 it mean that I'm supposed to complete the work before the mid-term of GSoC
 2014? If so, how about the second part of the summer in July and August? I
 believe the Marmotta community has its plan of developing the Linked Data
 Platform implementations. I don't want to delay your original plan because
 of the GSoC program. Could you please tell me about the desired schedule?


 Don't worry, the date there was more a wish than an actual planned date.
 But that date fits with the GSoC's mid-term evaluation, which potentially
 is a good checkpoint for your project.


 Cheers,

 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at

Re: Contribute to Marmotta in GSoC 2014 (Provide an alternative SPARQL-based implementation of the LdpService)

[Qihong Lin]

Hi,

Please check my replays and questions below:

On Fri, Feb 28, 2014 at 4:12 PM, Sergio Fernández wik...@apache.org wrote:

 Dear Qihong Lin,


 On 28/02/14 08:23, Qihong Lin wrote:

 I'm Qihong Lin from Beijing Normal University Zhuhai Campus, P.R. China. I
 did some student projects in my university related to Semantic Web. I have
 good knowledge of RDF, SPARQL, Linked Data, with some development
 experience of Sesame and Jena. According to my background, I'd like to
 contribute to Marmotta in GSoC 2014, on MARMOTTA-444 [1] (Provide an
 alternative SPARQL-based implementation of the LdpService).


 Right now Jakob and myself are working on a Sesame-native implementation
 (for more details, see MARMOTTA-440 and the ldp branch on git), and we hope
 to have it sufficiently evolve to give a proper working framework for the
 project.

I can anticipate you it'd require quite good knowledge of SPARQL 1.1, as
 well of RDF and Sesame.


It seems the api and implementation are still in progress.
Is LdpService.java supposed to conform to the W3C working draft in 2013-07
[1] or the latest one here [2]? When will Linked Data Platform become a W3C
recommendation?

Now, I can totally understand the source code of Sesame-native
implementation. I have good knowledge of SPARQL 1.1. With Sesame, I can
write codes of SPARQL Query for LdpService.exists() and getStatements(),
while SPARQL Update [3] for LdpService.addResource() and deleteResource().
As to LdpService.exportResource() and generateETag(), it's just required to
translate the inline getStatement() codes into SPARQL queries. Am I right
about the above approaches?



  I also have some basic skills of SVN, Junit and Dependency Inversion. But
 I
 didn't work on open source projects before. Marmotta would be my first
 open
 source community to get involved, if I can get accepted. It's
 greatly appreciated if you can help me with the project application and
 the
 coding work.


 We use industry standards: git for code control, maven as build tool,
 junit and rest-assured for testing, Weld for CDI, etc. But don worry if
 your are not some familiar with any, because in case your proposal gets
 granted, a mentor will be assigned to help during the project execution.


Thanks for telling me about these. I'm familiar with maven and junit. As to
git and Weld, I've just started to learn their documents. Is rest-assured
the one here [4]?




  Is there a project proposal template to refer to?


 Sorry, this is the first time we participate in the GSoC. So we did not
 prepare any project proposal template. But I think what the general
 documentation describes should more than enough:

 https://www.google-melange.com/gsoc/document/show/gsoc_
 program/google/gsoc2014/help_page#5._What_should_a_student_proposal_look

 Hope this helps. Whatever other question you may have, just ask.


Thanks again, it helps a lot!



 Thanks for your interest.

 Cheers,

 --
 Sergio Fernández
 Senior Researcher
 Knowledge and Media Technologies
 Salzburg Research Forschungsgesellschaft mbH
 Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
 T: +43 662 2288 318 | M: +43 660 2747 925
 sergio.fernan...@salzburgresearch.at
 http://www.salzburgresearch.at


Best regards,
Qihong Lin

[1] http://www.w3.org/TR/ldp/
[2] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html
[3] http://www.w3.org/TR/sparql11-update/
[4] http://code.google.com/p/rest-assured

Contribute to Marmotta in GSoC 2014 (Provide an alternative SPARQL-based implementation of the LdpService)

[Qihong Lin]

Hi all,

I'm Qihong Lin from Beijing Normal University Zhuhai Campus, P.R. China. I
did some student projects in my university related to Semantic Web. I have
good knowledge of RDF, SPARQL, Linked Data, with some development
experience of Sesame and Jena. According to my background, I'd like to
contribute to Marmotta in GSoC 2014, on MARMOTTA-444 [1] (Provide an
alternative SPARQL-based implementation of the LdpService).

I also have some basic skills of SVN, Junit and Dependency Inversion. But I
didn't work on open source projects before. Marmotta would be my first open
source community to get involved, if I can get accepted. It's
greatly appreciated if you can help me with the project application and the
coding work. Now I'm studying the documents of Marmotta. I can understand
the description in MARMOTTA-444 in jira. Could you please tell me more
details about it? Is there a project proposal template to refer to?

Best,
Qihong Lin

[1] https://issues.apache.org/jira/browse/MARMOTTA-444