Sports Team and Player Identity Candidate Matcher

Reconcile team and player names from different sports datasets with Wikidata candidate IDs, labels and structured evidence. The Actor keeps ambiguous results visible so you can review main clubs, reserve teams, women's teams and similarly named people or works before merging your records.

This independent tool returns candidates, not verified identities. It does not predict sporting outcomes or infer a complete sports taxonomy from names or descriptions.

Input

{
  "queries": [
    {"sourceId": "team-home", "name": "Bayern Munich", "sportQid": "Q2736"},
    {"sourceId": "player-1", "qid": "Q1426", "name": "Roger Federer", "sportQid": "Q847"}
  ],
  "candidateLimit": 3
}

Supply 1–10 queries. Each needs a unique sourceId from your dataset and a name or exact Wikidata qid. With a QID, the Actor reads that entity directly; an accompanying name is checked against its labels and aliases. Resolving a supplied ID does not prove it is the correct identity for your record.

Without a QID, English search examines the first candidateLimit results: 3 by default, at most 5. The limited search can miss relevant entities. Candidate order follows the source and is not a confidence score. A single candidate is still unverified.

Optional exact claim constraints:

Input	Wikidata evidence
sportQid	Sport, P641; for example Q2736 association football or Q847 tennis
countryQid	Country, P17
nationalityQid	Country of citizenship, P27; distinct from P17
typeQid	Instance of, P31; exact listed class only

The Actor reports whether the requested QID is present in nondeprecated claims, absent from the observed values, or not stated. It does not follow subclass hierarchies or interpret temporal qualifiers. These claims do not prove current membership or eligibility. qualifyingCandidateQids lists candidates with all supplied constraints observed; when no constraints are supplied, it lists all returned candidates. It never automatically merges your IDs.

For example, a search for Bayern Munich can also return a film with an exact name agreement but no sport claim. The report retains it and marks the missing evidence rather than treating a matching title as proof of a football club.

Output and source

Each identity_candidate_report links your sourceId to examined QIDs, candidate labels and aliases, English descriptions when available, revision IDs, exact claim evidence, name agreement and constraint states. Labels and aliases retain their source language: English (en) or multilingual (mul). Name agreement uses NFKC normalization, whitespace normalization and lowercase; it is not an identity confidence estimate.

All real reports include source URLs, retrieval timestamps, SHA-256 hashes of decoded response bytes, and Wikidata/CC0 attribution. No portraits, logos, contact fields, sitelinks or unrelated raw claims are exported. Missing or redirected QIDs are reported without following redirects. An empty examined result does not establish global nonexistence.

Data comes from the public Wikidata Action API, using item search followed by a bounded entity request. Requests are sequential, at least one second apart per run, with a 20-second deadline and 2 MiB decoded body limit each. The Actor uses maxlag=5, an identifying User-Agent and compressed responses. HTTP errors, rate limits and maxlag errors stop collection without automatic retries. Separate concurrent runs have independent request clocks.

Structured data is available under CC0 1.0. Charges are for this Actor's processing and delivery. Report incorrect source facts through the entity's Wikidata page; report Actor defects through its Apify Issues page.

Pricing and partial runs

One delivered query report containing at least one resolved candidate requests one result-found event. This includes ambiguous candidates or candidates that do not meet your optional constraints: the report supplies the examined evidence. Repeated queries and snapshots are billable again. Empty reports, diagnostics and synthetic demos request no result event. A configured start charge may apply; check current Apify pricing and set Max total charge.

The budget guard checks that another paid report fits before querying the source. If it does not, collection stops, including queries that might otherwise have returned an unbilled empty result. A later source failure leaves earlier delivered reports in the Dataset; inspect sourceId and rerun only the unresolved portion if appropriate. A run with no candidates can succeed but does not establish matching quality or global absence.

OUTPUT contains counts, source snapshots and completion flags without duplicating candidate evidence. Dataset billing.resultEventRequested and settlement: "unconfirmed_at_write" describe the intent at write time and are not updated after acknowledgement. Use the run's actual charged-event counters and, when available, OUTPUT.confirmedResultEvents to confirm billing.

Unknown writes or charge acknowledgements are never automatically retried. OUTPUT may be missing after a timeout, termination or uncertain storage write; its absence does not imply no data or charges. Check the Dataset and run counters before repeating a run.

Synthetic demo

{"demo": true}

Demo ignores the known queries and candidateLimit fields, including form defaults. It makes no source requests and requests no result event. The synthetic row uses the same report type but has isDemo: true, status: demo, source: null and no real QID. Exclude demo rows when importing real data. Its summary has outcome: demo and collectionComplete: false because it does not collect a source.