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.
Reports
The report should also include details of the execution environment:
- Environment:
- Joseki version (ARQ version and Jena version if upgraded)
- Java version
- Operating system
- What's the CLASSPATH?
- How are you running the server?
- Are you running in an application server? Which one?
- Are you running the server standalone? Does it work standalone?
- Data:
- Does your data parse as RDF?
- Does the configuration file show any errors?
- Network:
- What protocol are you using? HTTP or SOAP?
See also the ARQ
bug reports page.