Spatial coverage¶

A metadata declaration publishing the geographic region within which a resource is valid — an explicit inclusion-exclusion rule on the spatial dimension that lets the catalog check, before any analysis, whether a question's scope falls inside or outside it.

Core Idea¶

Spatial coverage is a metadata declaration that a resource — dataset, claim, service, or document — is valid only within a stated geographic region. The structural commitment is to publish an explicit inclusion-exclusion rule on the spatial dimension, encoded canonically as DCAT's dct:spatial or Schema.org's spatialCoverage, so that downstream consumers can detect at the catalog layer whether their question's geographic scope falls within or outside the resource's validity region before any analysis begins. Without this declaration, a consumer who joins or queries a regionally scoped resource against out-of-region questions will silently receive zero rows or wrong aggregates and have no machine-readable signal distinguishing "no data here" from "no signal in the world"; the spatial-coverage field surfaces that distinction as a catalog-level mismatch. The act the declaration performs is to push the applicability check upstream of the pipeline: rather than discovering at analysis time that a Bay Area air-quality dataset contributes nothing to an African query, the catalog enforces the mismatch as a typed error. In federated data ecosystems with many co-registered resources, the declared spatial coverage is also the precondition for region-aware search (find all datasets covering the Iberian Peninsula), join-validity checking (these two layers can only be meaningfully joined where their coverages intersect), and refusal of nonsensical cross-region aggregations.

Structural Signature¶

Sig role-phrases:

the resource — the dataset, claim, service, or document whose geographic applicability is being declared
the spatial region — the bounded set of locations the resource is valid for, the region it was built to describe
the inclusion-exclusion rule — how membership in the region is decided (bounding box, polygon, named place, CRS), the explicit rule on the spatial dimension
the publication channel — the metadata field the declaration is recorded in, canonically DCAT dct:spatial or Schema.org spatialCoverage
the consumer query — the in-region or out-of-region question whose geographic scope is checked against the declaration
the intersection test — the single mechanical operation the field licenses: does the query's scope intersect the resource's coverage, computable at the catalog layer before any analysis
the mismatch surface — the typed catalog-level refusal or warning that fires on an out-of-region join, disambiguating "no data here" (scope artifact) from "no signal in the world" (substantive null)
the joint-validity ceiling and silence default — the limitations: joint inference is valid only within the intersection of participating coverages (power cannot manufacture validity outside it), and an unpublished coverage reads as unknown scope, never global

What It Is Not¶

Not the data structure for region queries. Spatial coverage is a declaration of where a resource is valid, not the spatial index (R-tree, geohash, quadtree) that makes region lookups efficient. One states applicability for the catalog to check; the other accelerates retrieval. A resource can be richly indexed yet silent on its coverage, and vice versa.
Not "global unless stated otherwise." An unpublished coverage reads as unknown scope, never global scope. Treating silence as global is the canonical error — it licenses confident cross-region use of a resource that may apply nowhere near the question; the safe default excludes the silent resource from cross-region claims.
Not the act of carving a space into regions. Segmentation and boundary-drawing create the partition; spatial coverage merely publishes which existing region a resource applies to. It is a documentary slot on an applicability claim, not the operation that produces the regions.
Not a guarantee of data quality within the region. Declaring coverage of the Iberian Peninsula says the resource is in scope there, not that it is dense, accurate, or complete there. Coverage is an inclusion-exclusion claim on applicability; it carries no promise about the signal's quality inside the validity region.
Not validity beyond the coverage intersection. When several resources are joined, the region in which the joint inference is valid is bounded by the intersection of their coverages — no amount of statistical power manufactures validity outside it. Reading a conclusion drawn beyond that intersection as warranted over-reads the declaration.
Not a distinct structural mechanism. Stripped of the spatial-and-documentary specifics, spatial coverage is publishing a boundary (an inclusion-exclusion rule) along a chosen dimension via metadata/documentation, with space merely the dimension parameter. It is a sibling facet of temporal_coverage, not a new pattern — the cross-cutting content belongs to those parents and to a general applicability-scope mechanic, not to this slot as named.

Scope of Application¶

Because spatial coverage is a metadata declaration, not a mechanism, it is not bounded by a single domain: it applies literally wherever its precondition holds — a resource has a scope statable as an inclusion-exclusion rule on the spatial dimension and checkable against a question's scope — and the contexts below are genuine uses of the identical applicability claim, not metaphors. The boundary to police is over-reading (silence read as global scope; validity read beyond the coverage intersection), and the cross-cutting residue is publishing a boundary via metadata, a sibling facet of temporal_coverage.

