Re: Fwd: Proposal submitted [JENA-491]
On 03/04/15 03:47, Qihong Lin wrote: 3) query string sytax I went through TriG syntax. By the way: in SPARQL Update there is a similar form "INSERT" which takes a TriG+variables template. This is the grammar that you need; the embedded java may need changing or not (I'm not sure but it looks close). See: https://github.com/apache/jena/blob/master/jena-arq/Grammar/master.jj#L679 The execution of INSERT (not INSERT DATA) should provide the general approach: https://github.com/apache/jena/blob/master/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/UpdateEngineWorker.java#L381 and it uses code: https://github.com/apache/jena/blob/master/jena-arq/src/main/java/com/hp/hpl/jena/sparql/modify/TemplateLib.java#L46 Andy
Re: Fwd: Proposal submitted [JENA-491]
On 12/04/15 14:03, Bruno P. Kinoshita wrote: Oh, so I started working with the JavaCC grammar by running Fuseki, and later wrote that main method, but I could have used qparse? I liked the main method because I did not have to re-compile the project, since I could simply update the JavaCC grammar and run the generated parser. Can I get the same result with qparse? If so I will update JENA-632 :) Thanks Andy!Bruno Presumably, it is using Fuskei as an uber jar to have a command setup. To work at the command line, I redid my script recently and it now that puts the target/classes on the front of a classpath of "download/lib/*" because all the dependencies are in that directory. Just updating the grammar, and recompiling (Eclipse, maven) should make the new grammar show up. Another way which works better with Fuseki (large number of dependencies) is to cache the classpath with mvn dependency:build-classpath -Dmdep:out=FILE then CP="$(cat FILE)" java -cp "$CP" ... I'm away at the moment and just about have email - remind next week and I can dig the latest script and put it somewhere. Andy From: Andy Seaborne To: dev@jena.apache.org Sent: Monday, April 13, 2015 12:44 AM Subject: Re: Fwd: Proposal submitted [JENA-491] The command line tools work with the extended ARQ syntax if: 1/ The file name ends ".arq" or 2/ --syntax arq so you can use qparse to test queries. "qparse" also does some internal testing - it parses the query, prints the parsed form (so it does query -> string), reparses and tests that hash code and .equals work. Andy On 12/04/15 11:31, Bruno P. Kinoshita wrote: Hello, Chiming in just to say that if necessary I can help testing the JavaCC part. I was working on JENA-632, which is still being reviewed, but it included changes in ARQ and in the JavaCC grammar. One thing that could be helpful, I think, is extracting the main method created for JENA-632 [1] in the generated parser. It avoids having to re-run Fuseki to quickly test the modifications in the grammar. I will file an issue and extract that part later. All the best,Bruno [1] https://github.com/kinow/jena/blob/7b3b10134f4201314d5f6c6103a595181e82f997/jena-arq/Grammar/arq.jj#L39
Re: Fwd: Proposal submitted [JENA-491]
Oh, so I started working with the JavaCC grammar by running Fuseki, and later wrote that main method, but I could have used qparse? I liked the main method because I did not have to re-compile the project, since I could simply update the JavaCC grammar and run the generated parser. Can I get the same result with qparse? If so I will update JENA-632 :) Thanks Andy!Bruno From: Andy Seaborne To: dev@jena.apache.org Sent: Monday, April 13, 2015 12:44 AM Subject: Re: Fwd: Proposal submitted [JENA-491] The command line tools work with the extended ARQ syntax if: 1/ The file name ends ".arq" or 2/ --syntax arq so you can use qparse to test queries. "qparse" also does some internal testing - it parses the query, prints the parsed form (so it does query -> string), reparses and tests that hash code and .equals work. Andy On 12/04/15 11:31, Bruno P. Kinoshita wrote: > Hello, > Chiming in just to say that if necessary I can help testing the JavaCC part. > I was working on JENA-632, which is still being reviewed, but it included > changes in ARQ and in the JavaCC grammar. > > One thing that could be helpful, I think, is extracting the main method > created for JENA-632 [1] in the generated parser. It avoids having to re-run > Fuseki to quickly test the modifications in the grammar. I will file an issue > and extract that part later. > > All the best,Bruno > [1] > https://github.com/kinow/jena/blob/7b3b10134f4201314d5f6c6103a595181e82f997/jena-arq/Grammar/arq.jj#L39 > > > From: Qihong Lin > To: dev@jena.apache.org > Sent: Sunday, April 12, 2015 9:10 PM > Subject: Re: Fwd: Proposal submitted [JENA-491] > > 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 de
Re: Fwd: Proposal submitted [JENA-491]
The command line tools work with the extended ARQ syntax if: 1/ The file name ends ".arq" or 2/ --syntax arq so you can use qparse to test queries. "qparse" also does some internal testing - it parses the query, prints the parsed form (so it does query -> string), reparses and tests that hash code and .equals work. Andy On 12/04/15 11:31, Bruno P. Kinoshita wrote: Hello, Chiming in just to say that if necessary I can help testing the JavaCC part. I was working on JENA-632, which is still being reviewed, but it included changes in ARQ and in the JavaCC grammar. One thing that could be helpful, I think, is extracting the main method created for JENA-632 [1] in the generated parser. It avoids having to re-run Fuseki to quickly test the modifications in the grammar. I will file an issue and extract that part later. All the best,Bruno [1] https://github.com/kinow/jena/blob/7b3b10134f4201314d5f6c6103a595181e82f997/jena-arq/Grammar/arq.jj#L39 From: Qihong Lin To: dev@jena.apache.org Sent: Sunday, April 12, 2015 9:10 PM Subject: Re: Fwd: Proposal submitted [JENA-491] 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
Re: Fwd: Proposal submitted [JENA-491]
Hello, Chiming in just to say that if necessary I can help testing the JavaCC part. I was working on JENA-632, which is still being reviewed, but it included changes in ARQ and in the JavaCC grammar. One thing that could be helpful, I think, is extracting the main method created for JENA-632 [1] in the generated parser. It avoids having to re-run Fuseki to quickly test the modifications in the grammar. I will file an issue and extract that part later. All the best,Bruno [1] https://github.com/kinow/jena/blob/7b3b10134f4201314d5f6c6103a595181e82f997/jena-arq/Grammar/arq.jj#L39 From: Qihong Lin To: dev@jena.apache.org Sent: Sunday, April 12, 2015 9:10 PM Subject: Re: Fwd: Proposal submitted [JENA-491] 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 >>
Re: Fwd: Proposal submitted [JENA-491]
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:04 AM, Andy Seaborne wrote: On 03/04/15 03:47, Qihong Lin wrote: > > > Hello Andy, > > It's submitted in time. Good. Ying - what is the next process step? > I saw your notes, thanks. Here're some further > questions. > > 1) API of QueryExecution > Does the API look like: > - Iterator QueryExecution.execConstrucQuads() > - Dataset QueryExecution.execConstructDataset() Both. (One builds on the other anyway.) It should mirror how execConstruct/execConstructTriples are done unless there is a very good reason not to
Re: Fwd: Proposal submitted [JENA-491]
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. 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? 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:04 AM, Andy Seaborne wrote: >>> >>> On 03/04/15 03:47, Qihong Lin wrote: Hello Andy, It's submitted in time. >>> >>> >>> >>> Good. >>> >>> Ying - what is the next process step? >>> I saw your notes, thanks. Here're some further questions. 1) API of QueryExecution Does the API look like: - Iterator QueryExecution.execConstrucQuads() - Dataset QueryExecution.execConstructDataset() >>> >>> >>> >>> Both. (One builds on the other anyway.) >>> >>> It should mirror how execConstruct/execConstructTriples are done unless >>> there is a very good reason not to. >>> 2) master.jj How does master.jj generate arq.jj? What tool? You mentioned "is processed with cpp". What's cpp? >>> >>> >>> >>> cpp is the C preprocessor (yes!!) It rewrites one text file to another >>> text >>> file. ARQ does not cpp macros, it is just using defined symbols ARQ and >>> SPARQL_11 to put in different blocks of text. >>> >>> It's also why there are no comments in arq.jj. cpp removes them and >>> blank >>>
Re: Fwd: Proposal submitted [JENA-491]
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:04 AM, Andy Seaborne wrote: On 03/04/15 03:47, Qihong Lin wrote: Hello Andy, It's submitted in time. Good. Ying - what is the next process step? I saw your notes, thanks. Here're some further questions. 1) API of QueryExecution Does the API look like: - Iterator QueryExecution.execConstrucQuads() - Dataset QueryExecution.execConstructDataset() Both. (One builds on the other anyway.) It should mirror how execConstruct/execConstructTriples are done unless there is a very good reason not to. 2) master.jj How does master.jj generate arq.jj? What tool? You mentioned "is processed with cpp". What's cpp? cpp is the C preprocessor (yes!!) It rewrites one text file to another text file. ARQ does not cpp macros, it is just using defined symbols ARQ and SPARQL_11 to put in different blocks of text. It's also why there are no comments in arq.jj. cpp removes them and blank lines (the alternative is lots of blank lines - it's yuk). The script to drive it is jena-arq/Grammar/grammar (it's a bash script - I don't know how well it runs on MS Windows - it used to using cygwin). The script directs the output to the right place in the java source code. If you have trouble running it, edit arq.jj then run javacc. The SyntaxARQ parts that are not SPARQL 1.1, are in sections #ifdef ARQ #endif 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? Multiple. A dataset is one default and zero or more named graphs. CONSTRUCT { GRAPH :g1 { ?s ?p ?o } GRAPH :g2 { ?s ?p ?o } GRAPH ?g { ?s ?p ?o } } ... only in real use the patterns will be bigger. - Shall we consider using variables for named graphs? I mean "?g", not ":g": CONSTRUCT { # Named graph GRAPH ?g { ?s :p ?o } } WHERE Yes. Class Template can be made to work purely on quads. Where it current uses BasicPattern (which is triples), use QuadPattern. That will work for non-extended SPARQL 1.1 as well because "CONSTRUCT { no use of GRAPH }" will give a quad pattern of all quads for the default graph. There is a magic constant for "this quad is for the default graph" - see class Quad. So you don't need tow different sets of machinary - update Template to handle quads and the syntactic restrictions of SPARQL_11 will stop it getting named graph in CONSTRUCT. execConstruct/execConstructTriples then work on the default graph of a dataset. You may find it helpful to look at the TriG parser output. That parser is not Javacc (it's much fa
Re: Fwd: Proposal submitted [JENA-491]
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:04 AM, Andy Seaborne wrote: > On 03/04/15 03:47, Qihong Lin wrote: >> >> Hello Andy, >> >> It's submitted in time. > > > Good. > > Ying - what is the next process step? > >> I saw your notes, thanks. Here're some further >> questions. >> >> 1) API of QueryExecution >> Does the API look like: >> - Iterator QueryExecution.execConstrucQuads() >> - Dataset QueryExecution.execConstructDataset() > > > Both. (One builds on the other anyway.) > > It should mirror how execConstruct/execConstructTriples are done unless > there is a very good reason not to. > >> 2) master.jj >> How does master.jj generate arq.jj? What tool? You mentioned "is >> processed with cpp". What's cpp? > > > cpp is the C preprocessor (yes!!) It rewrites one text file to another text > file. ARQ does not cpp macros, it is just using defined symbols ARQ and > SPARQL_11 to put in different blocks of text. > > It's also why there are no comments in arq.jj. cpp removes them and blank > lines (the alternative is lots of blank lines - it's yuk). > > The script to drive it is jena-arq/Grammar/grammar (it's a bash script - I > don't know how well it runs on MS Windows - it used to using cygwin). The > script directs the output to the right place in the java source code. > > If you have trouble running it, edit arq.jj then run javacc. > > The SyntaxARQ parts that are not SPARQL 1.1, are in sections > > #ifdef ARQ > > #endif > > >> 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? > > > Multiple. > > A dataset is one default and zero or more named graphs. > > CONSTRUCT > { GRAPH :g1 { ?s ?p ?o } > GRAPH :g2 { ?s ?p ?o } > GRAPH ?g { ?s ?p ?o } > } ... > > only in real use the patterns will be bigger. > >> - Shall we consider using variables for named graphs? I mean "?g", not >> ":g": >> CONSTRUCT { >> # Named graph >> GRAPH ?g { ?s :p ?o } >> } WHERE >> > > Yes. > > Class Template can be made to work purely on quads. Where it current uses > BasicPattern (which is triples), use QuadPattern. > > That will work for non-extended SPARQL 1.1 as well because "CONSTRUCT { no > use of GRAPH }" will give a quad pattern of all quads for the default graph. > There is a magic constant for "this quad is for the default graph" - see > class Quad. > > So you don't need tow different sets of machinary - update Template to > handle quads and the syntactic restrictions of SPARQL_11 will stop it > getting named graph in CONSTRUCT. > > execConstruct/execConstructTriples then work on the default graph of a > dataset. > > You may find it helpful to look at the TriG parser output. That parser is > not Javacc (it's much faster). It's informing but you will need to write > the javacc for this project. > >> regards, >> Qihong > > > Andy
Re: Fwd: Proposal submitted [JENA-491]
On 03/04/15 03:47, Qihong Lin wrote: Hello Andy, It's submitted in time. Good. Ying - what is the next process step? I saw your notes, thanks. Here're some further questions. 1) API of QueryExecution Does the API look like: - Iterator QueryExecution.execConstrucQuads() - Dataset QueryExecution.execConstructDataset() Both. (One builds on the other anyway.) It should mirror how execConstruct/execConstructTriples are done unless there is a very good reason not to. 2) master.jj How does master.jj generate arq.jj? What tool? You mentioned "is processed with cpp". What's cpp? cpp is the C preprocessor (yes!!) It rewrites one text file to another text file. ARQ does not cpp macros, it is just using defined symbols ARQ and SPARQL_11 to put in different blocks of text. It's also why there are no comments in arq.jj. cpp removes them and blank lines (the alternative is lots of blank lines - it's yuk). The script to drive it is jena-arq/Grammar/grammar (it's a bash script - I don't know how well it runs on MS Windows - it used to using cygwin). The script directs the output to the right place in the java source code. If you have trouble running it, edit arq.jj then run javacc. The SyntaxARQ parts that are not SPARQL 1.1, are in sections #ifdef ARQ #endif 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? Multiple. A dataset is one default and zero or more named graphs. CONSTRUCT { GRAPH :g1 { ?s ?p ?o } GRAPH :g2 { ?s ?p ?o } GRAPH ?g { ?s ?p ?o } } ... only in real use the patterns will be bigger. - Shall we consider using variables for named graphs? I mean "?g", not ":g": CONSTRUCT { # Named graph GRAPH ?g { ?s :p ?o } } WHERE Yes. Class Template can be made to work purely on quads. Where it current uses BasicPattern (which is triples), use QuadPattern. That will work for non-extended SPARQL 1.1 as well because "CONSTRUCT { no use of GRAPH }" will give a quad pattern of all quads for the default graph. There is a magic constant for "this quad is for the default graph" - see class Quad. So you don't need tow different sets of machinary - update Template to handle quads and the syntactic restrictions of SPARQL_11 will stop it getting named graph in CONSTRUCT. execConstruct/execConstructTriples then work on the default graph of a dataset. You may find it helpful to look at the TriG parser output. That parser is not Javacc (it's much faster). It's informing but you will need to write the javacc for this project. regards, Qihong Andy
Re: Fwd: Proposal submitted [JENA-491]
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 [JENA-491]
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