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: svn commit: r1696184 - /jena/site/trunk/content/documentation/query/construct-quad.mdtext

[Qihong Lin]

 Hi Dr. Jiang,

Here's the revised doc. Please help me commit it.

Thanks
Qihong

On Tue, Aug 18, 2015 at 3:46 PM, Qihong Lin  wrote:
> 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  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  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,

I've committed the code according to your suggestion. The server side
only runs QueryExecutionBase::execConstructQuads().

I've also hacked QueryEngineHTTP to test the conneg of
execConstructTriples() and execConstructQuads(). For
execConstructQuads(), all of the content types in DEF.quadsOffer have
been tested: if the client sends Accept content type of, e.g. TriG,
the sever will response with the desired same content type.
Please check the PR 91: TestQuery.query_construct_quad_conneg()

regards,
Qihong

On Tue, Aug 18, 2015 at 4:26 PM, Andy Seaborne  wrote:
> On 18/08/15 08:44, Qihong Lin wrote:
>>
>> 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().
>
>
> I wrote:
>>> a combined DEF.rdfOffer+DEF.quadsOffer
>
> Create a new offer which combines all the languages you want.
> DEF.constructOffer.
>
> If the language is quad-supporting, RDFLanguages.isQuads is true, process as
> a dataset regardless.
>
> It does not matter if the client is asking for a model or a dataset because
> in all syntax cases, a dataset of just the default (the unnamed) graph looks
> like a single graph.  This is while you can generalise to work in datasets
> for much of the processing.  The default graph in a datasets is written as
> just triples without a graph field.
>
>> 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.
>
>
> If they call execConstructTriples, then either the CONSTRUCT query will only
> have a default graph template or it's an extended syntax query and you want
> the default graph.  In both cases, parse to a steam of triples.  The parsers
> skip named graphs when they are asked for triples only.
>
>> 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?
>
>
> That would probably also work but it is not what the code is doing in
> SPARQL_Query.  It just offers DEF.pureRdfOffer and then tests for *. There
> is no datasets content negotation possible (e.g. n-quads vs Trig) because
> the process can't get to ResponseDataset with application/n-quads set, say.
> The only way I can see to get there is a Accept-type of "*" in SPARQL_Query.
>
> Try it in a debugger.
>
> hack to run Fusek2 clean in Eclipse (string names need changing):
>
> public class DevFuseki2 {
>   public static void main(String[] args) {
> String DIR = "/home/afs/ASF/jena-491/" ;
> System.setProperty("FUSEKI_HOME",
>DIR+"jena-fuseki2/jena-fuseki-core") ;
> String fusekiBase =
> "/home/afs/ASF/jena-491/jena-fuseki2/jena-fuseki-core/run" ;
> System.setProperty("FUSEKI_BASE", fusekiBase) ;
> String runArea = Paths.get(fusekiBase).toAbsolutePath().toString() ;
> //  Delete any previous state.
> // FileOps.ensureDir(runArea) ;
> FusekiCmd.main() ;
> System.exit(0) ;
>   }
> }
>
>
> Andy
>
>
>>
>> regards,
>> Qihong
>>
>> On Mon, Aug 17, 2015 at 10:49 PM, Andy Seaborne  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 

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  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  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,

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  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: 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  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  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  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  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"?
>>>>>
>>&

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

[Qihong Lin]

Hi,

I modified the doc here, using the anonymous username:

Index: trunk/content/documentation/query/index.mdtext
===
--- trunk/content/documentation/query/index.mdtext  (revision 1655891)
+++ trunk/content/documentation/query/index.mdtext  (working copy)
@@ -46,6 +46,7 @@
 -   [Sub-SELECT](sub-select.html)
 -   [Negation](negation.html)
 -   [Conditions in FILTERs](function_forms.html)
+-   [Construct quad](construct-quad.html)


I'd like to compose the construct quad documentation in the above new
"construct-quad.html". Could you tell me how to create a new wiki page
in jena website?

regards,
Qihong