Open-data portals — DCAT-compliant catalogs (data.gov, the EU Open Data Portal) requiring dct:spatial on every dataset record so consumers can detect region mismatches at the catalog layer.
GIS and mapping — every layer carrying an explicit bounding box and coordinate reference system, which is the spatial-coverage declaration in cartographic form.
API and service catalogs — weather, transit, and routing APIs publishing their service area, so calls outside it return well-defined errors rather than silent empties.
Enterprise data inventories — internal catalogs tagging data products with the regions, sites, or business units they cover, to support governance and compliance.
Clinical and epidemiological evidence — external-validity claims attaching a population-region scope to a finding, marking where a result is in scope to be applied.

Clarity¶

The field's clarifying force is to separate two things that an undocumented resource silently fuses: the region a resource was built to describe and the region a consumer wants to ask about. Once that separation is named and published, a geographic mismatch stops being an analysis-stage surprise and becomes a catalog-level fact a machine can check. The sharpest distinction it makes legible is the one that otherwise has no machine-readable signal at all — "no data here" (the question fell outside the resource's declared validity region) versus "no signal in the world" (the resource covers the region but found nothing). A query returning zero rows is ambiguous between those two until spatial coverage is declared; with it, the catalog can attribute the emptiness to scope rather than to absence, and a consumer is spared mistaking an out-of-region join for a real null result.

Declaring it also fixes the default that silence would otherwise leave open: a resource with no published coverage should be read as unknown scope, not global scope. That convention lets a cataloger ask the region-aware questions that are otherwise unanswerable mechanically — which resources cover this place, where two layers' coverages intersect (and so where a join is even meaningful), and which cross-region aggregations are nonsensical and should be refused. The applicability check moves from buried inside each pipeline to the front, where it can be enforced once for all consumers rather than rediscovered by each.

Manages Complexity¶

A federated ecosystem holds thousands of co-registered resources, each valid only somewhere, and the question every consumer faces — is this resource applicable to where my question lives? — is, undeclared, an open-ended judgment rediscovered inside each pipeline, one resource and one query at a time, often only after a join has silently returned zero rows. Spatial coverage compresses that sprawl by reducing each resource's geographic applicability to a single published object: an explicit inclusion-exclusion rule on the spatial dimension (dct:spatial / spatialCoverage). The consumer no longer reasons case by case about whether a Bay Area dataset bears on an African query; the cataloger tracks one declared region per resource and reads applicability off a single mechanical test — does the query's geographic scope intersect the resource's coverage? That one intersection check, computable at the catalog layer before any analysis runs, settles a whole family of otherwise per-pipeline questions at once: region-aware search (which resources cover the Iberian Peninsula), join validity (two layers are joinable only where their coverages intersect), and the refusal of cross-region aggregations that have no meaning. It also collapses an ambiguity that, undeclared, has no machine-readable resolution at all — "no data here" versus "no signal in the world" — into a typed catalog fact, with the default for an unpublished coverage fixed once as unknown rather than global. The analyst thus tracks, per resource, a single declared region and reads off validity, joinability, and the meaning of an empty result, instead of re-deriving the applicability check inside every consumer for every query — the move from an open, per-pipeline applicability problem across a large resource set to one published rule per resource with a single intersection test.

Abstract Reasoning¶

Spatial coverage licenses reasoning moves that all run through one operation — testing whether a query's geographic scope intersects a resource's declared validity region — and that resolve, at the catalog layer, questions which otherwise surface only as analysis-stage surprises.

Diagnostic, on the meaning of an empty result. The signature inference disambiguates a zero-row return. A query that comes back empty is, absent the declaration, ambiguous between two incompatible explanations: the question fell outside the region the resource describes ("no data here") or the resource covers the region and genuinely found nothing ("no signal in the world"). The analyst reasons from the published coverage to the correct attribution — if the query region does not intersect the declared coverage, the emptiness is a scope artifact and carries no information about the world; if it does intersect, the null is substantive. The same move detects silent misuse before it happens: a join against an out-of-region resource is inferred to contribute nothing not from inspecting the returned rows but from the coverage mismatch itself, surfaced as a typed catalog error rather than discovered downstream.

