Access URL¶

Reach a resource through a published, dereferenceable handle that names a route rather than the bytes — so location, storage, and hosting stay hidden behind a routing layer and identity can outlive the link.

Core Idea¶

An access endpoint is a published, dereferenceable handle — a URL, an API path, a connection string, a SPARQL endpoint — through which a client that knows the handle can retrieve or invoke a specific resource right now, without knowing anything about where or how that resource is stored.

The structural commitment is a separation of identity from location. The handle names a route, not the resource itself; the same logical resource can be published at a new endpoint without its identity changing, and the same endpoint can route to a different backing resource if the service is updated. Within open-data publishing, the W3C Data Catalog Vocabulary encodes this as the distinction between dcat:accessURL (where to reach the resource) and the dataset identifier (what the resource is): the two can vary independently. A dataset whose identifier persists across hosting migrations has a stable identity; its access endpoint is a current-time retrieval fact, not a permanent property.

The pattern has four constitutive roles. The published resource is a logical artifact with a stable catalog identity. The dereferenceable handle is the URL or equivalent that clients hold and invoke. The routing layer is the infrastructure that maps that handle to the current backing storage or service — CDN, reverse proxy, database connection pool, or API gateway. The protocol contract is the specification of how the handle is invoked — HTTP GET, SPARQL query, OGC GetCapabilities, JDBC connect string — and what the client can expect in return.

The pattern hides the resource's location, storage layout, and hosting details from clients. A client needs only the handle and the protocol contract; relocation, mirroring, and CDN fan-out are managed by the routing layer without the client's involvement. This also cleanly separates two failure modes that look similar on the surface but have different remediations: a broken endpoint (the routing layer has failed or the handle is stale) versus a corrupt resource (the backing data is wrong). You cannot diagnose the difference without the conceptual split.

In data publishing practice, a municipal government releasing its property-tax dataset might publish three access endpoints for the same logical dataset: a CSV download URL, a JSON API path accepting query parameters, and a SPARQL endpoint for federated queries. Each endpoint is a different protocol contract to the same underlying resource; all three are registered in the catalog alongside the dataset identifier that persists across endpoint changes.

Structural Signature¶

Sig role-phrases:

the published resource — a logical artifact with a stable catalog identity, the thing a client ultimately wants
the dereferenceable handle — the URL, API path, connection string, or SPARQL endpoint that clients hold and invoke
the routing layer — the CDN, reverse proxy, connection pool, or API gateway that maps the handle to current backing storage
the protocol contract — the specification of how the handle is invoked (HTTP GET, SPARQL query, JDBC connect) and what the client gets back
the identity-from-location separation — the handle names a route, not the resource, so identifier and access route vary independently
the location-hiding guarantee — relocation, mirroring, and CDN fan-out happen inside the routing layer with zero client-side change
the failure-mode split — a broken endpoint (stale handle / failed route) is held distinct from a corrupt resource (wrong backing data)
the perishable-route limitation — an access route is a current-time retrieval fact, not a permanent property, and must not be cited as the resource's identity

What It Is Not¶

Not the resource it points to. The URL is not the dataset. The handle names a route to the bytes, not the bytes themselves, which is exactly why the same logical resource can be published at a new endpoint without its identity changing — and why an endpoint can be re-pointed to a different backing resource while its URL stays the same. Treating the handle as the resource is the conflation the identity-from-location split exists to prevent.
Not an identifier of the resource. An access endpoint retrieves; a persistent identifier (a DOI, a dcat:dataset identifier) names. The two carry different fields and vary independently: the identifier is a permanent property that survives an unbounded sequence of hosting migrations, while the endpoint is a current-time retrieval fact. Citation and federation bind to the identifier, never to the perishable route.
Not evidence the resource is gone when the link dies. A 404 says the route failed — a stale handle or a moved host — not that the dataset has been deleted. Because the endpoint is a current-time fact rather than an identity, neither its presence nor its absence is evidence about the resource's existence; concluding "the data is gone" from "the link is dead" is the standard error the concept rules out.
Not a provenance or traceability artifact. An endpoint records where a resource can be reached right now, not the chain of where it has been or who changed it. It is a perishable retrieval handle, not a historical record; the resource's lineage lives elsewhere and is untouched when the route is swapped.
Not one-to-one with a resource. A single logical dataset can carry several endpoints at once — a CSV download URL, a JSON API path, a SPARQL endpoint — each a distinct protocol contract over the same resource, with its own independently-varying availability, latency, and freshness. The endpoint is a property of a route, so mirror policy and authoritative-source designation attach per-route, not to the resource as a whole.