On Tue, Aug 11, 2015 at 10:35 AM, 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
>
>
> On Mon, Aug 10, 2015 at 9:58 PM, Andy Seaborne  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  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
>>>>> -

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  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) Iterator execTriples()
>> 2) Iterator 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  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 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  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'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) Iterator execTriples()
2) Iterator 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  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  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
>>>> 

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  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  {: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 
>> wrote:
>>>
>>> Hi Qihong,
>>>
>>> I re-checked the code you commited. Most of the hashCode issues
>>> for arq.qparse that Andy

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 : 

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

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

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

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

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

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

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  : 

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

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  : 

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

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  : 

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 : 

CONSTRUCT {
   GRAPH  {:s :p :o .}
   }
WHERE {}
 Output of qparse --file syntax-quad-construct-07.arq
PREFIX  : 

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

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

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

On Sun, Aug 2, 2015 at 9:14 AM, Ying Jiang  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  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 : 
>>
>> CONSTRUCT { GRAPH :g { :s :p :o } } WHERE {}
>>  Output of qparse --file syntax-quad-construct-01.arq
>> PREFIX  : 
>>
>> CONSTRUCT
>>   { GRAPH  {:s :p :o .}
>>   }
>> WHERE
>>   {  }
>>  Issue:
>> Minor: formatting of  should be :g
>>
>>  File: syntax-quad-construct-02.arq
>> PREFIX : 
>>
>> CONSTRUCT { GRAPH ?g { ?s ?p ?o } } WHERE { ?s ?p ?o }
>>  Output of qparse --file syntax-quad-construct-02.arq
>> PREFIX  : 
>>
>> CONSTRUCT
>>   { GRAPH ?g {?s ?p ?o .}
>>   }
>> WHERE
>>   { ?s  ?p  ?o }
>> 
>> OK
>>
>>  File: syntax-quad-construct-03.arq
>> PREFIX : 
>>
>> CONSTRUCT { :s :p :o } WHERE {}
>>  Output of qparse --file syntax-quad-construct-03.arq
>> PREFIX  : 
>>
>> CONSTRUCT
>>   { GRAPH  {:s :p :o .}
>>   }
>> WHERE
>>   {  }
>>  Issue:
>> Major: The output is contains "GRAPH "
>>
>> Note:  is for internal use only.
>>
>> For syntax, that is a named graph just like 

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  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  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 
>>> Date: Tue, Jul 21, 2015 at 9:25 AM
>>> Subject: Fwd: Final Deliveries of GSoC Project (JENA-491)
>>> To: Ying Jiang 
>>>
>>>
>>> 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 
>>> Date: Sun, Jul 19, 2015 at 5:52 AM
>>> Subject: Re: Final Deliveries of GSoC Project (JENA-491)
>>> To: "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 
>>>   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  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  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: [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  wrote:
> On 16/06/15 09:06, Qihong Lin wrote:
>>
>> Hi,
>>
>> Thanks! I just marked  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:name"syntax-select-expr-01.arq" ;
>mf:action   ;.
>
> 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:name"Construct Quads 1" ;
> mf:action
>  [ qt:query   ;
>qt:data] ;
> mf:result  
> .
>
> 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,

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  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  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: [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  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  wrote:
> On 15/06/15 11:36, Qihong Lin wrote:
>>
>> Hi,
>>
>> Please check my last 3 commits[1], related to refactoring Template.
>> master.jj is modified accordingly, *without* implementing the new
>> CONSTRUCT query function for quad. Just to make sure: the maven build
>> test for this jena-arq module is successful.
>>
>> Here're some ideas for to discuss:
>>
>> (1) Leaving the existing methods/constructors in-place , such as new
>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>> parser does not need change.
>
>
> Good!
>
>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>> QuadPattern), because other parts of master.jj use it for parsing
>> quads.
>
>
> That's workable but it could be a bit neater with a builder pattern like the
> current Template(BGP).
>
> The original code had TripleCollectorBGP as the builder and when it's
> finished the parsing step for the CONSTRUCT template, there is a call of
> getBGP() that yields the BGP.  They may not be a real copy - that's an
> efficiency hack, not a design issue.
>
> Template for quads should follow the same pattern.  The constructor for
> Template can take List (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  wrote:
> On 16/06/15 12:19, Andy Seaborne wrote:
>>
>> On 15/06/15 11:36, Qihong Lin wrote:
>>>
>>> Hi,
>>>
>>> Please check my last 3 commits[1], related to refactoring Template.
>>> master.jj is modified accordingly, *without* implementing the new
>>> CONSTRUCT query function for quad. Just to make sure: the maven build
>>> test for this jena-arq module is successful.
>
>
> Is there an example that I can try?
>
>>>
>
> You should be able to leave the SPARQL 1.1 version of CONSTRUCT alone. It's
> only the ARQ-extended form that should have your grammar.  The SPARQL 1.1
> parser (like the SPARQL 1.0 parser) will be unchanged although changes in
> whitespace etc in the generated java will get in the way of seeing that.
>
> master.jj:
>
>
> #ifdef ARQ
> void ConstructQuery() ;  { Template t ;
>   QuadAcc acc = new QuadAcc() ; }
> ...
> #else
> void ConstructQuery() : { Template t ;
>   QuadAcc acc = new QuadAcc() ; }
>
> This second branch should be the same bytes as the existing master.jj:
>
> void ConstructQuery() : { Template t ;
>   TripleCollectorBGP acc = new TripleCollectorBGP()
> ; }
> {
> ...
>
>
> You can test from the command line using the arq.qparse tool.  Either
>
> java -cp ... arq.qparse --syntax=ARQ --file=...
>
> or
>
> java -cp ... arq.qparse --file=Q.arq
>
> The .arq extension will change it to ARQ syntax.
>
> I'm looking forward to trying it out ...
>
> Andy
>
>
>>> Here're some ideas for to discuss:
>>>
>>> (1) Leaving the existing methods/constructors in-place , such as new
>>> Template(basic graph pattern), so the source code for the SPARQL 1.0
>>> parser does not need change.
>>
>>
>> Good!
>>
>>> (2) Add new constructors of Template(QuadAcc qp) for future use for
>>> the new CONSTRUCT query for quad. I use QuadAcc here (instead of
>>> QuadPattern), because other parts of master.jj use it for parsing
>>> quads.
>>
>>
>> That's workable but it could be a bit neater with a builder pattern like
>> the current Template(BGP).
>>
>> The original code had TripleCollectorBGP as the builder and when it's
>> finished the parsing step for the CONSTRUCT template, there is a call of
>> getBGP() that yields the BGP.  They may not be a real copy - that's an
>> efficiency hack, not a design issue.
>>
>> Template for quads should follow the same pattern.  The constructor for
>> Template can take List (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  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  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  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  wrote:
>> Qihong,
>>
>> There is an ambiguity in the grammar if you make  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  then the entry to QuadsNotTriples is marked by a  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  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:
>>> 
>>> 
>>> 
>>> If I change it to "optional" (which is required in future
>>> implementations, for the new grammar):
>>> 
>>> ()?
>>> 
>>> 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: 
>>>   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 a

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  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"  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 
>>>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 
>>>>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 
>>>>>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=

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

[Qihong Lin]

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:



If I change it to "optional" (which is required in future
implementations, for the new grammar):

()?

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: 
 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: 
 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: 
 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: 
 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: 
 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 "Token.java" does not exist.  Will create one.
File "JavaCharStream.java" does not exist.  Will create one.
Parser generated with 0 errors and 5 warnings.
 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 . . .
Warning: Choice conflict in [...] construct at line 486, column 4.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 490, column 6.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 811, column 3.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in [...] construct at line 819, column 5.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 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 "Token.java" does not exist.  Will create one.
File "JavaCharStream.java" does not exist.  Will create one.
Parser generated with 0 errors and 4 warnings.
 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

But I can see "()?" at line 339 without any trouble. Could you
please tell me why?

regards,
Qihong

[GSoC 2015 - JENA-491] Refactoring Template

[Qihong Lin]

Hi,

Please check my last 3 commits[1], related to refactoring Template.
master.jj is modified accordingly, *without* implementing the new
CONSTRUCT query function for quad. Just to make sure: the maven build
test for this jena-arq module is successful.

Here're some ideas for to discuss:

(1) Leaving the existing methods/constructors in-place , such as new
Template(basic graph pattern), so the source code for the SPARQL 1.0
parser does not need change.
(2) Add new constructors of Template(QuadAcc qp) for future use for
the new CONSTRUCT query for quad. I use QuadAcc here (instead of
QuadPattern), because other parts of master.jj use it for parsing
quads.


Anything inappropriate? If it's generally OK, I'd like to continue
working on master.jj.

regards,
Qihong


[1] https://github.com/confidencesun/jena/commits/JENA-491

Re: [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  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  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  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

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

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  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  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  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  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
&g

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  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  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  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  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  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  wrote:
>> Hi Ying,
>>
>> What is the next process step for GSoC this year?
>>
>> As mentor, you probably want to see this project as starting now.  As you
>> know, I don't have time to mentor this year and so can't really guarantee
>> technical invovement at short notice.
>>
>> The proposal will updating for the comments; it also needs to be made
>> consistent.  This is better now as part of the submission process, not in
>> the bonding stage.  It'll improve the proposal evaluation.
>>
>> e.g,. the javacc grammar changes should be done first.  Not much point
>> hacking the generated java parser (it'll be over written by the grammar
>> compiler).
>>
>> e.g. Documentation should arrive with a deliverable, not later (writing the
>> document, which isn't going to be very large, helps check the design).
>>
>> Ying - do you want to work with Qihong to do that? As discussion on dev@?
>>
>> The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the
>> first half is larger so it may not split at the mid-term evaluation.
>>
>> What will be important for this project is regular email traffic to dev@.
>> It's all about making a smooth path for change.  This isn't a new module,
>> this is making changes to an area users depend on already. Several people
>> here will want to know what's happening, hopefully comment; we should break
>> the deliverables up to get them in piece by piece, not wait until the end.
>>
>> Using github and generating pull requests throughout the project will work
>> best.  There needs to be a fallback in case github is not accessible after
>> our experiences of last year.
>>
>> Qihong - do you have any questions on the process?
>>
>> Andy
>>
>>
>> On 07/04/15 15:00, Ying Jiang wrote:
>>>
>>> Hi Andy,
>>>
>>> Thanks for answering Qihong's questions! JENA-491 is not original from
>>> my idea. So, I'm very grateful if you can help the student to clarify
>>> the project goals and the scopes. Then, as the mentor, I can push the
>>> project going on when it starts, with technical assistance regarding
>>> Jena.
>>>
>>> For the first question, is it OK to expose Quad to end user in
>>> querying? I mean, we have 2 layers of Jena API: the higher one of
>>> Model/Statement/Resource, and the underlying Graph/Triple/Quad/Node.
>>> It makes sense to me if we encourage the end users using the former as
>>> much as possible. Currently, in the API, we already have:
>>> Iterator QueryExecution.execConstructTriples(). I have the
>>> same doubt with it. What's your opinion?
>>>
>>> Best,
>>> Ying Jiang
>>>
>>> On Sun, Apr 5, 2015 at 2

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:
- Iterator 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  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  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  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 
>>>>>>> Date: Tue, Mar 24, 2015 at 12:39 AM
>>>>>>> Subject: Proposal submitted
>>>>>>> To: Ying Jiang 
>>>>>>>
>>>>>>>
>>>>>>> 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  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 
>> Date: Tue, Mar 24, 2015 at 12:39 AM
>> Subject: Proposal submitted
>> To: Ying Jiang 
>>
>>
>> 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 2014] Project Deadline Approaching

[Qihong Lin]

Dear Sergio,

I've completed the documentation. The final evaluation has also been
submitted to Google.
Thanks a lot for your mentoring during the project! It's a great
experience working with you.
Please let me know if anything I can help in future.

Cheers,
Qihong Lin



On Wed, Aug 13, 2014 at 3:32 AM, Sergio Fernández
 wrote:
> Dear Qihong Lin,
>
> On Aug 11, 2014 10:15 AM, Qihong Lin  wrote:
>> Any updates on Marmotta LDP implementations? I checked the "develop"
>> and "ldp" branches, but nothing changed. Am I missing something?
>
> There was no much progress on that in the last week, and now most of us we're 
> on vacations.
>
> But don't worry. From the beginning the scope of your project was what we had 
> when you started. All new additions were something nice to have, and we 
> appreciate your effort taking them into account, but that's not critical.
>
>> The GSoC project is supposed to end in 18th August [1]. It's OK, if
>> it's not convenient for you to deliver the code before the deadline. I
>> can still contribute to this work after the GSoC program ends. Thanks!
>
> Yes. Yesterday was the suggested pencils down date. You are now expected to 
> wrap up your project, finish documentation, write some
> more tests, etc.
>
> After the project we'll see how we continue adapting and maintaining your 
> code.
>
> Thanks.
>
> King regards,

[GSoC 2014] Project Deadline Approaching

[Qihong Lin]

Dear Sergio,

Any updates on Marmotta LDP implementations? I checked the "develop"
and "ldp" branches, but nothing changed. Am I missing something?

The GSoC project is supposed to end in 18th August [1]. It's OK, if
it's not convenient for you to deliver the code before the deadline. I
can still contribute to this work after the GSoC program ends. Thanks!

Yours,
Qihong Lin

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

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  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  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  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] LDP based on SPARQL, mid-term checkpoint

[Qihong Lin]

Dear Sergio,

I've just translated all of the methods into SPARQL implementations,
and committed the code. I'll watch the upstream, in case new methods
or modifications are coming. It's actually ahead of the original plan.

Thanks for sharing your opinions of my current work. In the next
weeks, I'll resolve the problems you pointed out (i.e. tests,
documentations, code abstractions and evaluations). Basically, I think
everything is going on well until now. I'll turn to you for help, if
there's any further question. Thanks a lot!

Cheers,
Qihong Lin


On Tue, Jun 24, 2014 at 8:32 PM, Sergio Fernández  wrote:
> Hi Qihong Lin,
>
> it's the mid-point of the GSoC programme, so it's a good time to assess the
> state of the project. It looks close to the plan and I'd like you to
> (briefly) write-up how the project is going. Check you are getting what you
> want out of the project as well. It is not just code production. Is the rest
> of the plan looking right still?
>
> Looking on at the repository forked at github:
>
>   https://github.com/confidencesun/marmotta/tree/MARMOTTA-444
>
> besides the few comments I did on your commits, there are a few things I'd
> like to discuss:
>
> * Working plan: concrete details about how your work is actually following
> (or not) the proposed working plan.
>
> * Implementation feedback: which in the end may revert to the overall
> quality of the project. For instance, looking to the current status of your
> implementation http://s.apache.org/7mn I could expect that you should be
> able to propose the usage of an abstract base implementation with some
> commons things.
>
> * Method documentation: document how you translate the Sesame native call to
> SPARQL queries will help to maintain the alternative implementation
>
> * User documentation: how to launch Marmotta using your implementation,
> example requests, etc.
>
> * More testing: I know you are moving on a very unknown area, but the more
> tests you write the best for discovering issues (specially lateral effect of
> related code). The official LDP Test Suite would be a helpful resource.
>
> * Evaluation: for example, regarding performance: on the typical scenarios,
> do you have some figure in the deviation in comparison with the main
> implementation?
>
> And I think that's all...
>
> Remember that you can use the github wiki to write down whatever stuff you
> need. Documentation is always good.
>
> But so far my overall impression for this checkpoint is that you are in the
> right path.
>
> Thanks.
>
> 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]

Hi Sergio,

The wiki is very helpful. Thanks!
I'll code following the restrictions. I think the best way to make it,
is to study LdpServiceImpl and provide the corresponding identical
methods for LdpServiceSPARQLImpl, because LdpServiceImpl is supposed
to be strictly stick to the restrictions, isn't it?

I just made 2 commits [1] of the methods of addResource() and
deleteResource(), with the unit tests [2]. As is promised in the
project plan, you can assess both the reading and writing capabilities
of LDP-RS in the mid-term evaluation.

Until the mid-term evaluation, I think things are going well at my
side. I'll complete the rest of the implementations of the methods. I
appreciate your help very much.

Cheers,
Qihong Lin

[1] https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
[2] 
https://github.com/confidencesun/marmotta/blob/926ae5de17d8c414184c0051f688101adf17003e/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java

On Wed, Jun 11, 2014 at 6:50 AM, Sergio Fernández  wrote:
> Dear Qihong Lin,
>
> apologize for the late reply.
>
>
> On 10/06/14 13:38, Qihong Lin wrote:
>>
>> 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.
>
>
> Great, so the issue was actually in your IDE. Please, verify it does not
> appear on a regular build environment (raw maven).
>
>
>> Could you please just help me with the problem 2)? Thanks a lot!
>
>
> Remember that the scope of your project is restricted to the internals of
> Marmotta. All related with HTTP (headers and so on) are handled by the web
> service, where any of the two service implementations can be plug-in.
>
> For the second part of your question, that's an internal decision of
> Marmotta. The storage layer is out of the scope of the LDP spec. More
> precisely, LDP Marmotta storage is implemented by:
>
> * Using <http://www.w3.org/ns/ldp#> as "management" context, where store
> some management data
> * Internally every LDP-R will be stored in its own context
>
> Further details about our implementation restrictions are available from the
> wiki:
>
> http://wiki.apache.org/marmotta/LDPImplementationReport#Implementation_Restrictions
>
> Thanks for binging here that questions. Finding out those details means that
> you are in the right path for developing your 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  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.ThreadPoolE

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:1

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  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  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  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  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,

Your feedback is very valuable. Thank you! I've modified the proposal
according to your suggestions. Here's the short description inline. Any
other suggestions are very welcome.

On Tue, Mar 11, 2014 at 4:22 PM, Sergio Fernández  wrote:

> Hi Qihong Lin,
>
>
> On 11/03/14 04:38, Qihong Lin wrote:
>
>> 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!
>>
>
> Great!
>
> Taking a quite look to your proposal, there are some points you could
> improve:
>
> * References 5 and 6 could be mentioned together as SPARQL 1.1. It is not
> expected to work with SPARQL 1.0, that's something you could stand out.
>

The references of 5 and 6 have been merged to SPARQL 1.1. Also, I change
the project title to highlight SPARQL 1.1. Hope it helps.


>
> * Performance Improvement: that's not true at all, because all pending
> operations are performed at commit time. And I don't expect performance
> would be better in this alternative implementation, we're aware of it.


> * Instead you could add something about portability, since SPARQL is the
> official recommendation for accessing RDF stores (Sesame is just the
> de-facto standard for Java).
>

Yes, I'm just aware of that. This performance improvement part has been
removed from the proposal, replaced by the portability significance. Thanks
for pointing it out.


>
> * LdpService definition is still evolving. So I'd not refer the delivery
> of concrete methods in the work plan, but functionalities (container
> creation, resource addition, resource deletion, etc) instead.
>
> * Although I understand that reading operations could be easier for
> starting, in the end data creation needs to be in place before reading. So
> FMPOV you would have two options: a) group by target (resource, container,
> etc.) instead of operation type (exist, read, write, etc.) b) keep it as it
> is, and start with a service skeleton where all methods call the default
> implementation until you provide your actual implementation of each. I'd
> prefer the first, but the second is completely valid and probably the most
> convenient one for you.
>
> * But for the mid-term evaluation I'd like to have some writing
> capabilities already in place, not only reading ones.
>

