Crossref: addressable objects

Addressable object kinds

The identity of an object is crossref:<kind>:<canonical native identifier>. It is the provider’s own identifier inside the provider’s own namespace. It is never derived from a title, a hostname, an address, or a string match, and it is not a Counterpedia identity.

• Crossref work

  Native identifier

  DOI

  Accepted form

  a bare DOI name: the prefix 10.<digits>[.<digits>...], a slash, and a non-empty suffix with no whitespace or control characters

  Canonical spelling

  ASCII letters A-Z are lower-cased, because DOI names that differ only in ASCII letter case are equivalent. No other normalization is applied, so non-ASCII letters keep their case.

  Route

  /providers/crossref/objects/work/<canonical native identifier>

  • Only a bare DOI is accepted. A doi.org link or a prefixed form is an address spelling, and is refused rather than parsed.
  • Whether Crossref, rather than another DOI registration agency, registers a given DOI is not checked.
  Identifier shape taken from provider documentation:

  • https://www.doi.org/doi-handbook/DOIHandbook_2025.pdf

Implemented by Counterpedia’s adapter

Two separate lists from two separate artifacts. What a service offers is not what an adapter implements, and neither list is derived from the other.

What the service offers (provider capabilities)

• Native-ID resolution
• Metadata lookup

From the pinned inventory. It describes the service, not any adapter.

What the landed adapter declares (implemented capabilities)

• Search
• Native-ID resolution

Landed adapter, manifest pinned

• Offered by the service, not declared by the adapter: Metadata lookup.
• Declared by the adapter, not listed for the service in the inventory: Search. The two lists come from different artifacts and are not required to agree.

Adapter manifest (canonical sha256)

sha256:6bd7bfefce33d139a654e6f81a91223da1acdb541abe8befdf78e0edc33ada30

The capability set the landed adapter itself declares, taken from its manifest as pinned at the same snapshot as the inventory. It states what the adapter declares, not that any call has run, succeeded, or returned anything.

Six distinct object families

These are different kinds of thing with different owners. None is an alias of, or a step toward, another; moving from one to the next is a separate act with its own record.

1. Provider — owned by the pinned provider inventory.
   An external service that can help discover sources. Not: A source, and not any object the service holds.
2. Provider object — owned by the provider (its own native identifier).
   One object in a provider's own system, named by the provider's native identifier within that provider's namespace. Not: A Source Record. It carries no Counterpedia source identity and is not evidence, support, or admitted.
3. Discovery observation — owned by Source Intelligence (a sealed record of one provider call).
   What a provider reported at a stated time for one query. Not: A finding that the reported thing exists or is as described, and not a capture.
4. Candidate locator — owned by Source Intelligence (descends from a discovery observation).
   An address a discovery observation turned up as a candidate. Not: Source identity, and not a reason to fetch, trust, or admit what it points at.
5. Captured artifact — owned by Acquisition (exact bytes, with a digest).
   Bytes that were actually retained from one locator at one time. Not: Admitted, supported, authentic, or current by being retained.
6. Source Record — owned by the Counterpedia Source Registry (governed).
   A governed Counterpedia record with its own source identity, capture posture, and admission. Not: Created by addressing, resolving, or listing anything here.