Scope of Application¶

The access endpoint lives across the addressable-resource subfields of data publishing and information architecture — wherever a digital resource is reached through a dereferenceable handle that resolves via a routing layer the client never sees; its reach is within that computing substrate (the non-digital address-indirection analogues — postal addresses, ported phone numbers, DNS-versus-IP — belong to the parent prime, the addressable handle, not here).

Open-data publishing — the home turf: DCAT distributions and data.gov-style catalogs expose a dcat:accessURL / dcat:downloadURL per dataset alongside the persistent dcat:dataset identifier, the field split that the identity-from-location separation formalizes.
Web APIs and API catalogs — OpenAPI-described services and Postman collections, where a base URL plus path template is the canonical handle, invoked under an HTTP protocol contract and routed through gateways and reverse proxies.
SPARQL and linked-data endpoints — federated-query services where the SPARQL endpoint is a dereferenceable handle to a graph, with relocation and mirroring hidden behind the routing layer.
Database and message-system handles — JDBC/ODBC connection strings, message-queue topics, and RPC stubs, each a handle naming a route to a backing service rather than the data, supporting the same broken-route-versus-corrupt-resource diagnostic.
Geospatial service endpoints — OGC GetCapabilities and tile/feature service URLs, where the protocol contract specifies how the handle is invoked and what the client receives.
Filesystem and storage routes — mount points and CDN download URLs, where the handle is invariant across re-hosting, mirroring, and CDN fan-out so conforming clients see no change when storage relocates.
Internal knowledge inventories — intranet resource pages, Confluence space links, and internal search indexes, where the published resource carries a stable catalog identity distinct from the perishable link that reaches it.

Clarity¶

Naming the access endpoint forces apart three things that catalog users and even publishers routinely run together: what a resource is, where it can be reached, and how it is invoked. The most common confusion is treating the URL as the dataset — so that when a download link 404s, people conclude the data is gone, when in fact only the routing fact has changed. The concept makes the cleaner statement available: an endpoint is a current-time retrieval handle, not an identity, so a dataset can keep its catalog identifier across hosting migrations, mirroring, and CDN changes while its endpoints come and go. A publisher can now ask the sharp question DCAT was built to express — which field carries persistent identity (dcat:dataset) and which carries the perishable route (dcat:accessURL)? — instead of conflating the two and breaking citation when the host moves.

The split also makes a diagnostic legible that is otherwise invisible. When retrieval fails, the endpoint concept distinguishes a broken endpoint — the routing layer has failed or the handle is stale, fixed by re-pointing or re-publishing — from a corrupt resource — the backing data is wrong, fixed at the source. These look identical to a client holding only a URL, and without the conceptual separation a maintainer cannot even locate the failure, let alone choose the remedy. Finally, the concept clarifies that one logical resource may carry several endpoints at once — a CSV URL, a JSON API path, a SPARQL endpoint — each a distinct protocol contract over the same dataset, which lets a catalog reason about mirror policy, freshness, and authoritative source as properties of the routes rather than of the resource itself.

Manages Complexity¶