I agree with you. The project plan is now grouped by the targets (i.e.
resource, container, etc) and their functionalities. According to the new
plan, you can assess both the reading and writing capabilities of resource
in the mid-term evaluation.


>
> * For storing binary resources, or more precisely "LDP Non-RDF Source",
> you could use the same service the default implementation uses, SPARQL is
> not capable of that.
>
> * I like that you assert that each concrete milestone would come with
> tests.
>
> So far, the proposal looks good for me. Thanks for your effort.
>
>
> 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
>


Cheers,
Qihong Lin

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  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]

Dear Sergio,

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?

Best,
Qihong Lin




On Tue, Mar 4, 2014 at 3:40 PM, Sergio Fernández  wrote:

> Hi,
>
>
> On 04/03/14 05:03, Qihong Lin wrote:
>
>
>  I'll focus on implementing the LdpSrvice interface using SPARQL.
>> The implementation can be developed incrementally during the GSoC 2014
>> summer, if anything would be changed for LdpService. I can also promise to
>> maintain the implementation after the GSoC program. As a student, it's
>> great to get involved into an open source community with long time
>> contributions. I believe I can learn a lot from the project experience.
>>
>
> Your contributions would be welcomed. And don't be self-conscious because
> your inexperience. That's normal, it happened to everybody at some point,
> it's a natural learning process. And GSoC is an excellent program for that.
>
>
>  According to your replies, the testing work contains 2 parts: 1) unit
>> tests
>> (junit) of the SPARQL implementation itself; 2) RESTful service tests
>> (rest-assured). It seems the later one is service oriented, not for the
>> concrete implementations. Shall we test the RESTful services for different
>> LdpService implementations (i.e. different test cases/suits
>> for different implementations)?
>>
>
> Besides the unit tests, the REST test should behavior exactly the same
> when plugin your implementation instead of the default one. In principle
> we're going to provide a sufficient test suite (this is related to
> MARMOTTA-438 by the way), but we could also expect contributions there for
> improving the coverage of testing.
>
>
>  I'm clear about the project scopes now: the SPARQL implementation and the
>> tests. The approaches are lucid in my mind as well. Anything else to be
>> considered/discussed for the project scopes/approaches/etc? If not, I'd
>> like to prepare a project proposal draft.
>>
>
> Sure, I think you have enough information to prepare your proposal.
>
>
> 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]

