Re: Fwd: Proposal submitted [JENA-491]
Hello, Please check my reply below: On Thu, Apr 9, 2015 at 12:07 PM, Ying Jiang jpz6311...@gmail.com wrote: Hi Andy, Now, we are at proposal ranking phase 1: indicate willingness to mentor, with the deadline of April 12 00:00 UTC. I've already registered as a Possible mentor for Qihong's proposal. Not sure what the next step is. Maybe, ranking all the proposals with scores. I'm waiting for the notices from the mentors@. Hi, Qihong, I think we should take Andy's advice to start discussion on dev@. The proposal has been submitted, and you can not change it. But we can put some posts below there to improve the proposal evaluation. So, I suggest: 1) Andy has made some comments about the project details on dev@ and JIRA. You can summarize them and enrich your proposal in google-melange. If you have any questions, just ask ASAP. I've modified the project proposal: https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit 2) The project schedule can be adjusted, because the first half is larger so it may not split at the mid-term evaluation. 3) The javacc grammar changes should be done first. Have you learned the document of how to use javacc? Have you tried the scripts in cygwin? Yes, cygwin works for me. However I need some time to study the javacc grammar. 4) You can also set up the project documentation in Github or Jena-site. It's better to write the document of design now, like Andy says. You should know that Apache strives for a 100% success rate of GSoC project. It makes good chance to get accepted if we can get things go on ASAP. I'd like to help you with pleasure. Good luck! Best, Ying Jiang On Wed, Apr 8, 2015 at 9:18 PM, Andy Seaborne a...@apache.org wrote: Hi Ying, What is the next process step for GSoC this year? As mentor, you probably want to see this project as starting now. As you know, I don't have time to mentor this year and so can't really guarantee technical invovement at short notice. The proposal will updating for the comments; it also needs to be made consistent. This is better now as part of the submission process, not in the bonding stage. It'll improve the proposal evaluation. e.g,. the javacc grammar changes should be done first. Not much point hacking the generated java parser (it'll be over written by the grammar compiler). e.g. Documentation should arrive with a deliverable, not later (writing the document, which isn't going to be very large, helps check the design). Ying - do you want to work with Qihong to do that? As discussion on dev@? The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the first half is larger so it may not split at the mid-term evaluation. What will be important for this project is regular email traffic to dev@. It's all about making a smooth path for change. This isn't a new module, this is making changes to an area users depend on already. Several people here will want to know what's happening, hopefully comment; we should break the deliverables up to get them in piece by piece, not wait until the end. Using github and generating pull requests throughout the project will work best. There needs to be a fallback in case github is not accessible after our experiences of last year. Qihong - do you have any questions on the process? Andy On 07/04/15 15:00, Ying Jiang wrote: Hi Andy, Thanks for answering Qihong's questions! JENA-491 is not original from my idea. So, I'm very grateful if you can help the student to clarify the project goals and the scopes. Then, as the mentor, I can push the project going on when it starts, with technical assistance regarding Jena. For the first question, is it OK to expose Quad to end user in querying? I mean, we have 2 layers of Jena API: the higher one of Model/Statement/Resource, and the underlying Graph/Triple/Quad/Node. It makes sense to me if we encourage the end users using the former as much as possible. Currently, in the API, we already have: IteratorTriple QueryExecution.execConstructTriples(). I have the same doubt with it. What's your opinion? Best, Ying Jiang On Sun, Apr 5, 2015 at 2:04 AM, Andy Seaborne a...@apache.org wrote: On 03/04/15 03:47, Qihong Lin wrote: Hello Andy, It's submitted in time. Good. Ying - what is the next process step? I saw your notes, thanks. Here're some further questions. 1) API of QueryExecution Does the API look like: - IteratorQuad QueryExecution.execConstrucQuads() - Dataset QueryExecution.execConstructDataset() Both. (One builds on the other anyway.) It should mirror how execConstruct/execConstructTriples are done unless there is a very good reason not to. 2) master.jj How does master.jj generate arq.jj? What tool? You mentioned is processed with cpp. What's cpp? cpp is the C preprocessor (yes!!) It rewrites one text file to another text file. ARQ does not cpp macros, it is just
Re: Fwd: Proposal submitted [JENA-491]
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 confidence@gmail.com 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 jpz6311...@gmail.com wrote: Hi Andy, Now, we are at proposal ranking phase 1: indicate willingness to mentor, with the deadline of April 12 00:00 UTC. I've already registered as a Possible mentor for Qihong's proposal. Not sure what the next step is. Maybe, ranking all the proposals with scores. I'm waiting for the notices from the mentors@. Hi, Qihong, I think we should take Andy's advice to start discussion on dev@. The proposal has been submitted, and you can not change it. But we can put some posts below there to improve the proposal evaluation. So, I suggest: 1) Andy has made some comments about the project details on dev@ and JIRA. You can summarize them and enrich your proposal in google-melange. If you have any questions, just ask ASAP. I've modified the project proposal: https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit 2) The project schedule can be adjusted, because the first half is larger so it may not split at the mid-term evaluation. 3) The javacc grammar changes should be done first. Have you learned the document of how to use javacc? Have you tried the scripts in cygwin? Yes, cygwin works for me. However I need some time to study the javacc grammar. 4) You can also set up the project documentation in Github or Jena-site. It's better to write the document of design now, like Andy says. You should know that Apache strives for a 100% success rate of GSoC project. It makes good chance to get accepted if we can get things go on ASAP. I'd like to help you with pleasure. Good luck! Best, Ying Jiang On Wed, Apr 8, 2015 at 9:18 PM, Andy Seaborne a...@apache.org wrote: Hi Ying, What is the next process step for GSoC this year? As mentor, you probably want to see this project as starting now. As you know, I don't have time to mentor this year and so can't really guarantee technical invovement at short notice. The proposal will updating for the comments; it also needs to be made consistent. This is better now as part of the submission process, not in the bonding stage. It'll improve the proposal evaluation. e.g,. the javacc grammar changes should be done first. Not much point hacking the generated java parser (it'll be over written by the grammar compiler). e.g. Documentation should arrive with a deliverable, not later (writing the document, which isn't going to be very large, helps check the design). Ying - do you want to work with Qihong to do that? As discussion on dev@? The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the first half is larger so it may not split at the mid-term evaluation. What will be important for this project is regular email traffic to dev@. It's all about making a smooth path for change. This isn't a new module, this is making changes to an area users depend on already. Several people here will want to know what's happening, hopefully comment; we should break the deliverables up to get them in piece by piece, not wait until the end. Using github and generating pull requests throughout the project will work best. There needs to be a fallback in case github is not accessible after our experiences of last year. Qihong - do you have any questions on the process? Andy On 07/04/15 15:00, Ying Jiang wrote: Hi Andy, Thanks for answering Qihong's questions! JENA-491 is not original from my idea. So, I'm very grateful if you can help the student to clarify the project goals and the scopes. Then, as the mentor, I can push the project going on when it starts, with technical assistance regarding Jena. For the first question, is it OK to expose Quad to end user in querying? I mean, we have 2 layers of Jena API: the higher one of Model/Statement/Resource, and the underlying Graph/Triple/Quad/Node. It makes sense to me if we encourage the end users using the former as much as possible. Currently, in the API, we already have: IteratorTriple QueryExecution.execConstructTriples(). I have the same doubt with it. What's your opinion? Best, Ying Jiang On Sun, Apr 5, 2015 at 2:04 AM, Andy Seaborne
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 confidence@gmail.com 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 jpz6311...@gmail.com wrote: Hi Andy, Now, we are at proposal ranking phase 1: indicate willingness to mentor, with the deadline of April 12 00:00 UTC. I've already registered as a Possible mentor for Qihong's proposal. Not sure what the next step is. Maybe, ranking all the proposals with scores. I'm waiting for the notices from the mentors@. Hi, Qihong, I think we should take Andy's advice to start discussion on dev@. The proposal has been submitted, and you can not change it. But we can put some posts below there to improve the proposal evaluation. So, I suggest: 1) Andy has made some comments about the project details on dev@ and JIRA. You can summarize them and enrich your proposal in google-melange. If you have any questions, just ask ASAP. I've modified the project proposal: https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit 2) The project schedule can be adjusted, because the first half is larger so it may not split at the mid-term evaluation. 3) The javacc grammar changes should be done first. Have you learned the document of how to use javacc? Have you tried the scripts in cygwin? Yes, cygwin works for me. However I need some time to study the javacc grammar. 4) You can also set up the project documentation in Github or Jena-site. It's better to write the document of design now, like Andy says. You should know that Apache strives for a 100% success rate of GSoC project. It makes good chance to get accepted if we can get things go on ASAP. I'd like to help you with pleasure. Good luck! Best, Ying Jiang On Wed, Apr 8, 2015 at 9:18 PM, Andy Seaborne a...@apache.org wrote: Hi Ying, What is the next process step for GSoC this year? As mentor, you probably want to see this project as starting now. As you know, I don't have time to mentor this year and so can't really guarantee technical invovement at short notice. The proposal will updating for the comments; it also needs to be made consistent. This is better now as part of the submission process, not in the bonding stage. It'll improve the proposal evaluation. e.g,. the javacc grammar changes should be done first. Not much point hacking the generated java parser (it'll be over written by the grammar compiler). e.g. Documentation should arrive with a deliverable, not later (writing the document, which isn't going to be very large, helps check the design). Ying - do you want to work with Qihong to do that? As discussion on dev@? The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the first half is larger so it may not split at the mid-term evaluation. What will be important for this project is regular email traffic to dev@. It's all about making a smooth path for change. This isn't a new module, this is making changes to an area users depend on already. Several people here will want to know what's happening, hopefully comment; we should break the deliverables up to get them in piece by piece, not wait until the end. Using github and generating pull requests throughout the project will work best. There needs to be a fallback in case github is not accessible after our experiences of last year. Qihong - do you have any questions on the process? Andy On 07/04/15 15:00, Ying Jiang wrote: Hi Andy, Thanks for answering Qihong's questions! JENA-491 is not original from my idea. So, I'm very grateful if you can help the student to clarify the project goals and the scopes. Then, as the mentor, I can push the project going on when it starts, with technical assistance regarding Jena. For the first question, is it OK to expose Quad to end user in querying? I mean, we have 2 layers of Jena API: the higher one of Model/Statement/Resource, and the underlying
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 a...@apache.org 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 confidence@gmail.com 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 jpz6311...@gmail.com wrote: Hi Andy, Now, we are at proposal ranking phase 1: indicate willingness to mentor, with the deadline of April 12 00:00 UTC. I've already registered as a Possible mentor for Qihong's proposal. Not sure what the next step is. Maybe, ranking all the proposals with scores. I'm waiting for the notices from the mentors@. Hi, Qihong, I think we should take Andy's advice to start discussion on dev@. The proposal has been submitted, and you can not change it. But we can put some posts below there to improve the proposal evaluation. So, I suggest: 1) Andy has made some comments about the project details on dev@ and JIRA. You can summarize them and enrich your proposal in google-melange. If you have any questions, just ask ASAP. I've modified the project proposal: https://docs.google.com/document/d/1KiDlfxMq5ZsU7vj7ZDm10yC96OZgdltwmZAZl56sTw0/edit 2) The project schedule can be adjusted, because the first half is larger so it may not split at the mid-term evaluation. 3) The javacc grammar changes should be done first. Have you learned the document of how to use javacc? Have you tried the scripts in cygwin? Yes, cygwin works for me. However I need some time to study the javacc grammar. 4) You can also set up the project documentation in Github or Jena-site. It's better to write the document of design now, like Andy says. You should know that Apache strives for a 100% success rate of GSoC project. It makes good chance to get accepted if we can get things go on ASAP. I'd like to help you with pleasure. Good luck! Best, Ying Jiang On Wed, Apr 8, 2015 at 9:18 PM, Andy Seaborne a...@apache.org wrote: Hi Ying, What is the next process step for GSoC this year? As mentor, you probably want to see this project as starting now. As you know, I don't have time to mentor this year and so can't really guarantee technical invovement at short notice. The proposal will updating for the comments; it also needs to be made consistent. This is better now as part of the submission process, not in the bonding stage. It'll improve the proposal evaluation. e.g,. the javacc grammar changes should be done first. Not much point hacking the generated java parser (it'll be over written by the grammar compiler). e.g. Documentation should arrive with a deliverable, not later (writing the document, which isn't going to be very large, helps check the design). Ying - do you want to work with Qihong to do that? As discussion on dev@? The first half is ARQ changes, the second is Fuseki changes (Fuseki2) - the first half is larger so it may not split at the mid-term evaluation. What will be important for this project is regular email traffic to dev@. It's all about making a smooth path for change. This isn't a new module, this is making changes to an area users depend on already. Several people here will want to know what's happening, hopefully comment; we should break the deliverables up to get them in piece by piece, not wait until the end. Using github and generating pull requests throughout the project will work best. There needs to be a fallback in case github is not accessible after our experiences of
[GitHub] jena pull request: jena-text multilingual indexing
Github user osma commented on the pull request: https://github.com/apache/jena/pull/51#issuecomment-92086474 Hi Alexis! For the moment, it's the responsability of the client code to commit or rollback the index (finishIndexing() or abortIndexing() methods) in phase with the associated dataset transaction. I think that synchro should be manage directly from jena (jena-arq?) Yes, that sounds sensible. For example I use jena-text mainly via Fuseki, so there is no opportunity for me to tell Fuseki to call any jena-text methods. However, I realize that we have here two distinct issues, the multilingual-index and the dataset/index transactions synchronization. Do you think it should be a better way to close this issue and re post 2 distinct pull requests from 2 related branches ? Indeed it seems that this pull request addresses two separate issues. If you can easily split that into two separate pull requests, it would help merging them. It's easier to address new features one at a time. Also rebasing your code on the current upstream jena-text would of course help. A pull request that doesn't apply to the current code is not very easy to merge... -Osma --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
