Appearance
Scholia turns a Wikidata item into a live, multi-panel dashboard, so the fastest way to visualise heritage data well is to treat Scholia as a read-out of your data quality rather than a drawing tool. Point it at a Q-identifier (an author, a collection, a work, a topic) and it runs dozens of SPARQL queries to render bar charts, timelines, maps and co-occurrence networks. Good Scholia output is therefore a downstream effect of good statements on the underlying items.
What can Scholia actually visualise for heritage?
Scholia organises every dashboard into aspects. For collections and archives the most useful are:
- Author / creator profiles — works, timelines, co-authorship graphs.
- Organisation profiles — holdings, staff, related institutions.
- Topic profiles — items with
P921(main subject), publications over time. - Work profiles — provenance, exhibitions, citing items.
- Collection / location maps drawn from
P625(coordinates).
Each panel is a self-contained SPARQL query. If a panel is blank, that query returned nothing — which is information.
How do I get a clean Scholia profile?
Pick the Q-identifier and check its statements first. A useful baseline checklist:
text
[ ] instance of (P31) is set correctly
[ ] label + description present in your working languages
[ ] P50 (author) / P170 (creator) link works to people
[ ] P195 (collection) ties items to the holding institution
[ ] P921 (main subject) tags topics for topic dashboards
[ ] P625 (coordinates) present where a map is expected
[ ] references (P248 / reference URL) on factual claimsThen open https://scholia.toolforge.org/topic/Q<id> (swap the aspect for author, work, etc.). Iterate: add statements, refresh, repeat.
How do I export a chart that survives peer review?
Every Scholia panel has a small link to "the underlying SPARQL query". Click it to open the Wikidata Query Service (WQS), then export:
text
WQS → run query → Download ▾
• SVG — vector, best for print figures
• PNG — raster, quick slides
• CSV / TSV — the raw rows behind the chartCite the query URL plus an access date, not the Scholia page. Because the data is live, archive the CSV alongside your manuscript so the figure can be regenerated byte-for-byte.
Should I customise Scholia or just use it as-is?
| Need | Use stock Scholia | Fork / self-host |
|---|---|---|
| Quick profile of a person or topic | Yes | No |
| Slightly different filter on an existing panel | Edit the SPARQL in WQS | No |
| A brand-new reusable aspect for your project | No | Yes |
| Private / pre-publication data | No (it reads live Wikidata) | Yes, point at your own endpoint |
Self-hosting means running the Scholia Flask app and editing the Jinja-wrapped SPARQL templates. Only do this when a panel must become a permanent project deliverable.
Why is documentation a best practice, not an afterthought?
Across a whole collection, undocumented Scholia views are not defensible: a reviewer cannot tell whether a gap is a real absence or a missing statement. Keep a short data dictionary mapping each figure to its query, the access date, and the properties it depends on. This is what makes results consistent and reproducible when you re-run them six months later.
What are the common Scholia failure modes?
- Sparse items — the dashboard renders but every panel is thin. Enrich
P31,P50,P921. - Timeout — a co-author or citation graph times out at 60 seconds. Narrow with a
LIMITor a date filter in WQS. - Wrong aspect — you opened the author view for a place. Match the aspect to
P31. - Label gaps — nodes show Q-numbers instead of names; add labels in your languages.
Key Takeaways
- Scholia visualises live Wikidata via SPARQL; quality output depends on quality statements.
- Fix the underlying item (
P31,P50,P195,P921,P625) before blaming the tool. - Match the aspect (author, topic, work, organisation) to what the item actually is.
- Export figures from the underlying WQS query as SVG/CSV and cite the query URL plus access date.
- Archive the result set because live data changes; a Scholia URL alone is not citable.
- Self-host only when you need a permanent custom aspect or pre-publication privacy.
- Keep a figure-to-query data dictionary so the whole collection stays defensible.
Frequently Asked Questions
What is Scholia and what data does it visualise?
Scholia is a free web service that builds live dashboards from Wikidata using SPARQL behind the scenes. For heritage work it visualises authors, works, collections, topics and co-authorship or provenance networks tied to Wikidata items (Q-identifiers).
Do I need to install anything to use Scholia?
No. Scholia runs in the browser at scholia.toolforge.org and queries the live Wikidata Query Service. You only need a Q-identifier or a search term, though you can self-host the Flask app if you need custom aspects.
Why does my Scholia profile look empty or wrong?
Almost always it is a data problem, not a Scholia problem: the underlying Wikidata items lack the statements Scholia expects, such as P50 (author), P195 (collection) or P921 (main subject). Fix the items and the panels populate.
Can I export a Scholia chart for a publication?
Yes. Open the underlying query in the Wikidata Query Service via the panel's link, then download the result as SVG, PNG or CSV. Cite the query URL and the access date so the figure is reproducible.
Is a Scholia view stable enough to cite?
The visualisation regenerates from live data, so it changes as Wikidata changes. Cite the timestamped SPARQL query rather than the Scholia URL, and archive a copy of the result set if the figure must be fixed.
How do I make a custom Scholia panel?
Scholia panels are SPARQL templates with a placeholder Q-identifier. You can fork the Scholia repository, add an aspect under the relevant view, and the new SPARQL query becomes a reusable panel for every matching item.