Dear Nandana and Sergio,

I'm grateful to your explanations.

I'll focus on implementing the LdpSrvice interface using SPARQL.
The implementation can be developed incrementally during the GSoC 2014
summer, if anything would be changed for LdpService. I can also promise to
maintain the implementation after the GSoC program. As a student, it's
great to get involved into an open source community with long time
contributions. I believe I can learn a lot from the project experience.

According to your replies, the testing work contains 2 parts: 1) unit tests
(junit) of the SPARQL implementation itself; 2) RESTful service tests
(rest-assured). It seems the later one is service oriented, not for the
concrete implementations. Shall we test the RESTful services for different
LdpService implementations (i.e. different test cases/suits
for different implementations)?

I'm clear about the project scopes now: the SPARQL implementation and the
tests. The approaches are lucid in my mind as well. Anything else to be
considered/discussed for the project scopes/approaches/etc? If not, I'd
like to prepare a project proposal draft.

Best,
Qihong Lin




On Sun, Mar 2, 2014 at 7:18 PM, Sergio Fernández  wrote:

> Hi,
>
>
> On 01/03/14 10:38, Qihong Lin wrote:
>
>> 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?
>>
>
> Nandana already did a great summary of the following steps of LDP at W3C.
> I expect the timing would fit quite well with GSoC's timeline, and by the
> end of April everything should be stable enough.
>
> But I'd say for your project the uncertainty is even smaller: MARMOTTA-440
> is defining the stubs for the rest web services, which pushes requirements
> to fully define the LdpService interface. Therefore your project would
> target a concrete implementation of that interface. You should not care
> about other details around; although, of course, any feedback would be
> always welcomed to improve the whole stack.
>
>
>  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?
>>
>
> Complete right: SPARQL 1.1 implementation of those methods. For the moment
> are few, but it'll still evolving and the list will grow for sure.
>
>
>  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]?
>>
>
> Exactly that. It provides a very nice DSL for REST testing. See for
> instance this test:
>
> https://git-wip-us.apache.org/repos/asf?p=marmotta.git;a=
> blob;f=platform/marmotta-ldp/src/test/java/org/apache/
> marmotta/platform/ldp/webservices/LdpWebServiceTest.java;h=
> 4883e8bee28a16978ec82ac88dc06caf5c50bd1d;hb=refs/heads/ldp#l90
>
> Although not included in the description, testing is very important for
> us. Therefore it is expected you would also help extending that test suite,
> in order to improve the validation of your implementation.
>
> Thanks for your interest. Please, let us know if you may need anything
> else for the proposal preparation.
>
>
> 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  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