Working notes towards the next LPF: v1 round-trip defects, WHG’s prototype “v2”, and two stress tests (DEEP, PLATO)

[docuracy]

⚠️ Status of this post: working notes, not proposals.

I am using this Discussion to record and expose some ideas about where LPF might go next, so that they are visible to anyone who is interested and so that I stop carrying them around in private files. I am not yet ready to defend or discuss them. Nothing below is a position of the Pelagios Place Working Group, of ISHI, or of WHG; several points contradict things I have myself written or built; and some will turn out to be wrong. Please feel free to read, react, and leave comments, but don't expect prompt replies, and please don't treat any of this as settled or as a request for a decision. When individual items are ready to be argued for, they will become Issues or PRs of their own and I will link them from here.

---

1. Coordination: ISHI and the Pelagios Place Working Group

The README still directs people to a Google Group for "the Linked Places working group … discussing and implementing next steps". In practice LPF has been stable since v1.2.2 (2022), and as @kgeographer said on #51, stability is not a bad thing in a data standard. But #52, the recent traffic on #37, and the arrival of new implementers (Peripleo's SSI-funded maintenance, PLATO) suggest that some decisions now need a venue and a process.

The Institute for Spatial History Innovation (ISHI) at the University of Pittsburgh, which hosts World Historical Gazetteer, and the Pelagios Network's Place Working Group have undertaken to coordinate discussion of LPF's development. Concretely, as I understand it at the moment:

• The Working Group is the forum; this repository remains the record. Proposals should end up here as Issues and PRs, whatever channel they start in.
• The Working Group also hosts PLATO (Place Attestation Ontology), which defines LPF as its single-object-attestation profile. PLATO does not supersede LPF; the intention is that the simple interchange format and the richer model coexist, and part of the Working Group's job is to keep them aligned. Section 5 below is about what "aligned" would have to mean.
• Anyone can join: gazetteers@pelagios.org. Linked Pasts 12 (Porto, late November 2026) is an obvious place to talk in person; @eltonteb suggested as much on Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52.
• @kgeographer's ruling on Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52, that the context defines the schema's own elements and is not an identifier registry, and that any implementer must always accept full URIs, is accepted and is the kind of decision that should be written into the spec rather than left in an issue thread.

Everything below is my own list of what I think that coordination will need to deal with.

---

2. Problems in v1 that a round-trip exposes

By "round-trip" I mean: take a valid LPF document, expand it as JSON-LD with the declared context, or load it into an implementation and export it again, and compare. Most of these are cheap to fix and none of them needs a v2.