A published resource sits behind a shifting, open-ended tangle of operational facts: which host serves it today, how it is mirrored, what the CDN fans out, where the bytes physically live, how the storage is laid out, which protocol a given client speaks. The access endpoint collapses that tangle for the client to two things it must hold — the dereferenceable handle and the protocol contract — and absorbs everything else into the routing layer, so relocation, mirroring, and re-hosting happen without any client-side change. For the catalog the compression runs the other way: instead of tracking a resource's full, churning hosting history, it tracks a small fixed set of roles per route — published resource, handle, routing layer, protocol contract — and reads availability, latency, freshness, and authoritative-source as properties of routes rather than of the resource. The same parameter split makes the qualitative diagnosis fall out directly: a retrieval failure resolves to either a broken endpoint (re-point or re-publish) or a corrupt resource (fix at source) by asking which role failed, where a client holding only a URL would face an undifferentiated outage. The move is from reasoning about a resource's entire material situation to reasoning about a handful of named slots per access route.

Abstract Reasoning¶

The identity-from-location split and the four-role decomposition license a tight set of inferences about reachability that a client holding only a URL cannot draw.

Diagnostic (localize a retrieval failure to a role). When a fetch fails, the concept turns an undifferentiated outage into a question with a decidable answer: which of the four roles failed? If the same handle, invoked under the same protocol contract, returns nothing or a 404, the inference points at the routing layer or a stale handle — the route has moved, not the resource. If the handle resolves and the protocol handshake succeeds but the bytes returned are wrong, malformed, or internally inconsistent, the inference points at the backing resource — the route is intact, the data is corrupt. The two present identically to a naive client, and the reasoning move is to condition on whether the handle dereferenced at all: dereference-then-bad-data implicates the resource; failure-to-dereference implicates the route. This is what makes the failure locatable before any fix is attempted.

Interventionist (the remedy follows from the localized role). Each diagnosis names its own intervention and predicts its effect. A broken route is repaired by re-pointing the routing layer or re-publishing the handle — and the prediction is that the logical resource's catalog identity is untouched, so every citation of the identifier stays valid while the perishable route is swapped underneath. A corrupt resource is repaired at the source, behind the routing layer — and the prediction is that the handle and protocol contract need no change at all, because the route was never the problem. The interventionist content is precisely the warning that applying a route-fix (re-host, re-mirror, new URL) to a data-corruption problem will not move the failure, and vice versa: the conceptual split predicts which class of fix can possibly work.

Interventionist (relocate without breaking clients). Because the handle names a route and not the resource, the concept licenses the inference that relocation, mirroring, and CDN fan-out can be performed entirely within the routing layer with zero client-side change — the client holds only handle plus protocol contract, both invariant across the move. The predicted effect of adding a mirror or migrating hosts is therefore no observable change to any conforming client, which is the property that makes hosting migration safe; a publisher reasons from "did I preserve the handle and the contract?" to "are existing clients unaffected?"

Boundary-drawing (route-fact versus identity-fact, and which field carries which). Before treating any string as load-bearing, the concept forces a classification: is this a current-time retrieval fact or a persistent identity? A dcat:accessURL is perishable — it may 404 tomorrow without the dataset having changed — so it must not be cited as the dataset's identity; the dcat:dataset identifier is persistent and is what citation and federation should bind to. The inference is that a dataset can survive an unbounded sequence of endpoint changes with its identity intact, and conversely that a live endpoint can be re-pointed to a different backing resource without its URL changing — so neither the handle's presence nor its absence is evidence about identity. Drawing this boundary is what prevents the standard error of concluding "the data is gone" from "the link is dead."

Predictive / order-of-events (citation and freshness as properties of routes). The split licenses reasoning about availability, latency, freshness, and authoritative-source as attributes of routes rather than of the resource: one logical dataset carrying a CSV URL, a JSON API path, and a SPARQL endpoint has three independently-varying reachability profiles, and the concept predicts that a mirror policy, a staleness window, or an authoritative-source designation attaches to a particular endpoint, not to the dataset as a whole. A maintainer therefore reasons about which route is authoritative and which is a possibly-stale mirror as a per-route fact, and can predict that improving one route's latency or freshness leaves the others — and the dataset's identity — unchanged.

