Annotate queries with parameter declarations

[rousso]

Summary

Names the values a reader may change in each published query, so the web app can offer them as a form instead of asking people to edit SPARQL. Companion to the 2.4.0 parameter feature in ted-open-data (issue #72).

What's in this PR

• Existing .sparql file(s) edited — 33 of the 36 published queries gain one or more # ?variable: Label comments
• Documentation only (README.md, CONTRIBUTING.md) — the Parameterisation section rewritten for the declaration syntax

Nothing else changes: no query's SPARQL is rewritten except two whose date bounds move into a single FILTER, which is what two adjacent FILTERs already meant.

The syntax

# ?publicationDate: Publication date
FILTER (?publicationDate = "2024-11-04"^^xsd:date)

Only the label is declared. The kind of field and the starting value come from the query itself, so there is no second copy of anything to fall out of step.

Two names on one line are the two ends of a range, the start first:

# ?startDate, ?endDate: Publication date

A single variable bounded from both sides by one && is read as a range too. Anything else — bounds in separate FILTERs, either side of a ||, in opposite arms of a UNION, or under a negation — is offered as ordinary fields with no ordering check, deliberately: the app never refuses to run a query on the strength of a guess.

For new or edited queries

• Every edited file still parses and runs unchanged — the annotations are comments
• sparql: paths untouched
• All 33 edited queries are published in web-library.yaml

Notes for reviewers

Two queries in queries/ are not touched here because they are not published: contracts-per-day.sparql (entry commented out) and procedures-per-day.sparql (no entry). See #12.

Worth a look:

• notice-count-per-form-type, notice-count-per-date-and-notice-type, notice-count-per-date-and-procedure-type, notices-per-period — two annotation lines replaced by one comma declaration
• highest-estimated-procedure-amount, number-of-notices-per-day — the only two files whose SPARQL changes, merging two adjacent FILTERs into one && so the pair reads as one range

[Anoop-Variyan]

Reviewed by checking out the branch locally and testing against the live TED SPARQL endpoint.

Verified the two files with actual SPARQL changes (highest-estimated-procedure-amount.sparql, number-of-notices-per-day.sparql): merging two adjacent FILTERs into one &&-joined FILTER is semantically identical. Ran number-of-notices-per-day.sparql before and after — both return count=6536.
Spot-checked the annotation rules described in CONTRIBUTING.md (range detection via single && or comma-declared pairs, IRI exclusion, lang()-comparison exclusion) across a sample of files — all consistent with the stated rules.
Two non-blocking notes:

7 of the files touched here (joint-procurement-notice-count.sparql, notice-count-per-buyer.sparql, top-buyers-by-notice-count.sparql, top-winners-by-contract-count.sparql, organizations-per-day.sparql, competition-notices.sparql, notices-per-buyer-country.sparql) overlap with the open fix/multilingual-duplication branch (issue #81), which is also mid-review. Both branches insert a line at the same header-comment anchor point, so whichever merges second will hit a small textual conflict — no logic conflict, just a heads-up.
Pre-existing gap, not introduced here: the "Web library categories" list in CONTRIBUTING.md is missing Contracts and Federated queries, both of which are actually used in web-library.yaml. Since this PR already rewrites that file extensively, might be worth adding them while you're in there — not a blocker.