Interventionist, pushing the applicability check upstream. The act the declaration performs is to relocate the validity test from inside each pipeline to the front of the catalog, and the licensed intervention follows: enforce the intersection check once, for all consumers, before any analysis runs, and predict that doing so converts a class of silent wrong-answer failures (zero rows mistaken for a real null, cross-region aggregates that look plausible but are meaningless) into loud catalog-level refusals. The analyst can therefore design region-aware search (return exactly the resources whose coverage contains the place in question), gate joins (permit a join only on the region where two layers' coverages overlap), and refuse aggregations across non-intersecting coverages — each a concrete action whose effect is predicted by the coverage geometry rather than rediscovered per query.

Boundary-drawing, on the validity region of a joint inference and the default for silence. Two boundary rules are licensed. First, the region within which any joint inference is valid is bounded by the intersection of the participating resources' coverages: outside that intersection at least one input is out of scope, so a conclusion drawn there is unwarranted regardless of statistical power — power cannot manufacture validity where the resource simply does not apply. Second, the concept fixes the default an unpublished coverage must be read under: absence of a declaration means unknown scope, never global scope, so a resource silent on coverage is excluded from confident cross-region use rather than presumed to apply everywhere. Drawing these two lines — the intersection as the ceiling on joint validity, and unknown-not-global as the reading of silence — is what keeps the catalog from over-claiming.

Predictive / order-of-operations. The concept dictates that the applicability check must precede analysis: the intersection test is computable at the catalog layer from metadata alone, so the analyst runs it first and predicts which resources can even contribute to a given geographic question before spending any computation on the join or fit. A resource whose coverage excludes the query region is ruled out at the front, sparing the pipeline an empty result later that would have been ambiguous to interpret.

Knowledge Transfer¶

Spatial coverage is a metadata declaration — a typed property published about a resource — not a causal mechanism in the world, so the "mechanism within the home domain / metaphor beyond it" framing does not apply. It is an instrument-grade construct — case (C) — and the right thing to characterize is the reach of the construct itself. Within data science and analytics the declaration transfers across artifact classes as the same notation, not as analogy: DCAT's dct:spatial on an open-data record, a GIS layer's bounding box and CRS, an API's published service area, an enterprise catalog's region/site/business-unit tag, and a clinical finding's population-region external-validity scope are all dual encodings of one applicability claim, and the single mechanical test it licenses (does the query's geographic scope intersect the resource's declared coverage?) runs identically across all of them. The consumer-facing service-area map and the machine-readable metadata field are the same claim in two forms.

The boundary worth marking here is therefore not analogy-versus-mechanism but instrument-reach versus over-reading. The construct applies literally wherever its precondition holds — wherever a resource has a scope that can be stated as an inclusion-exclusion rule on the spatial dimension and checked against a question's scope — and that is exactly why it recurs across catalogs, GIS, APIs, and evidence inventories: each genuinely has such a scope to publish. The over-readings to police are specific. Reading silence as global scope is the canonical error: an unpublished coverage means unknown scope, never global, so a resource silent on coverage must be excluded from confident cross-region use rather than presumed to apply everywhere. Reading the intersection rule too loosely is the other: the region within which a joint inference is valid is bounded by the intersection of the participating resources' coverages, and no amount of statistical power manufactures validity outside it. And there is a deeper over-reading at the catalog-design level: spatial coverage should not be treated as a distinct structural mechanism. Strip the spatial-and-documentary specifics and what remains is publishing a boundary (an inclusion-exclusion rule) along a chosen dimension, recorded via metadata/documentation — with space merely the dimension parameter. That is the genuinely cross-cutting content, and it is carried by those parent primes, of which spatial coverage is one dimensional facet. It is a sibling metadata slot of temporal_coverage, and both look like facets of a more general applicability_scope mechanic (publish-a-boundary-on-applicability) that would be the honest home for the cross-domain generalization. So the construct transfers literally wherever a declarable scope exists; its reach is wide but instrumental, and what must be guarded is over-reading the declaration — as global by default, as validity beyond the coverage intersection, or as a new mechanism rather than a published boundary (see Structural Core vs. Domain Accent).

Examples¶

Canonical¶

The precise defining construction is a DCAT dataset record carrying dct:spatial. Suppose an air-quality dataset covers only the San Francisco Bay Area. Its catalog record declares this once, for example as a bounding box — roughly longitude −123.0 to −121.5, latitude 37.0 to 38.5 (or, equivalently, a GeoNames URI for the Bay Area) — in the dct:spatial field (Schema.org's spatialCoverage is the dual encoding). Now a consumer issues a query scoped to Nairobi, Kenya (about longitude 36.8, latitude −1.3). The catalog computes one intersection test: does the query point fall inside the declared box? It does not, so the catalog returns a typed out-of-scope mismatch before any join runs — rather than the pipeline silently executing and handing back zero rows that the analyst cannot distinguish from a genuine null.

Mapped back: The air-quality dataset is the resource; the Bay Area box is the spatial region expressed as the inclusion-exclusion rule, recorded in dct:spatial — the publication channel. The Nairobi-scoped request is the consumer query; the box-membership check is the intersection test, and the typed refusal is the mismatch surface separating "no data here" from a real null.

Applied / In Practice¶

Geospatial engineering deploys the same declaration through every GIS layer's bounding box and coordinate reference system. Consider a flood-hazard map — say a national agency's 100-year floodplain layer for one river basin — packaged with an explicit extent and CRS (e.g., EPSG:4326). When an analyst overlays it with a separate layer, such as a parcel-boundary layer for an adjacent county, the GIS uses each layer's declared extent to bound the operation: the meaningful result exists only where the two extents overlap. A spatial join or risk calculation attempted outside that intersection is flagged or returns nothing, so planners cannot accidentally assign flood risk to parcels the hazard layer never covered — the intersection rule enforced automatically in the mapping pipeline.

Mapped back: Each map layer is the resource; its bounding box plus CRS is the inclusion-exclusion rule and publication channel in cartographic form. Overlaying the floodplain and parcel layers exercises the intersection test, and confining valid flood-risk assignment to where the two extents overlap is the joint-validity ceiling — inference bounded by the intersection of participating coverages, not extended by wishful overlay.

Structural Tensions¶

T1: Upstream applicability check versus the maintenance burden of a live declaration. Pushing the applicability test to the catalog layer — one intersection test before any analysis — is the whole value: a mismatch fires as a typed error instead of a silent zero-row join. But a published coverage is a claim that must stay true as the resource evolves; a dataset that quietly extends or contracts its real region while its dct:spatial box stays fixed produces confident intersection verdicts that no longer hold. The declaration trades analysis-stage surprises for a standing commitment to keep the metadata synchronized with the resource, and stale metadata is worse than none because the catalog now vouches for it. Diagnostic: Is the declared region guaranteed to track the resource's actual validity, or can the resource's real coverage drift away from the box the catalog checks?

T2: Silence-as-unknown versus silence-as-global (a safe default that suppresses usable resources). Fixing the default so an unpublished coverage reads as unknown rather than global is the canonical guard against confident cross-region misuse. But the safe reading has a cost: a resource that genuinely is global, or genuinely does cover the query region, but simply never published its scope, is excluded from confident use — the default protects against over-claim by under-claiming. The convention is correct precisely because it errs toward exclusion, and that erring is itself a real loss of otherwise-applicable data whenever documentation lags behind actual coverage. Diagnostic: Is the resource's silence on coverage evidence of limited scope, or merely undocumented scope that the unknown-default is now needlessly excluding?

T3: Inclusion-exclusion boundary versus quality inside it (in-scope is not the same as good-there). Declaring coverage of a region makes a crisp membership claim the catalog can check — but it says only that the resource applies there, not that it is dense, accurate, or complete there. A consumer who reads a passed intersection test as a warrant of usable data conflates applicability with quality, exactly the fusion the field does not resolve. The declaration's crispness (a box, a polygon, a named place) can itself lend a false sense that everything inside the region is equally sound. Diagnostic: Does the decision need the resource merely to be in-scope for the region, or to have adequate signal density there — and is anything checking the latter?

T4: Intersection ceiling versus statistical power (validity the metadata caps and power cannot restore). When resources are joined, the region in which the joint inference is valid is bounded by the intersection of their coverages — a hard ceiling the field draws. The tension is that this ceiling is invisible to the machinery that usually signals confidence: a join over a large sample drawn partly outside the intersection returns tight confidence intervals that certify nothing, because power computed on out-of-scope rows manufactures precision without validity. The metadata boundary and the statistical boundary can point in opposite directions, and the coverage one governs. Diagnostic: Does the conclusion draw only on the region where every participating resource's coverage overlaps, or does its apparent power come partly from out-of-intersection data?

T5: Autonomy versus reduction (its own metadata slot or a boundary-on-a-dimension instantiated in space). "Spatial coverage" (dct:spatial / spatialCoverage) is a real, canonically-encoded instrument, and unusually it applies literally wherever a scope can be published — but that breadth is instrumental, not a sign it is its own mechanism. Strip the spatial-and-documentary specifics and what remains is publishing a boundary (an inclusion-exclusion rule) along a chosen dimension via metadata/documentation, with space merely the dimension parameter; it is a sibling facet of temporal_coverage, and both look like facets of a general applicability-scope mechanic. Diagnostic: Resolve toward the boundary-via-metadata parent (and the applicability-scope generalization) when asking what the cross-cutting content is; toward "spatial coverage" when recording or checking a resource's geographic validity in a catalog.

Structural–Framed Character¶

Spatial coverage sits in the mixed region of the spectrum, with a profile unusual for a domain-specific entry: it is not a mechanism at all but a documentary instrument — a typed metadata declaration — so its framed and structural marks sit in an atypical arrangement. Its evaluative_weight is neutral: publishing where a resource is valid renders no verdict, praising and condemning nothing; it states an inclusion-exclusion fact for a catalog to check. But it is thoroughly human_practice_bound: a coverage declaration exists only as an act within a data-publishing and cataloging practice — there is no "spatial coverage" in a world without resources, consumers, and the documentation convention that lets one be checked against another, and the whole construct dissolves if that practice is removed. Its institutional_origin is correspondingly strong: dct:spatial, Schema.org's spatialCoverage, and the DCAT catalog standards are stipulated artifacts of a metadata tradition, not facts of nature. Where it turns structural is vocab_travels and import_vs_recognize: within data science the identical notation travels across artifact classes (open-data records, GIS bounding boxes, API service areas, clinical external-validity scopes) as literal co-instances rather than analogies — instrument-reach, not metaphor — because each genuinely has a scope to publish; what stays home is only the spatial-and-documentary trappings, and beneath them the content is fully general.

The portable skeleton is publishing a boundary — an inclusion-exclusion rule — along a chosen dimension via metadata/documentation, with space merely the dimension parameter; it is the sibling of temporal_coverage and a facet of a general applicability-scope mechanic (publish-a-boundary-on-applicability). That boundary-via-metadata pattern is what spatial coverage instantiates from its parents, and the cross-cutting content belongs to them; "spatial coverage" as named is one dimensional facet, distinctive only in fixing the dimension to geography and the encoding to dct:spatial/spatialCoverage. Its character: an evaluatively-neutral but wholly practice-constituted, standards-codified metadata instrument whose structural core is a boundary published on a dimension, mixed — belonging to boundary-via-metadata for everything that travels and to the catalog convention for everything that names it.

Structural Core vs. Domain Accent¶

This section decides why spatial coverage is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity — with the wrinkle that spatial coverage is a documentary instrument, not a mechanism, so the line is drawn between instrument-reach and over-reading rather than between mechanism and metaphor.

What is skeletal (could lift toward a cross-domain prime). Strip the geography and the metadata trappings and a thin relational structure survives: a resource publishes an inclusion-exclusion rule fixing the region of a chosen dimension within which it is valid, so a consumer can test — before use — whether a question's scope falls inside or outside that region. The portable pieces are abstract — a resource, a declared validity region, an inclusion-exclusion rule, a publication channel, and a single intersection test computable ahead of analysis. This core is genuinely substrate-portable — indeed it is exactly the parent primes the entry names: publishing a boundary (an inclusion-exclusion rule) along a dimension via metadata/documentation, with space merely the dimension parameter. That is why it recurs, as literal co-instances rather than metaphors, across open-data records, GIS layers, API service areas, enterprise inventories, and clinical external-validity scopes — and why it has a dimension-sibling in temporal_coverage and a plausible general home in an applicability_scope mechanic. But it is the core the entry shares, not what makes spatial coverage distinctive.

What is domain-bound. What is distinctive to spatial coverage in particular is thin but real: the fixing of the dimension to geography, and the specific encodings and standards the practice supplies — DCAT's dct:spatial, Schema.org's spatialCoverage, the bounding-box/polygon/CRS machinery, the GeoNames/EPSG vocabularies, and the DCAT catalog conventions that make the intersection test a cartographic operation. These are the worked instruments the discipline actually uses. The decisive test: strip the spatial-and-documentary specifics — the box, the CRS, the dct:spatial slot — and what remains is not "spatial coverage" but the bare act of publishing a boundary on a dimension, indistinguishable in structure from temporal_coverage with the dimension swapped. Nothing peculiar to space survives the extraction; the dimension parameter is the only thing that made it spatial.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain reach is recognition of the same mechanism, not analogy. Spatial coverage's reach is unusual: because it is an instrument rather than a mechanism, the identical notation travels literally wherever a declarable spatial scope exists — DCAT records, GIS bounding boxes, API service areas, clinical population-region scopes are dual encodings of one applicability claim, and the single intersection test runs the same across all of them. That very breadth is the tell that the cross-cutting content is not proprietary to this slot: what travels is the general publish-a-boundary-on-applicability pattern, and spatial coverage is one dimensional facet of it, keyed to geography. When the bare cross-cutting content is needed — a validity region checkable before use — it is already carried in more general form by the parents the entry instantiates: boundary published via metadata/documentation, sibling to temporal_coverage and facet of a general applicability_scope mechanic. The cross-cutting reach belongs to those parents; "spatial coverage," as named, is their geographic instance, distinctive only in fixing the dimension to space and the encoding to dct:spatial/spatialCoverage — accent that should stay home. (The over-readings the entry polices — silence-as-global, validity-beyond-intersection, treating the slot as a new mechanism — are precisely the errors of mistaking the domain-specific facet for a first-class prime.)

Relationships to Other Abstractions¶

Current abstraction Spatial coverage Domain-specific

Parents (1) — more general patterns this builds on

Spatial coverage is a decomposition of Applicability Scope Prime

Removing geographic metadata vocabulary leaves a forward-published, machine-checkable applicability envelope on one dimension.

Hierarchy path (1) — routes to 1 parentless root

Spatial coverage → Applicability Scope → Boundary

Not to Be Confused With¶

Spatial index (R-tree, geohash, quadtree). The data structure that makes region lookups fast, not a declaration of where a resource is valid. One accelerates retrieval; the other states applicability for the catalog to check before analysis. A resource can be richly indexed yet silent on its coverage, and vice versa. Tell: does the artifact speed up geographic queries over the data (spatial index), or declare the region within which the resource itself is in scope (spatial coverage)?
Temporal coverage. The dimension-sibling — the identical publish-a-boundary-on-applicability structure with time swapped for space (a validity interval instead of a validity region), checked by the same intersection test. Same machinery, different dimension parameter; neither is a distinct mechanism. Tell: is the declared validity a geographic region (spatial coverage), or a time span the resource applies within (temporal coverage)?
Segmentation / boundary-drawing. The operation that creates a partition of space into regions. Spatial coverage does not carve regions; it publishes which existing region a resource applies to — a documentary slot on an applicability claim, not the act that produces the regions. Tell: does the operation generate the regions themselves (segmentation), or attach an inclusion-exclusion claim to a resource against regions that already exist (spatial coverage)?
Data quality / completeness within the region. A distinct claim the declaration does not make: coverage asserts the resource is in scope for a region, never that it is dense, accurate, or complete there (the entry's T3). A passed intersection test warrants applicability, not usable signal. Tell: does the decision need the resource merely to apply to the region (spatial coverage), or to have adequate density and accuracy inside it (data quality — which nothing here checks)?
The spatial join / geometric overlay operation. The analysis-stage computation that intersects two datasets' features. Spatial coverage licenses a catalog-layer metadata check — does the query's scope intersect the resource's declared coverage, run before any analysis — not the geometric join itself. Tell: is it a pre-analysis metadata gate deciding whether resources can even contribute (spatial coverage), or the actual feature-level geometric operation computing overlaps (spatial join)?
The boundary-via-metadata parent and the general applicability_scope mechanic (umbrella). The substrate-neutral pattern spatial coverage instantiates — publishing an inclusion-exclusion boundary along a chosen dimension via metadata/documentation. This is the genuinely cross-cutting content; spatial coverage is one dimensional facet of it, keyed to geography and encoded as dct:spatial/spatialCoverage. Tell: is the concern the general publish-a-boundary-on-applicability pattern that recurs across dimensions and fields (parent/umbrella, treated more fully in the transfer sections), or specifically geographic validity in a catalog (this slot)?

Neighborhood in Abstraction Space¶

Spatial coverage sits in a sparse region of the domain-specific corpus (64^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12