Knowledge Transfer¶

Within data publishing and the broader information-architecture domain, the access-endpoint pattern transfers as mechanism, with its diagnostics and vocabulary intact. The identity-from-location split and the four-role decomposition (published resource, dereferenceable handle, routing layer, protocol contract) carry across the substrate family of addressable resources without translation: a SPARQL endpoint, a REST API base path plus path template, a JDBC/ODBC connection string, an OGC GetCapabilities service, a message-queue topic, an RPC stub, a filesystem mount point, and a CDN download URL are all the same mechanism — a handle that names a route, not the bytes, behind which relocation and mirroring happen invisibly. An engineer who internalizes the DCAT accessURL-versus-dataset distinction for open data reads the identical broken-route-versus-corrupt-resource diagnostic on a database connection string or a queue topic, and the "re-point the route, leave the identity untouched" intervention is literally the same move. These are co-instances, not analogies, because each genuinely separates a perishable route from a persistent identity and routes through an infrastructure layer the client never sees. The protocol contract differs (HTTP GET, SPARQL query, JDBC connect, AMQP subscribe), but the structure that makes the failure locatable and the migration safe is shared.

Beyond addressable-resource systems the honest reading is case (B): the lesson that travels is the parent prime — an addressable handle (a path / pointer / address: a routable name that is dereferenced rather than walked-to) — while the access-endpoint concept's own named cargo stays home-bound. The portable mechanism is the indirection itself: naming a thing by a handle that resolves through a layer, so the name can outlive the location. That recurs far outside data publishing — a postal address, a phone number ported between carriers, a person's name versus their current desk, a DNS name versus an IP — as genuine co-instances of address-indirection, none of them "like" an access URL by surface resemblance; they share the abstract dereference mechanism. But what does not travel out of the data-publishing/computing substrate is the concrete cargo: the DCAT field distinction (dcat:accessURL / dcat:downloadURL / dcat:dataset), the protocol-contract layer (HTTP, SPARQL, JDBC), the CDN/reverse-proxy/connection-pool routing machinery, and the dereference-then-bad-data versus failure-to-dereference diagnostic, which presupposes a digital fetch with a checkable handshake. The catalog-and-API apparatus is data-publishing and information-architecture furniture; it does not survive extraction to a postal system intact. So when the lesson is needed elsewhere, carry the addressable-handle prime — name-by-route, identity-separable-from-location — and not the data-portal-specific "access endpoint," whose machinery is a domain instance of that prime. Invoking "access endpoint" for a non-digital address borrows the shape and renames the parts while dropping the protocol/routing machinery that gives it its operational bite; that is analogy, and should be marked so (see Structural Core vs. Domain Accent).

Examples¶

Canonical¶

The defining construction is the W3C Data Catalog Vocabulary (DCAT) record for one dataset. A municipality publishes its property-tax roll as a single logical dataset with a persistent catalog identifier, and attaches three dcat:distribution entries to it: a CSV served at a dcat:downloadURL, a JSON query service at a dcat:accessURL, and a SPARQL endpoint at another dcat:accessURL. The dataset node answers what the resource is; each distribution's URL answers where and how to reach it right now. In DCAT these are separate fields by design, so the publisher can migrate the CSV to a new CDN host, changing its downloadURL, without touching the dataset identifier that citations bind to. If a client's fetch of the CSV 404s while the JSON service still answers, the failure is localized to one route, not the dataset — exactly the split the vocabulary was built to express.

Mapped back: The property-tax roll is the published resource with a stable identity; each accessURL/downloadURL is the dereferenceable handle; the CSV-vs-JSON-vs-SPARQL specifications are three distinct protocol contracts over one resource. Keeping the dataset identifier fixed while a downloadURL changes is the identity-from-location separation, and diagnosing a single-route 404 without condemning the dataset is the failure-mode split.

Applied / In Practice¶

The Zenodo research-data repository operates this pattern at scale for reproducible science. When a researcher deposits a dataset, Zenodo mints a DOI that resolves to the record — a persistent identity meant to be cited in papers for decades. The actual bytes are served from file access URLs under that record, delivered through the repository's storage and delivery infrastructure. Over the archive's lifetime the backing storage, mirrors, and delivery paths can change without the DOI changing, so a paper citing the DOI still resolves even after the files have physically relocated. If a download stalls, an operator distinguishes a delivery-route failure (re-point or re-serve, DOI untouched) from a corrupted deposit (fix at the source record), because the two have different remedies and would otherwise look identical to a user holding only a file URL.

Mapped back: The deposited dataset is the published resource; its DOI is a persistent identifier while the file URLs are the dereferenceable handles. The repository's storage-and-delivery infrastructure is the routing layer, and its ability to relocate bytes without breaking cited DOIs is the location-hiding guarantee. Separating a stalled download (broken route) from a corrupted deposit (bad backing data) is the failure-mode split, and treating file URLs as current-time facts rather than citable identity is the perishable-route limitation.

Structural Tensions¶

T1: Location-hiding convenience versus route-fragility risk (the indirection that both frees and exposes). The routing layer's whole virtue is that clients hold only a handle and a protocol contract while relocation, mirroring, and CDN fan-out happen invisibly — a publisher can migrate hosts with zero client-side change. But the same indirection that lets the location move freely is exactly what makes the route a perishable, current-time fact: the handle can 404 tomorrow though the resource is untouched, and the client, insulated from location, has no way to tell a moved route from a deleted resource. Convenience for the publisher (move anything, break nothing) is bought with fragility for the citer (the thing you cited may stop resolving without the thing itself changing). The abstraction that hides location also hides why a fetch failed. Diagnostic: Is the handle being relied on as a stable citation, when its whole design makes it a route that can be re-pointed out from under you?

T2: Handle-as-identity versus handle-as-route (the conflation the concept exists to forbid). The natural user reflex is to treat the URL as the dataset — cite the link, bookmark the endpoint, equate presence-of-handle with existence-of-resource. The identity-from-location split forbids exactly this: the handle names a route, so it must never be cited as identity, and neither its presence nor its absence is evidence about the resource. Yet the pull toward conflation is relentless because in the common case the handle is stable and does resolve, so it functions as a de facto identifier right up until the host moves and citations break. The tension is that the concept's central discipline runs against the path of least resistance: the handle is usable as identity nearly always, and catastrophically wrong as identity exactly when it matters. Diagnostic: When this string is written down for the long term, is it the persistent identifier (dcat:dataset, a DOI) or the perishable route (dcat:accessURL) — and does its use match?

T3: Failure-mode split value versus the diagnosis it demands (locatability is not free). Separating a broken endpoint from a corrupt resource is the concept's sharpest payoff — the two look identical to a client holding only a URL, and the remedies are opposite (re-point the route versus fix the source). But the split only pays off if someone can perform the conditioning move: did the handle dereference at all? Failure-to-dereference implicates the route; dereference-then-bad-data implicates the resource. That test requires access to the handshake and the returned bytes, which the naive client lacks — so the very audience that most needs the diagnosis (a downstream consumer facing an outage) is often the one least able to run it, while the operator who can run it may not see the client's failure. The locatability is real but asymmetrically available. Diagnostic: Can whoever is diagnosing this outage actually observe whether the handle dereferenced — or are they inferring resource-death from a route they cannot inspect?

T4: One resource, many routes versus per-route reasoning burden (multiplicity that helps and complicates). Letting one logical dataset carry a CSV URL, a JSON API path, and a SPARQL endpoint at once is a genuine strength: each is a distinct protocol contract, and availability, latency, freshness, and authoritative-source become per-route properties a catalog can reason about independently. But that same multiplicity means there is no longer a single answer to "is the dataset fresh / available / authoritative?" — those are now route-scoped facts that can disagree, so one endpoint can be a stale mirror while another is live, and a consumer must know which route it holds to know what it has. The move from resource-level to route-level attributes buys precise mirror and freshness policy at the cost of dissolving simple resource-wide guarantees into a matrix of per-route ones. Diagnostic: Is freshness, authority, or availability being asserted of the dataset as a whole, when it is actually a property of one particular route among several?

T5: Autonomy versus reduction (a data-publishing endpoint or the domain instance of the addressable handle). "Access endpoint" is a specific data-publishing construct, complete with its DCAT field distinctions (dcat:accessURL / dcat:downloadURL / dcat:dataset), its protocol-contract layer (HTTP, SPARQL, JDBC), and its CDN/reverse-proxy/connection-pool routing machinery — and within the addressable-resource substrate it travels intact as mechanism across APIs, connection strings, queue topics, and mount points, which are co-instances rather than analogies. But its portable core is the parent prime, the addressable handle: naming a thing by a route that is dereferenced rather than walked-to, so identity can outlive location. That indirection recurs far outside computing — postal addresses, ported phone numbers, DNS-versus-IP — as genuine co-instances that share the dereference structure while carrying none of the protocol/routing cargo. What does not survive extraction is exactly the machinery that gives "access endpoint" its operational bite: the digital handshake presupposed by the failure-mode split, the catalog field distinctions, the CDN apparatus. Diagnostic: Resolve toward the parent (the addressable handle, identity-separable-from-location) when carrying the lesson to a non-digital address; toward the access-endpoint machinery when diagnosing an actual digital resource's reachability.

Structural–Framed Character¶

The access endpoint sits at mixed — evaluatively inert and transferring as literal mechanism across a wide computing substrate, yet constituted by engineered routing infrastructure and pinned to data-publishing vocabulary, so it cannot sit as far toward the structural end as a mechanism that runs observer-free in physical nature. Evaluative_weight points structural: an endpoint is a plain retrieval fact and renders no verdict; even its failure-mode split is a neutral diagnostic (broken route vs. corrupt resource), not a normative judgment. Human_practice_bound points framed and holds it back: there is no access endpoint in nature — it exists only where a routing layer, a protocol contract, and a catalog have been engineered, and it dissolves entirely if that computing practice is removed. Institutional_origin points framed toward a technical tradition rather than an agency or survey: the DCAT field distinctions (dcat:accessURL / dcat:downloadURL / dcat:dataset), the W3C vocabulary, and the HTTP/SPARQL/JDBC contracts are furniture of data-publishing standards. Vocab_travels is domain-pinned — routing layer, protocol contract, CDN, connection pool carry their content only inside computing. Import_vs_recognize is the strongest structural signal and why it clears the domain-specific bar: within the addressable-resource substrate family (REST APIs, connection strings, queue topics, mount points, OGC services) the transfer is literal recognition of the same mechanism — co-instances, not analogies, because each genuinely separates a perishable route from a persistent identity behind an unseen layer; only beyond computing (a postal address, a ported phone number) does it lapse into analogy.

The portable structural skeleton is address indirection — naming a thing by a dereferenceable handle that resolves through a layer, so identity can outlive location. That skeleton is substrate-general, but it is exactly what the access endpoint instantiates from its umbrella prime path (the addressable handle: a routable name dereferenced rather than walked-to), not what makes "access endpoint" itself travel: the cross-domain reach — postal addresses, DNS-versus-IP, ported numbers — belongs to that addressable-handle prime, while the endpoint's own cargo (the DCAT field split, the protocol-contract layer, the CDN/reverse-proxy routing machinery, and the digital dereference-handshake the failure-mode diagnostic presupposes) stays home in data publishing. Its character: an evaluatively-inert data-publishing construct that transfers by literal recognition across the whole addressable-resource substrate, but is constituted by engineered routing infrastructure and pinned to catalog-and-protocol vocabulary, so only the bare address-indirection skeleton it instantiates from path lifts beyond computing.

Structural Core vs. Domain Accent¶

This section decides why the access endpoint is a domain-specific abstraction and not a prime — a case where the concept travels literally across a broad computing substrate yet still carries a payload that stops at the edge of that substrate.

What is skeletal (could lift toward a cross-domain prime). Strip the data-publishing machinery and a thin relational form survives: a thing is named by a dereferenceable handle that resolves through an indirection layer, so identity can outlive location. The pieces that travel are abstract — a persistent identity, a routable name that points at the thing rather than being it, a resolution step that maps the name to a current location, and the consequent separability of what-a-thing-is from where-it-is-reached-now. That skeleton is genuinely substrate-portable — a postal address, a phone number ported between carriers, a person's name versus their current desk, a DNS name versus an IP all share it as address-indirection co-instances — which is exactly why the endpoint reads as an instance of the addressable-handle prime path (a routable name dereferenced rather than walked-to). But it is the bare core the endpoint shares, not what makes "access endpoint" the operationally sharp thing data publishing names.

What is domain-bound. Almost all the content is data-publishing and computing-infrastructure furniture and none of it survives extraction. The DCAT field distinctions (dcat:accessURL / dcat:downloadURL / dcat:dataset) are catalog-standard furniture; the protocol contract layer (HTTP GET, SPARQL query, JDBC connect, OGC GetCapabilities) presupposes engineered digital services; the routing layer (CDN, reverse proxy, connection pool, API gateway) is concrete network machinery; and the failure-mode split — broken route versus corrupt resource, conditioned on whether the handle dereferenced at all — presupposes a digital fetch with a checkable handshake and returned bytes. These are the worked vocabulary, the instruments, and the empirical cases (the DCAT property-tax record with three distributions, Zenodo's DOI-over-file-URLs), and they are specific to the computing substrate. The decisive test: remove the protocol/routing machinery and the digital handshake — carry the idea to a postal address or a ported phone number — and it is no longer an access endpoint but a looser instance of address-indirection; the operational bite that earns the name (the locatable failure diagnosis, the catalog field split) has fallen away.

Why this does not clear the prime bar. A prime's vocabulary travels and its transfer is recognition of the same mechanism, not analogy. The access endpoint's transfer is bimodal, with the seam falling at the edge of the computing substrate rather than at one narrow domain. Within the addressable-resource substrate — REST APIs, SPARQL endpoints, JDBC connection strings, queue topics, RPC stubs, OGC services, mount points, CDN URLs — it travels as full mechanism, because these genuinely separate a perishable route from a persistent identity behind an unseen layer and share the same broken-route-versus-corrupt-resource diagnostic; these are co-instances, not analogies. Beyond computing the named concept moves only by analogy: a postal address or ported phone number shares the dereference structure but has no protocol contract, no CDN, no digital handshake, so "access endpoint" there borrows the shape and renames the parts while dropping the machinery. And when the bare name-by-route lesson genuinely is wanted cross-domain, it is already carried, in more general form, by the prime the endpoint instantiates — path, the addressable handle whose identity is separable from location, is what governs address-indirection wherever no routing infrastructure exists. The cross-domain reach belongs to that parent; "access endpoint," as named, carries the DCAT-and-protocol baggage that should stay home in data publishing.

Relationships to Other Abstractions¶

Current abstraction Access URL Domain-specific

Parents (2) — more general patterns this builds on

Access URL is a kind of Indirection Prime

An access endpoint is indirection specialized to a perishable digital handle resolved through routing infrastructure under a protocol contract.
Access URL is a decomposition of Interface Prime

Removing data-publishing machinery from an access endpoint leaves a stable, rule-governed exchange surface that hides the provider behind a contract.

Children (3) — more specific cases that build on this

Data Access Service Domain-specific presupposes Access URL

A cataloged data access service presupposes an access endpoint because its typed record must name the live route and invocation contract it describes.
Distribution Form Domain-specific presupposes, typical Access URL

A network-published distribution typically presupposes an access endpoint carrying the fetch route, while offline or physically delivered forms do not.
Linked Open Data Release Domain-specific is part of Access URL

A linked-open-data release contains access endpoints for URI dereferencing and query-at-scale access as one constitutive access-infrastructure layer.

Hierarchy paths (4) — routes to 4 parentless roots

Access URL → Indirection → Layering

Show alternative paths (3)

Not to Be Confused With¶

Persistent identifier (DOI, dcat:dataset identifier). A name that identifies a resource permanently, meant to be cited and bound to for decades and to survive an unbounded sequence of hosting migrations. The access endpoint retrieves; the identifier names — the two are separate DCAT fields that vary independently, and the whole identity-from-location split turns on not conflating them. Tell: does the string survive the resource moving hosts and remain a valid citation (persistent identifier), or is it a current-time route that may 404 tomorrow without the resource changing (access endpoint)?
URN vs URL (and the URI umbrella). In web-standards vocabulary a URI splits into a locator (URL — how/where to reach the thing) and a name (URN — what the thing is, independent of location). The access endpoint is the locator half; the identifier is the name half. This is the same identity-versus-location distinction expressed in generic web-architecture terms rather than DCAT ones. Tell: is the string a routable locator you dereference to get bytes (URL / access endpoint), or a location-independent name that identifies without saying where to fetch (URN)?
PURL / persistent URL / DOI resolver redirect. A handle deliberately engineered with an extra indirection layer (a resolver that redirects to the current location) so that it behaves more like a stable identity. It is still a route — but one whose routing layer is owned by a resolver service precisely to make re-pointing invisible and citation-safe. The confusion is treating a persistent-URL scheme as if it collapsed the identity/route distinction; it does not, it just relocates the routing layer to a resolver. Tell: is stability achieved because the string is a permanent identifier, or because a resolver service silently re-points a route that is still, underneath, an access endpoint?
DNS name vs IP address. The network-layer indirection in which a hostname resolves to a current IP. This is a genuine co-instance of the parent addressable-handle prime (path) — address-indirection at the naming layer — but not a data-publishing access endpoint: it carries none of the DCAT field split, the protocol-contract layer, the CDN/gateway routing machinery, or the dereference-then-bad-data failure diagnostic. Tell: is the indirection resolving a network name to an address (DNS, the bare address-indirection prime), or reaching a catalogued resource through a protocol-specified handle with a broken-route-versus-corrupt-resource diagnostic (access endpoint)?
Provenance / traceability record. A historical artifact recording where a resource has been and who changed it — its lineage over time. The access endpoint records only where the resource can be reached right now; it is a perishable retrieval handle, not a historical chain, and is untouched when the route is swapped. Tell: does the artifact answer "what is this resource's history and custody chain" (provenance), or "how do I fetch it at this moment" (access endpoint)?
The addressable-handle prime (path) — umbrella. The substrate-general pattern — naming a thing by a dereferenceable handle that resolves through a layer, so identity can outlive location — that the access endpoint instantiates with data-publishing specifics. This is the umbrella, not a confusable peer: it is what carries the lesson to postal addresses, ported phone numbers, and DNS-versus-IP where no routing infrastructure exists. Tell: strip away the DCAT field split, the protocol contract, and the digital handshake and what remains is bare address-indirection — at which point the work is done by this prime, not by "access endpoint." Treated fully in the Knowledge Transfer and Structural Core sections.

Neighborhood in Abstraction Space¶

Access URL sits in a sparse region of the domain-specific corpus (79^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