Writing a Bug Report

A good bug report is clear and concise. For ARQ, reduce the problem to a short dataset (20 triples should be enough; Turtle, N3 or N-triples preferred) and a query that illustrates the problem. State what you expected to happen as well as what did happen.

It also a good idea to check the documentation.

• ARQ FAQ
• ARQ Documentation

Parse Errors

The SPARQL parser outputs a line and column number - it is usually correct in identifying the first point of a syntax error.

Execution failure

If you are reporting a failure that produces a stack trace, please include the message, exception and the stack trace. Only if it is very long, should you truncate the trace but please include the whole trace to the point where it indicates it is entering ARQ (a package name starting com.hp.hpl.java.query) and one level which is your code.

Unexpected results

If you are getting unexpected results, show the results you expect as well as what you actually get.

There is a testing format used by the Data Access Working Group and that is used for the scripted tests in the distribution.

Reports

The report should also include details of the execution environment:

• Environment:
  • ARQ version
  • Java version
  • Operating system
  • What's the CLASSPATH?
• How are you running the query?
  • Are you running in an application server? Which one?
  • Have you used the command line tools?
• Data:
  • Does your data parse as RDF?
  • Are you querying an inference model
• Query:
  • Have you printed out the query exactly as it is (especially if the string has been assembled in by java code)? It is a good idea to print the query out after building it programmatically.
  • Have you passed the query through the SPARQL syntax checker?
    java -cp ... arq.qparse 'your query'

ARQ Documentation Page