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 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
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 Graph
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
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:
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 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
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:
- 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 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:
- IteratorQuad QueryExecution.execConstrucQuads()
- Dataset QueryExecution.execConstructDataset()
2) master.jj
How does master.jj generate arq.jj? What tool? You mentioned is
processed with cpp. What's cpp?
3) query string sytax
I went through TriG syntax.
- For our query string, can it construct a Dataset with multiple
graphs, or just one default/named graph?
- Shall we consider using variables for named graphs? I mean ?g, not :g:
CONSTRUCT {
# Named graph
GRAPH ?g { ?s :p ?o }
} WHERE
regards,
Qihong
On Wed, Apr 1, 2015 at 9:59 PM, Andy Seaborne a...@apache.org wrote:
Hi there,
What's the status on this? Was it submitted?
I've put some notes on JENA-491 that related to the proposal about the
proposed syntax and the way to modify the grammar.
One of the important things to make sure happens is that the work is visible
on this list (confidence.sun@ is subscribed so that's a good start) through
out the project. It hard to have code appear at the end and integrate it in
time and I'm working with the assumption that there will be change to the
main codebase as a result of JENA-491 with no need for extension classes.
(I looked at the github prototype
https://github.com/confidencesun/jena/)
For example, Template class becomes quad-aware and the SPARQL 1.1 usage is
triples only because the strict syntax can't set things outside the default
graph of the datasets. Otherwise, the code is quads throughout.
So if this going ahead, we should be building community from now on, through
the bonding period and throughout the project lifetime. That includes
regular status and discussions here. Qihong - After last year with
Marmotta, I'm sure you know how things work at Apache.
Andy
On 25/03/15 13:10, Andy Seaborne wrote:
Hi Ying,
Have you signed up as a mentor yet? This is getting to be urgent.
(instructions forwarded)
On 03/25/15 01:32, Ying Jiang wrote:
Hi,
I can see it's a strong proposal. If possible, I'd be glad to be the
mentor for this project.
Andy, if other project is appropriate for Jena, I'm willing to be a
mentor, or at least a co-mentor, depending on its scopes. Hope it
helps!
The two I know of are this one from Qihong and one mention by Dimuthu [*]
The mentors signup to specific projects - it comes down to what you want
to do.
Andy
[*]
http://mail-archives.apache.org/mod_mbox/jena-dev/201503.mbox/%3CCAHzXhOimMQjHeCzdV%3Dp-jegVC-gxdPiXe%3D9QE_aGO%2BT3hfDknw%40mail.gmail.com%3E
https://issues.apache.org/jira/browse/JENA-624
Best,
Ying Jiang
On Tue, Mar 24, 2015 at 11:50 PM, Andy Seaborne a...@apache.org wrote:
On 03/24/15 13:54, Qihong Lin wrote:
Hi Andy,
I just changed the settings. Is the proposal here [1] now visible
for you?
Dr. Ying Jiang mentioned to be the potential mentor. Is that OK?
Sorry, no. I'm afraid I don't have time to be a mentor this year.
Andy
regards,
Qihong Lin
[1]
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/confidence_sun/5639274879778816
On Tue, Mar 24, 2015 at 6:23 PM, Andy Seaborne a...@apache.org wrote:
Qihong,
We can't read that URL.
You need a mentor for the project and at the moment, Jena has very
people
with time to be a mentor this year which is severely limiting the
capacity
to take on GSoC projects.
Andy
On 24/03/15 01:51, Ying Jiang wrote:
Hi,
I can not open your proposal. Maybe you can mark it public to
everyone?
Although I can give some advice, you'd better also ask for feedback
from other committers in the Jena community. It's vital to make clear
the project details through discussion in the dev mailing list before
GSoC project begins. Guys there are nice and helpful. So, just
subscribe to it and post your ideas for comments. Good luck!
Ying Jiang
-- Forwarded message --
From: Qihong Lin confidence@gmail.com
Date: Tue, Mar 24, 2015 at 12:39 AM
Subject: Proposal submitted
To: Ying Jiang jpz6311...@gmail.com
Hello, Dr. Jiang
I've submitted a project proposal for GSoC 2015. Could you please
help
me improve it? Thanks.
http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/confidence_sun/5639274879778816
regards,
Qihong
Re: Fwd: Proposal submitted [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 a...@apache.org wrote: On 03/24/15 13:54, Qihong Lin wrote: Hi Andy, I just changed the settings. Is the proposal here [1] now visible for you? Dr. Ying Jiang mentioned to be the potential mentor. Is that OK? Sorry, no. I'm afraid I don't have time to be a mentor this year. Andy regards, Qihong Lin [1] http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/confidence_sun/5639274879778816 On Tue, Mar 24, 2015 at 6:23 PM, Andy Seaborne a...@apache.org wrote: Qihong, We can't read that URL. You need a mentor for the project and at the moment, Jena has very people with time to be a mentor this year which is severely limiting the capacity to take on GSoC projects. Andy On 24/03/15 01:51, Ying Jiang wrote: Hi, I can not open your proposal. Maybe you can mark it public to everyone? Although I can give some advice, you'd better also ask for feedback from other committers in the Jena community. It's vital to make clear the project details through discussion in the dev mailing list before GSoC project begins. Guys there are nice and helpful. So, just subscribe to it and post your ideas for comments. Good luck! Ying Jiang -- Forwarded message -- From: Qihong Lin confidence@gmail.com Date: Tue, Mar 24, 2015 at 12:39 AM Subject: Proposal submitted To: Ying Jiang jpz6311...@gmail.com Hello, Dr. Jiang I've submitted a project proposal for GSoC 2015. Could you please help me improve it? Thanks. http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/confidence_sun/5639274879778816 regards, Qihong
