| OsProject | |
|---|---|
| id | py_ez_wikidata |
| state | active |
| owner | WolfgangFahl |
| title | py_ez_wikidata |
| url | https://github.com/WolfgangFahl/py_ez_wikidata |
| version | 0.5.4 |
| description | Mapping for Wikidata allows creation of wikidata entries from dicts |
| date | 2026-10-09 |
| since | 2024-03-01 |
| until | |
pip install py-ez-wikidata
# alternatively if your pip is not a python3 pip
pip3 install py-ez-wikidata
# local install from source directory of py-ez-wikidata
pip install .
pip install py-ez-wikidata -U
# alternatively if your pip is not a python3 pip
pip3 install py-ez-wikidata -U
✍️🤖 Agent/Guido: Py ez wikidata/Tutorial explains the mapping, the record, the dry run with its checks and RDF output, the author order and the five worked examples.
The ezwd command creates Wikidata items from a simple YAML/JSON record via a named property mapping. It is dry-run by default — add -w to write.
ezwd -s "Robert David"
ezwd -m scholar --list-mappings
ezwd -m scholar --example # the worked example embedded in the mapping, as dry run
Record robert_david.yaml:
label: Robert David
description: knowledge graph researcher
instanceof: Q5
orcid: "0000-0002-3244-5341"
dblp: "173/3493-1"
linkedInId: "robert-david-39b47692"
# dry-run (nothing written)
ezwd -m scholar -r robert_david.yaml
# write to production Wikidata
ezwd -m scholar -r robert_david.yaml -w
This created Q140424194 for Robert David (instance of human, ORCID, DBLP, LinkedIn). Only include an identifier once you have verified it belongs to this exact person — do not bulk-copy IDs from an author record that may aggregate homonyms.
The dry run prints the item that would be written — label, description and one line per statement:
label: Klaus Schröer
description: robotics researcher and automotive manager
P31 instance of: Q5
P106 occupation: Q1650915
P1960 Google Scholar author ID: yP0nMHAAAAAJ
P2038 ResearchGate profile ID: Klaus-Schroeer
The output comes from Wikidata.explain_result, which renders the actually built item — there is no separate preview implementation. With -d the full item JSON is printed instead.
Wikidata.check_result reports problems: a mapped record value whose property got no claim, and every conversion error. The CLI prints them always; with --strict problems set exit code 1, so scripted use can refuse to write a partial item:
ezwd --strict -m scholar -r record.yaml || echo "record has problems"
✍️🤖 Agent/Guido: since 0.5.2 the dry run also shows the qualifiers of each statement, and a record column without mapping is a problem too: "no mapping for column x - value is ignored". Since 0.5.4 --format turtle prints the built item as RDF in the Wikidata model, see Py ez wikidata/Tutorial/Dry run.
ezwd -m scholar -r robert_david.yaml --test # target test.wikidata.org
ezwd -m scholar -r robert_david.yaml --baseurl https://www.wikidata.org
Note: test.wikidata.org uses different property / item IDs than production, so a production-PID mapping (like scholar) will not validate there without a test-specific mapping.
The bundled scholar mapping (ez_wikidata/resources/scholar_props.yaml) covers the columns of Template:Scholar:
| column | property | type |
|---|---|---|
| instanceof | P31 (fixed value Q5) | itemid |
| occupation | P106 | itemid |
| orcid | P496 | extid |
| dblp | P2456 | extid |
| gnd | P227 | extid |
| googleScholarUser | P1960 | extid |
| homepage | P856 | url |
| linkedInId | P6634 | extid |
| researchGate | P2038 | extid |
| shacl | P12861 | entity_schema |
occupation is optional and has no default: an occupation is asserted only when the record states one.
✍️🤖 Agent/Guido: ezwd -m <name> --list-mappings shows the columns of each; every mapping file carries the record of its example item in its header as 🌐🕸 annotation, see Py ez wikidata/Tutorial/Examples:
| name | file | creates | example | model |
|---|---|---|---|---|
| scholar | scholar_props.yaml | human Q5 with scholarly identifiers | Q140424194 | Concept:Scholar |
| paper | paper_props.yaml | scholarly article Q13442814 | Q141609355 | Concept:Paper |
| proceedings | proceedings_props.yaml | CEUR-WS proceedings volume Q1143604 | Q141623730 | cvb Wikidata sync of pyCEURmake 0.5.5 |
| event | event_props.yaml | event of a CEUR-WS volume, class from the record | Q141623731 | cvb Wikidata sync of pyCEURmake 0.5.5 |
| extension | extension_props.yaml | MediaWiki extension Q6805426 | Q140770649 | Concept:Extension |
| sandbox | sb_props.yaml | test properties of test.wikidata.org |
✍️🤖 Agent/Guido: the record carries the authors in their order; each author becomes an author statement (P50) whose series ordinal (P1545) is the 1-based index of the author in that list. The mapping declares this with listIndexBase: 1 on the qualifier, so ordinals are never supplied by the record and a wrong order can not be stated, see Py ez wikidata/Tutorial/Author order.
✍️🤖 Agent/Guido:
ezwd -m <name> --example runs it as dry run; semantify3 is a dependency (#19)--format prints the built item as RDF in the Wikidata model (#8)listIndexBase on qualifier mappings: series ordinal of the authors as 1-based list index, get_record orders by it (#15)--strict refuses record columns without mapping again (#13)Wikidata.explain_result renders a result's built item as readable text; the dry run prints it, item JSON only in debug mode (#13)Wikidata.check_result reports mapped record values without a claim and all conversion errors; --strict sets exit code 1 on problems (needs pybasemkit 0.2.6 for BaseCmd.exit_code, pybasemkit #21)Mapping corrections, both found while creating a scholar item: