Appearance
When a QuickStatements batch fails, the cause is almost always one of three things: tab delimiters that got mangled, malformed date or coordinate values, or an account that is not yet autoconfirmed. Read the batch log first — it lists each row's status — then fix the offending pattern in your source data and re-run only the failed rows. Do not blindly re-submit the whole batch; that risks duplicating the rows that already succeeded.
Why is QuickStatements rejecting my whole file?
The number-one culprit is delimiters. QuickStatements V1 syntax is tab-separated, and many editors convert tabs to spaces on paste. Verify with a tool that reveals whitespace, or regenerate the file directly from a spreadsheet export. A correct line looks like:
text
Q42 P31 Q5 S854 "https://example.org/source"If you used the CSV (V1 command) mode instead, the first row must be a header of property codes and the separator is a comma — mixing the two formats silently breaks everything.
How do I read the batch log to find the failing row?
Every batch gets a page at quickstatements.toolforge.org showing rows as DONE, ERROR or SKIPPED. Click an error to see the API response. Map common messages to causes:
| Message fragment | Likely cause | Fix |
|---|---|---|
invalid-snak | bad value format (date, quantity, coordinate) | correct the literal syntax |
no-such-entity | typo in a Q/P id | check the identifier |
permissiondenied | not autoconfirmed / blocked | reach 50 edits + 4 days |
failed-save: modification-failed | constraint violation | review property constraints |
| nothing added, status DONE | duplicate statement | expected; safe to ignore |
Why are my dates and coordinates rejected?
Literals are strict. Dates need the full ISO string plus a precision flag after a slash:
text
+1605-00-00T00:00:00Z/9 # year precision
+1605-03-00T00:00:00Z/10 # month precision
+1605-03-14T00:00:00Z/11 # day precisionCoordinates use the @lat/lon form: @53.84/-0.43. Quantities with units need the unit's Q-id: 42U11573 means 42 metres. A bare 1605 or 53.84, -0.43 will always error.
How do I add references and qualifiers in a batch?
Append them on the same line after the main statement. Use uppercase S properties for references (the source layer) and lowercase q... actually P codes in the qualifier slot:
text
Q42 P571 +1605-00-00T00:00:00Z/9 P1480 Q18122778 S854 "https://example.org/ms"Here P1480 Q18122778 is the qualifier "attributed to" and S854 is the reference URL. Forgetting the reference is not an error, but it leaves unsourced claims that reviewers will flag.
My batch ran but nothing changed — what happened?
Two innocent explanations dominate. First, the statements already existed; QuickStatements is idempotent and skips duplicates, so a re-run of a finished batch legitimately adds nothing. Second, your account lost autoconfirmed privileges or hit a rate limit mid-run. Open the log: a wall of SKIPPED rows means duplicates; a wall of permission errors means an account problem.
How do I recover from a batch that imported bad data?
Act fast. While a batch is running you can stop it from its page. To reverse completed edits, the batch owner or an administrator can mass-revert by batch ID, which is far cleaner than manually undoing edits. Best practice: run a tiny 5-row pilot batch first, verify the result with a SPARQL query, and only then release the full job. A ten-minute pilot saves hours of reverts.
What pre-flight checks prevent most failures?
- Confirm tab (or comma for CSV mode) delimiters survived the export.
- Validate one row by hand in the QuickStatements preview before submitting thousands.
- Check every Q/P id resolves to a real entity.
- Format dates, coordinates and quantities to spec.
- Run a 5-row pilot, query it back, then scale.
Key Takeaways
- Read the batch log first; it pinpoints which rows failed and why.
- Tab/comma delimiter corruption causes most "malformed command" errors.
- Dates, coordinates and quantities need exact literal formats with precision/unit suffixes.
- A batch that adds nothing usually hit duplicates or an account-permission limit.
- Stop a running batch or mass-revert by batch ID to recover from bad imports.
- Always run a 5-row pilot and verify with SPARQL before the full job.
Frequently Asked Questions
Why does QuickStatements say my command is malformed?
Almost always a delimiter problem: QuickStatements expects tab separators, not spaces or commas. Copy-pasting from a spreadsheet usually preserves tabs, but text editors can silently convert them.
How do I reference a newly created item in the same batch?
Use the keyword LAST, which points to the most recently created item. After a CREATE line, every following LAST line adds statements to that new item.
Why are my dates rejected?
Dates must use the full ISO format with a precision suffix, for example +1605-00-00T00:00:00Z/9 for year precision. Bare years like 1605 fail.
Can I undo a batch that went wrong?
Yes. Each QuickStatements batch has its own page where you can stop it, and admins or the batch owner can mass-revert edits. Catching it early limits the cleanup.
Why does my batch run but add nothing?
Usually the statements already exist (QuickStatements skips duplicates) or your account is not autoconfirmed. Check the batch log for skipped rows.
How fast can a batch run?
In batch mode roughly 1 edit per second by default; with a bot flag it can go faster. Large imports of tens of thousands of statements take hours, so schedule accordingly.