HGIS-to-LINCS Exercise

Converting Canada boundary data to Linked Open Data

The Goal

We are going to take the Canada territorial boundaries data we explored in Part 1 and convert a subset of it into LINCS-compatible RDF/Turtle. This is the kind of task that LINCS contributors do regularly — taking structured historical data and expressing it as Linked Open Data using the CIDOC-CRM ontology.

Step 1: Load the Skills

Start a fresh Claude Code session in your claude_workshop folder:

cd claude_workshop
claude

Load the two skills we need:

/cidoc-crm
/lincs-profile

Step 2: Describe the Data

Copy boundaries_poly.csv and boundary_changes.csv into your working directory (or point Claude Code to where they are), then:

Read boundaries_poly.csv and boundary_changes.csv.
I want to convert this data to LINCS-compatible CIDOC-CRM.
First, describe what entities and relationships you see in the data.

Claude Code should identify entities like:

  • Places (territories, provinces) — E53_Place
  • Temporal extents (year_start, year_end) — E52_Time-Span
  • Events (treaties, proclamations) — E5_Event or E12_Production
  • Actors (sovereign powers) — E74_Group or E21_Person
  • Names (territory names, French names) — E48_Place_Name / E41_Appellation

Step 3: Model a Single Entity

Start small. Pick one territory — say, Rupert’s Land — and ask Claude Code to model it:

Model "Rupert's Land" as LINCS-compatible CIDOC-CRM in Turtle syntax.
It was controlled by the Hudson's Bay Company from 1670 to 1870.
Include the place, its name, temporal extent, and the controlling entity.
Do NOT add any Wikidata QIDs or other authority URIs --- leave entity
grounding for a later step. Use proper LINCS patterns.

Review the output. Check:

  • Are the CIDOC-CRM classes correct?
  • Are the properties connecting them appropriate?
  • Does the temporal modeling follow LINCS patterns?
  • Are URIs properly formed?
  • Are there any Wikidata QIDs (wd:Q…) in the output that you did not ask for? If so, delete them or ask Claude Code to regenerate without them.
Watch for hallucinated Wikidata QIDs

Even when you do not ask for them, Claude will often drop Wikidata QIDs into the Turtle output. There are two reasons for this:

  1. The LINCS skills tell it to. The CIDOC-CRM and LINCS profile skills both say things like “use authority URIs from Wikidata, GeoNames, etc., where possible, and mint a LINCS URI only if no external authority exists.” That instruction is correct in principle, but it implicitly assumes the model has a way to verify the authority — which without the Wikidata MCP server configured, it does not.
  2. The model defaults to the easy, plausible-looking answer. When asked for an authority URI it cannot verify, Claude (and every other current LLM) will happily generate a Q-number from memory. The Q-numbers look authoritative but the success rate is very low — they frequently point to a different entity, a disambiguation page, or nothing at all.

This is one of the most important lessons of working with LLMs on knowledge-graph data: a plausible-looking URI is not a verified URI. Until the Wikidata MCP is wired in, treat any unrequested authority URI as a hallucination and remove it. You may also need to remind Claude of this repeatedly during Steps 4 and 5 — the skills’ “use authorities where possible” instruction tends to pull it back toward inserting QIDs even after you have told it to stop.

We will come back to grounded entity disambiguation in Step 6 using the /place-disambig skill, which is structured around the MCP lookup rather than letting the model guess.

Step 4: Validate

/lincs-validate
Validate the Turtle you just produced against LINCS requirements.
Do not add any new authority URIs while fixing issues.

The validation skill checks against nine categories and reports PASS, WARN, or FAIL for each. Fix any issues:

Fix the warnings and regenerate the Turtle. Continue to leave Wikidata
QIDs and other authority URIs out --- mint LINCS URIs only.
Inspect the regenerated Turtle

After Claude regenerates, scan the file again for wd:Q… or other authority URIs you did not put there. The skills’ built-in “use authorities where possible” guidance often pulls them back in even after you have asked Claude not to. If you see new ones, delete them and tell Claude again.

Step 5: Scale Up

Now ask Claude Code to handle more of the dataset:

Convert all boundary changes from the Treaty of Paris (1763) into
LINCS-compatible Turtle. Include the treaty as an event, the
territories that changed sovereignty, and the sovereign entities.
Mint LINCS URIs for all entities --- do not insert any Wikidata QIDs
or other authority URIs.

Or try a broader conversion:

Write a Python script that reads boundaries_poly.csv and generates
LINCS-compatible Turtle for all territories. Use the patterns we
established for Rupert's Land, including LINCS-only URIs (no
hallucinated Wikidata QIDs). Save the output as canada_boundaries.ttl.

Step 6: Disambiguate Places (Demo Only)

Eventually you will want to ground each place in your data to a real Wikidata entity so other LINCS datasets can link to yours. The /place-disambig skill is designed for this:

/place-disambig
Disambiguate "Rupert's Land" to a Wikidata QID.
Why this is a demo and not a real workshop step

The skill is built around the Wikidata MCP server, which lets Claude Code do a vector search against the live Wikidata index. The MCP server is not configured in your fresh workshop setup, so when you run the skill today Claude will fall back to guessing QIDs from memory — and as we just saw in Step 3, it is wrong far more often than it is right.

We are showing you the skill so you know it exists and so you can set up the MCP after the workshop. For real entity grounding work, the workflow is:

  1. Configure the Wikidata MCP server in .claude/mcp.json (5–10 minutes, see the WikidataMCP project)
  2. Re-run /place-disambig — it will now do live vector lookups
  3. Verify each match by hand before adding it to your Turtle as owl:sameAs or skos:exactMatch

Even with the MCP, manual review is essential. Wikidata grounding is not a step to automate blindly.

What You Have Built

By the end of this exercise, you should have:

  • A Turtle file with LINCS-compatible RDF for Canadian territorial boundaries
  • Experience using CIDOC-CRM classes and properties for geospatial historical data
  • A workflow you can repeat with your own HGIS datasets

Next Steps

  • Keep asking questions. The best way to learn CIDOC-CRM, RDF, or any data modelling framework is to keep working with your own data. Tools like Claude Code can accelerate this — ask it to explain concepts, ask why it chose one class over another, ask it to compare approaches. But the real learning comes from constantly asking yourself where the tool is going off the rails. What did it get right? What is plausible-sounding nonsense? This is a different kind of critical thinking than most historians are trained in, and it is not always comfortable. Treat the output as a first draft from a confident but unreliable research assistant, not as an authority.
  • Your own data: Try the same workflow with a dataset from your own research
  • LINCS submission: If you want to contribute to LINCS, the validation skill can help ensure your data meets their requirements
  • SPARQL queries: Use /lincs-sparql to query existing LINCS data and see how other projects have modeled similar entities
  • Explore the skills repository: The full set of skills is at github.com/jburnford/lincs_skills — fork it and adapt the skills to your own domain