You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2014/06/23 22:26:07 UTC
GSoC : SPARQL in Rules : mid-term checkpoint
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
Re: GSoC : SPARQL in Rules : mid-term checkpoint
Posted by Miguel Bento Alves <mb...@gmail.com>.
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" <an...@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
Re: GSoC : SPARQL in Rules : mid-term checkpoint
Posted by Andy Seaborne <an...@apache.org>.
Claude,
That takes the case for not writing complex tests and also for having
simple tests then build on them, ideally, one feature at a time. Nicer
when JUnit ran test in a predictable order.
In this case there is a single call to the parser. It simply avoids
needing to have a separate
parseRuleStringNegative("...") ;
Insert DRYness here.
Andy
On 24/06/14 07:16, Claude Warren wrote:
> Just a quick difference of opinion.
>
> I think that
>
> @Test(expected=Rule.SparqlRuleParserException.class)
> public void sparqlInRule_NN() { parseRuleString("...") ; }
>
> is a bad pattern, and that tests where an exception is expected are better
> served with try catch blocks catching the expected exception and perhaps
> validating that the expected exception text is present. In the case noted
> here if there are several places in the code where SparqlRuleParserException
> could be thrown in this test, then the catch would verify that the text of
> the message was as expected to determine that the correct one was thrown.
>
> I got caught out to many times by using the expected property of the
> annotation only to discover, after much hair pulling, that it was not
> throwing the version of the exception I was expecting.
>
> Claude
>
>
> On Mon, Jun 23, 2014 at 9:26 PM, Andy Seaborne <an...@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
>>
>
>
>
Re: GSoC : SPARQL in Rules : mid-term checkpoint
Posted by Claude Warren <cl...@xenei.com>.
Just a quick difference of opinion.
I think that
@Test(expected=Rule.SparqlRuleParserException.class)
public void sparqlInRule_NN() { parseRuleString("...") ; }
is a bad pattern, and that tests where an exception is expected are better
served with try catch blocks catching the expected exception and perhaps
validating that the expected exception text is present. In the case noted
here if there are several places in the code where SparqlRuleParserException
could be thrown in this test, then the catch would verify that the text of
the message was as expected to determine that the correct one was thrown.
I got caught out to many times by using the expected property of the
annotation only to discover, after much hair pulling, that it was not
throwing the version of the exception I was expecting.
Claude
On Mon, Jun 23, 2014 at 9:26 PM, Andy Seaborne <an...@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
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren