Locator Scheme Registry | ACDP Registry

ACDP data_refs[].location accepts two forms (RFC-ACDP-0002 §6.2):

A URI string conforming to a registered URI scheme.
A structured locator object with a dotted-namespace scheme field.

This registry tracks commonly used dotted-namespace schemes for the structured form. ACDP does not maintain an exhaustive registry — producers using novel schemes SHOULD prefix the scheme with their organization or domain.

Common URI-form schemes (informational)

These are standard internet URI schemes and require no ACDP registration:

Scheme	Use
`https`, `http`	Web fetch.
`s3`	Amazon S3 / S3-compatible object stores.
`gs`	Google Cloud Storage.
`azure`	Azure Blob Storage (informal).
`file`	Local file path.
`postgres`, `mysql`, `mongodb`	Database row reference (producer-defined query semantics).
`kafka`	Kafka topic reference (informal).
`ipfs`	IPFS content identifier.

Structured locator schemes

Scheme	Status	Required fields	Optional fields	Description
`kafka.offset`	Stable	`broker`, `topic`, `partition`, `offset` (or `offset_start`/`offset_end` for ranges)	`consumer_group`, `key`	A specific offset or offset range in a Kafka topic partition.
`db.row`	Provisional	`system`, `database`, `table`, `key`	`column`, `tx_id`	A specific row in a database.
`ipfs.cid`	Provisional	`cid`	`gateway`, `path`	An IPFS content identifier.
`vendor.handle`	Provisional	`vendor`, `handle`	`version`	An opaque handle in a vendor system.

Adding a scheme

Open a PR adding a row to the table above. Schemes MUST:

Use dotted-namespace form (<namespace>.<resource> minimum).
Document required fields (the scheme field is always required by acdp-data-ref.schema.json).
Document optional fields and their semantics.
Not collide with an existing scheme.

New schemes are added at status Provisional.

Producers using non-registered schemes SHOULD use a reverse-domain prefix (com.example.feature) to avoid collisions.

Promotion from Provisional to Stable

A Provisional scheme MAY be promoted to Stable via PR when all of the following are true:

The scheme has at least two independent producer implementations — different codebases AND different operating organizations. A fork of an existing implementation does not count as a second implementation; a vendor-internal reuse of the same codebase across teams does not count as a second organization.
The required-fields list and required-field semantics have not changed in the preceding 90 days. Adding optional fields during the 90-day window does NOT reset the clock; changing or renaming a required field DOES reset the clock.
At least one ACDP context using the scheme has been published to a public, live registry that conforms to acdp-registry-core (the published context proves the scheme works end-to-end through the publish + retrieval path, not just on a producer's local schema).

To request promotion, open a PR that:

Cites the two implementations (links to their public source or their agent_id DID document).
Links to the published context (ctx_id URL).
Updates the row's status from Provisional to Stable.

Promotion is a registry-policy change only; it does NOT alter the on-wire schema. Renaming or removing a Stable scheme is forbidden — Stable MUST mean "consumers can rely on this scheme indefinitely".

Examples

Kafka offset range:

"location": {
  "scheme": "kafka.offset",
  "broker": "kafka.prod.example.com:9092",
  "topic": "service-metrics",
  "partition": 7,
  "offset_start": 8421005,
  "offset_end": 8421847
}

Database row:

"location": {
  "scheme": "db.row",
  "system": "postgres",
  "database": "analytics",
  "table": "sentiment_analysis",
  "key": "12345"
}

IPFS:

"location": {
  "scheme": "ipfs.cid",
  "cid": "bafybeibcz3of6ywmlmjbe7w2a2dk7p4g5dfiu3aqwafs5rfaaj7kf72kpa"
}