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 <[email protected]> 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<Triple> 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 <[email protected]> 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<Quad> 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 > >
