Hi All,
Below I list my report to mid-term evaluation.
Miguel
SPARQL commands in Jena rules - Mid-term evaluation
1. Introduction
Define SPARQL commands in Jena rules is a project proposed in Apache’s
JIRA, in project Apache Jena, and it goal is to allow the definition of
SPARQL commands in Jena rules, bringing a more powerful way to represent
knowledge and increase the expressiveness in Jena. This project was
approved to be developed under Google Summer of Code 2014 initiative. In
this document, will be reported the state of the project to the
middle-term evaluation. At this time, it is already possible to define a
SPARQL command in a rule. When a SPARQL command is introduced in a rule,
the system parse both the rule and the SPARQL command. A SPARQL command is
declared as the clauses in a rule, between parentheses, and the SPARQL
command must be enclosed between the tokens \\\\sparql...\\\sparql. An
example of how we can define a SPARQL command in a rule can be:
(?r rdf:type ex:Square) <-
(\\\\sparql select ?r
where { ?r ex:width ?width . ?
r ex:height ?height .
FILTER(?width = ?height ) .
}\\\\sparql).
In a rule, a SPARQL command only can appear in the body terms. Any
definition of a SPARQL command in the head terms of a rule, will be
rejected by the parser, returning an error. Regarding to the initial
workplan, the planned tasks were fulfilled. However, some good practices in
project development as the documentation and the tests were not followed
as desired. In Step 3, "Study the code of the Jena, namely, the
relevant pieces of code to the project", was only performed to the
parsing of the rules and of the SPARQL commands. The study of how a rule
is executed was already started but it was not finished yet. In the initial
workplan, the coding was only expected to start after the mid-term
evaluation, in task 6. Part of this task was already done, related with
the parsing of the rules with SPARQL commands,as described above.
2. Workplan
In this section, is presented a rescheduling of the tasks resulted from
the evaluation of the project. We will start with the implementation of
the good practises in project development. The work done must be
documented and the tests should be improved. After that, we will continue
with the study of the relevant libraries and pieces of code related with a
rule execution. The next task, coding the execution of a SPARQL command in
a rule, will be done almost in parallel with the previous task and we will
have the follow approach: – we will start with the implementation of a
rule where the body terms is only a SPARQL command. – next, we will
implement the execution of a rule that combines SPARQL commands and rules
clauses in the body terms. The project ends with testing and documentation
of the project.
Chronogram of the project
Begin End Task
23-06-14 27-06-14 Implement the good practises in project
development:
document the
implementation and improve the tests
30-06-14 01-08-14 Study the code of the Jena, namely, the relevant
libraries and
relevant piece of code to execute a rule
07-07-14 29-08-14 Coding. Implement the code to fulfil the goals
of the
project
11-08-14 29-08-14 Test and documentation the project
On 23/06/14 21:26, "Andy Seaborne" <a...@apache.org> wrote:
>Hi Miguel,
>
>We're approaching the mid-term of the Google Summer of Code project.
>It's a good time to assess the state against the plan and to replan the
>remainder of the time. Could you please briefly write-up how you see
>the project going and see if you think any replanning is needed. Also,
>make sure you are getting what you want out of the project.
>
>Looking at the gthub repository, there are a few things I have comments
>on.
>
>1/ Documentation. There will need to be documentation.
>
>2/ Tests
>
>There will need to be syntax test and evaluation tests, positive and
>negative in both cases. Having different classes for each kind helps
>organise them. SparqlInRulesTest.java seems to be heading for an all
>purpose single test class. My experience is that does not help as the
>testing grows. It is better to split tests up and not group them all
>into one test method.
>
>(aside:
>@RunWith(Parameterized.class), my experience is that this adds very
>little in the sort of situation you are in and can produce harder to
>understand test failure reports.
>)
>
>One test case per @Test method so that a test is testing one thing. It
>makes tracking down test failures a lot easier. Organise the tests by
>starting with simple tests and then have complicated ones. When tests
>fail, it can be clearer as to what failing - if some of all of the
>simple tests are parsing, then it points to features only in the complex
>tests and also the other way round. If the simple tests fail, its more
>likely a fundamental issue, not in a feature specific piece of code.
>
>Example:
>
>parseRuleString(String) is a method to call the rules parser.
>
>The test can be written succinctly with ....
>
>@Test public void sparqlInRule_01()
>{ parseRuleString("[rule1: (\\\\\\sparql .....") ; }
>
>parseRuleString is then something like:
>
>private static void parseRuleString(String ruleString) {
> // Exception will neatly fail the test in JUnit.
> List<Rule> rules = Rule.parseRules(ruleString);
> Assert.assertTrue(!rules.isEmpty()) ;
> ... any other checks ...
>}
>
>Note: it does not catch rule parse exceptions. It lets them propagate up.
>
>For negative syntax tests where you expect the test to fail write
>something like:
>
>@Test(expected=Rule.SparqlRuleParserException.class)
>public void sparqlInRule_NN() { parseRuleString("...") ; }
>
>then JUnit in your IDE or from Maven will produce more useful reports.
>
>
>Other:
>
>I see
>
>/*
>* To change this license header, choose License Headers in Project
>Properties.
>* To change this template file, choose Tools | Templates
>* and open the template in the editor.
>*/
>
>This can be removed!!
>
> Andy