2.1 The context silently drops documented terms. Expanding the repository's own sample (linkedplaces-sample-v1.2.2.geojson) against linkedplaces-context-v1.1.jsonld discards geowkt (the context defines geo_wkt). Checking the README's documented keys against the context, the following have no term and therefore vanish on expansion: fclasses (required since v1.3), year (the only temporal grounding a name citation has, and the thing the spec says a record must have if it lacks a record-level when), duration, and the name/uri of a period. @gklyne reported the same class of problem for ccodes and citations in 2019 (#9, #10). Some of those were fixed; the pattern was not.

2.2 The type of year is undefined. Every README example writes "year": 1635 as an integer. The only JSON Schema anyone validates against (WHG's, see 2.5) declares it a string matching ^-?\d+$. The spec's own examples fail the only validator.

2.3 CURIE expansion is undefined for the prefixes in heaviest use. The context expands gn: to http://www.geonames.org/ontology#, so gn:2649808 becomes an ontology-term URI where no place lives. The README's alias table gives a different base. wd: and tgn: also disagree between the two sources, and periodo: carries a stray #. This is the substance of #52 and the README paragraph beginning "World Historical Gazetteer supports the name resources listed here; the aliases … should be used" is where the closed-enum thinking came from.

2.4 The @context URL is not durable. The spec says @context is required and gives http://linkedpasts.org/assets/linkedplaces-context-v1.jsonld as the example; that now redirects to the Humanities Commons home page. Documents in the wild (WHG's exports included) cite raw.githubusercontent.com/LinkedPasts/linked-places/master/…, i.e. the repository's old name and old default branch, which resolves only by GitHub's redirect. The README itself notes that the JSON-LD Playground cannot read the file for want of CORS. There is no permanent URL, and a format whose required context is a raw file on a renamed branch is one rename away from every existing document becoming un-expandable.

2.5 There is no schema in this repository. #8 (2019) asked for one and is still open. The only JSON Schema for LPF in existence is hosted by WHG, and it already deviates from the spec (see section 3). A format whose sole machine-readable definition lives with one implementer is the condition that produced #52 and will produce the next one.

2.6 A citation cannot carry a date range, a locator, or a link to its timespan. A citation is {label, year, @id}. On a name, citations[] and when are sibling arrays with no cross-reference, so once a name has two citations nobody can say which source supports which span. year is a single integer, so a regnal date, a circa, or a century has nowhere to go except the label. There is no page/folio/item. And, per @gklyne on #10, mapping the whole thing to cito:cites makes a GeoJSON Point the thing that cites a source, which is not what anyone means. Section 4 shows what this costs on a real dataset.

2.7 A timespan cannot carry anything. #47 proposed certainty on individual timespans and periods, and the v1.2.2 changelog records it as adopted "wherever when is used". The only schema in existence still has additionalProperties: false on timespan and dateObject, so a per-span certainty (or a per-span citation) fails validation.

2.8 GeoJSON is doing less work than it used to. Multiple geometries force a GeometryCollection, which the README admits GitHub no longer renders and which, as @kgeographer noted on #51, many "GeoJSON-supporting" tools mishandle. geowkt inside a geometry is not GeoJSON. Meanwhile the things people actually want to attach to a geometry (source, certainty, approximation, date) are exactly the things a GIS will strip on import. WHG's own export writes only the first geometry of a collection, which is an implementation bug but also a symptom.

2.9 Long-open structural questions that a next version has to answer rather than defer: #1 (parthood), #17 (multiple/hierarchical parents), #34 (must a record have a when?), #40/#41 (non-place features, features without location), #4 (a media type), #25/#30/#31 (an RDFS/SHACL expression).

---

3. WHG's prototype "v2" and what is wrong with it

WHG validates uploads against a schema it calls lpf_v2.0.jsonld, with a companion context lpo_v2.0.jsonld. For the record, what it adds over v1.3:

• a shared optionalProperties block (certainty, when, citations, approximation) accepted on every geometry, on relations, and (the Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52 change) on links;
• approximation on geometries (geo:hasSpatialAccuracy with a tolerance in km, geo:sfWithin, crm:P189_approximates, or any URI), which came out of Proposal for geometry.precision #37;
• ethnonym as an alternative to toponym in names[];
• certainty on when;
• source on descriptions;
• a collection-level citation in CSL-JSON;
• four more namespace prefixes in the closed enum (whg, osm, ohm, po).

Several of these are worth keeping and will come back as proposals. But as a "v2" it has the following problems, and I say this as the person responsible for most of them:

1. It is a schema without a specification. The additions exist only as comment fields inside a JSON Schema. There is no prose, no changelog, no versioned URL, and no statement of what a consumer is entitled to expect.
2. The version number is a misnomer. It is v1.3 plus patches. Nothing in it is a breaking change, and nothing in it addresses any of the structural issues in section 2.
3. Its context disagrees with its schema, and with LPF's. lpo_v2.0.jsonld defines 55 terms and omits citations, certainty, when, label, ccodes, fclasses, approximation and ethnonym. A document that declares it loses more on expansion than one declaring v1.1. The context also points at a draft Turtle file in a personal repository.
4. It keeps the closed prefix enum that Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52 argues against, only longer.
5. It has editorial notes baked into the schema (required-NOT-IN-LPF-TSV-SPEC, required-REMOVE-FROM-SPECIFICATION), and WHG's own repository carries two divergent copies of it.
6. WHG does not itself round-trip it. Ingest stores each names[], relations[] and geometry object verbatim, so it is faithful going in. On the way out the serialisers whitelist fields, and the download writes names, whens and related inside properties, emits only the first geometry, and declares the v1.1 context, not the v2 one it validated against. So the "v2" is an input validator, not an interchange contract.
7. The hosted files refuse non-browser clients. https://whgazetteer.org/schema/lpf_v2.0.jsonld and the context return 403 to anything without a browser user agent, which is what a JSON-LD processor is.

The honest summary: WHG has been maintaining a private fork of LPF's rules and calling it a version. The right move is to bring the useful parts here as proposals, retire the number, and stop deviating silently. That is the direction agreed on #52 and not yet acted on.

---

4. DEEP: a richly cited gazetteer that LPF v1 cannot hold without loss

DEEP (Digital Exposure of English Place-names, 2013) digitised the English Place-Name Society survey volumes into MADS XML. It is the type-case of a philological gazetteer: the value is not the places but the attestations, dated spellings with sources. The same shape recurs in every gazetteer derived from a place-name survey, so it is a good stress test.

	Count
Place records	539,372
Name forms (headword + variants, each with its own URI)	820,567
Attestations (dated citations of a spelling)	429,536
Dates on attestations (an attestation may have several)	441,237
Distinct source abbreviations	7,049
Records with coordinates	23,448, most with 2–4 competing points from different gazetteers

Each record has a headword, one broader link (county → hundred → parish → township → minor name), optional variant spellings, and for each variant a list of attestations: one or more structured dates (simple, circa, regnal, century, ante, post, no date, each with numeric begin/end), a source abbreviation with an id, and optional page, item, folio, manuscript sigil, personal-name marker, frequency count, and charter copy-date. About 6% of attestations are nested to express "1252 Cl et passim to 1346 Harl".

What maps cleanly to v1.3: the hierarchy (relations[], gvp:broaderPartitive), headword vs variant (title + names[]), competing coordinates (GeometryCollection with per-geometry citations), place type (types[].sourceLabels plus an AAT crosswalk), the source URL (links[], primaryTopicOf).

What is lost or degraded:

#	Loss	Why
1	Per-citation date structure	citation has only a single year; a name's when is a parallel array with no link to the citation that supports it
2	Date semantics	circa / regnal / century / ante / post collapse; earliest/latest keep the extent of uncertainty but not its kind
3	Bibliographic apparatus	page, folio, item, MS sigil, copy-date, count: string-only in label
4	Passim runs	no construct for "continuously attested across sources between two dates"
5	Source properties	the roman/italic distinction on source abbreviations, which carries meaning in EPNS practice, has no home; nor does any source-level metadata
6	Per-name URIs	names[] items have no @id
7	Normalised search forms	no slot; adding them to names[] conflates them with attested spellings
8	Record metadata	creation date, source volume

What would avoid the loss, in LPF's own idiom, is small:

• Let a citation carry when and certainty, exactly as WHG's schema already lets a link. The date then travels with the source that supports it. This alone removes losses 1 and 2.
• Give citation a CSL-style locator (locator, locator label, plus a count and a copy date). Removes 3, using a vocabulary that already exists.
• A collection-level sources[] registry of CSL items, with citations pointing into it by @id. Source-level properties live on the source, where they belong, and 400,000 repeated label strings leave the feature stream. Removes 5.
• Define @id and a role on names[] in the context. Removes 6 and 7.

Passim stays prose. The test that matters for all of the above is the context, not the schema: an undefined term is dropped on expansion however tolerant the validator is.

---

5. What LPF would need in order to express a PLATO-modelled gazetteer

PLATO's unit is the Attestation: a node that bundles a SpatialEntity with any subset of Name, Geometry, Timespan, Type, PropertyValue and Source, and carries certainty, contributor and notes. Names, geometries, timespans and sources are reusable nodes with their own URIs. PLATO's README defines LPF as the profile in which every attestation links one entity to one facet.

I first checked whether DEEP itself survives PLATO, since a model that cannot hold the exemplar is not a useful target. It does, and notably better than LPF on precisely the points where LPF fails:

DEEP construct	PLATO
Attestation (variant + dates + source)	Attestation bundling Name + Timespan(s) + Source. Multiple dates → multiple timespans; an attestation covering several spellings → several names on one attestation
Date subtypes	four-date model plus startPrecision/endPrecision (century is in the enum), label for "Hy 3", edtfString for the original expression
Source abbreviations	reusable Source nodes with @id
Competing coordinates	one Geometry per gazetteer, each in its own attestation, sourceCrs for KEPN's OSGB eastings
Gazetteer cross-references (geonames:2652613 etc.)	IdentityRelation (closeMatch) with source and certainty, which is more correct than LPF's links[]
Passim runs	one attestation with a range timespan and several sources, with the constituent attestations kept alongside
Per-name URIs, hierarchy, type codes, record dates	Name.@id; relation attestations with a RelationType; Type.sourceLabel; Attestation.created

What PLATO currently lacks, all of it at the source/citation boundary:

• A citation locator. sourced_by goes straight from Attestation to Source; there is nowhere for page, folio or item. PLATO conflates the source with a citation of the source at a locus. It needs either a reified citation or locator properties on the attestation keyed by source.
• Source date and derivation. A charter known from a later cartulary copy is two sources, one derived from the other, each with a date. Source has title, URI and a citation string only.
• Small typed attestation properties (frequency count, personal-name marker) currently land in notes.
• nameType is a closed enum without a headword or normalised-form value; Type.identifier is required, which forces a crosswalk for opaque survey codes (sourceLabel keeps the original, so this is inconvenience rather than loss).

Those are PLATO issues and are now filed there: the locator gap was already open as pelagios/place-attestation-ontology#7, to which I have added the DEEP evidence; the others are #11 (source date and derivation), #12 (occurrence count and context) and #13 (name-form status). The question for this repository is the reverse: given a gazetteer modelled in PLATO, what does LPF need so that the projection is either lossless or lossy in a declared way? My current list:

1. Identifiers on facets. @id on names[], on each geometry, on each timespan, and on each type, so that a shared Name or Geometry node survives the trip. Without this, "the same name attested for two places" becomes two strings.
2. An attestation grouping key. An LPF name, type, geometry and relation can each carry their own when and citations, which makes each of them a single-facet attestation already. What they cannot say is "these three came from the same attestation". One optional attestation id on each element (or an attestations[] array on the feature) closes that.
3. Sources as first-class objects (section 4's registry), because PLATO's Source has a title, a URI and a bibliographic string, and {label, year, @id} cannot carry that back.
4. Certainty as a number. PLATO's certainty is 0.0–1.0 with a note; LPF's is a three-value enum. A mapping is easy one way and lossy the other. PLATO also separates fuzziness (the referent has no sharp boundary) and relativity ("two leagues north of X"), which LPF has no slot for at all.
5. Timespan precision and openness. in/earliest/latest covers the four-date model, but startPrecision, openStart/openEnd and an EDTF string do not survive.
6. Geometry role and CRS. PLATO distinguishes an extent from a feature point from a label anchor, and records the source CRS. approximation (WHG v2) covers accuracy but not role.
7. PropertyValue. Population, valuation, market days: LPF has nowhere to put an attribute that is not a name, type, geometry or relation. This may be the one thing that is legitimately out of scope, in which case the spec should say so.
8. Identity relations vs links. PLATO's IdentityRelation carries basis, asserter, timestamp and the candidate it was promoted from; links[] with certainty (Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52) is the minimum, not the whole.
9. Meta-attestations ("A contradicts B") need a target, which needs item 2.

If items 1–4 were adopted, LPF could genuinely be PLATO's single-facet profile and a PLATO gazetteer would round-trip through it. If they are not, LPF remains the deliberately lossy GeoJSON projection that PLATO already plans to generate for GIS use, and that is also a legitimate outcome; it just needs to be chosen rather than arrived at.

---

6. Where this might go (tentative, not committed)

Things that could become separate Issues or PRs, roughly in order of how cheap they are:

• Fix the context: add fclasses, year, geowkt, duration, name, uri; correct the gn and periodo expansions; and put a permanent URL in front of it (2.1, 2.3, 2.4).
• Settle the type of year (2.2) and adopt the Two proposals from reconciliation output: certainty on links[], and one authoritative list of identifier prefixes #52 rule in the README text.
• Adopt a JSON Schema here, versioned and changelogged, with WHG's as the starting point minus its private extensions (2.5, 3).
• Bring the WHG v2 additions here one at a time as proposals: optionalProperties on links, approximation, ethnonym, certainty on when, collection-level CSL citation.
• Then the substantive ones: citation when/locator, a sources registry, facet ids, an attestation key.

I will edit this post as the thinking changes, and note the edits at the bottom. Again: notes, not proposals; recorded here so that they are not lost, not so that they can be argued yet.

— Stephen Gadd (WHG / Pelagios Place Working Group), 26 September 2026

Edits

• 2026-09-26: section 5 now links the four PLATO issues (Fixed typo in context #7 comment, Use of @type in expanded term definitions in JSON-LD context #11, Fix Wikipedia link in tsv.md #12, Missing link for aat_types in tsv.md #13) that were promised there.