Standards assumptions

Registry Relay publishes metadata that other systems can inspect. This document keeps the line clear between standards evidence that Registry Relay emits and interpretations that downstream consumers may derive from that evidence.

Scope

Registry Relay may publish:

• DCAT and DCAT-AP catalogue, dataset, distribution, and data service metadata.
• BRegDCAT-AP profile metadata where configured.
• SHACL, JSON Schema, and OGC API Records metadata derived from configured entities.
• CPSV public service evidence when a dataset manifest declares a related service.

Registry Relay does not publish a proprietary source-of-truth flag.

Facts, publication choices, and downstream hypotheses

Registry Relay publishes machine-readable metadata facts and descriptors. It does not publish downstream conclusions.

• Published fact: a configured metadata manifest declares a dataset, entity, field, service, profile, ODRL Offer, or standard predicate, and Registry Relay renders it into /metadata/*.
• Publication choice: Registry Relay chooses a practical standards-shaped representation for a registry concept, such as describing entity routes as dcat:Distribution plus dcat:DataService.
• Downstream hypothesis: another tool, such as Registry Atlas (the registry family’s dataspace catalogue project), derives a candidate route, candidate source, confidence level, or governance gap from those published facts.

Downstream hypotheses must not be written back into Registry Relay metadata as if they were original source facts.

Standard evidence Registry Relay emits

The following predicates are treated as standard-facing evidence:

• dcterms:publisher
• dcterms:rightsHolder
• dcterms:accessRights
• dcterms:accrualPeriodicity
• dcterms:conformsTo
• dcterms:spatial
• adms:status
• dcatap:applicableLegislation
• dcat:distribution
• dcat:accessService
• dcat:servesDataset
• odrl:hasPolicy
• odrl:Offer
• odrl:permission
• odrl:prohibition
• odrl:duty
• odrl:constraint
• cpsv:PublicService
• cpsv:produces

These signals are published so standards-aware clients can inspect the registry. They are not, by themselves, proof that access is legally approved, operationally ready, complete, or authoritative.

dcterms:conformsTo is profile or standard conformance evidence. Registry Relay may render small typed standard nodes for consumer convenience, but it does not mean the target IRI is a data resource to harvest as part of the registry.

dcat:Distribution and dcat:DataService identify declared access surfaces. They do not mean a caller is authorized, that a specific identifier lookup is supported, or that production integration has been reviewed.

Interpretation boundary

Registry Relay does not decide:

• whether a dataset is a system of record;
• whether a caller is legally allowed to use a dataset;
• whether a dataset is complete enough for a program decision;
• whether the dataset’s owner is the final authority for every field;
• whether a discovered access route is fit for production integration.

Those decisions belong to downstream governance, review, and discovery layers. For example, Registry Atlas may derive a candidate_source route from dcterms:publisher, dcatap:applicableLegislation, and cpsv:produces, but that role is an Atlas interpretation, not a Registry Relay predicate.

Registry Relay may publish enough evidence for a downstream tool to form that hypothesis, but Registry Relay itself only claims what is in the metadata: publisher, rights holder, applicable legislation, public service relation, policy offer, access service, and schema evidence.

ODRL policy assumptions

Registry Relay may publish ODRL policy metadata as discovery and governance evidence. Governed evidence-gateway routes may evaluate the supported PDP subset declared by registry-evidence-gateway-pdp/v1 before serving data. Registry Relay still does not create or negotiate accepted ODRL agreements, and ODRL Offers outside the supported PDP subset remain catalog evidence. Dataset-level policy output should therefore use odrl:Offer, not odrl:Agreement, unless a future feature explicitly models an accepted agreement from an external governance process.

Configured policy values should be IRI-first. Purposes, recipients, actions, operands, assigners, assignees, and units should be explicit IRIs or compact IRIs expanded from the metadata manifest vocabularies. Human-readable policy text can help reviewers, but it should not be the field that strict discovery depends on.

The demo policy blocks use hypothetical demo.example.gov IRIs and illustrative assigners such as did:web:education.demo.example.gov. They are examples for metadata consumers and must not be read as official law, binding terms, legal approval, or proof that a duty has been fulfilled.

Default policy output is intentionally minimal. A generated default odrl:Offer means “this dataset has a discoverable policy node.” It is not sufficient legal basis, and it should not remove policy review gaps in downstream tools unless more specific configured policy evidence is present.

See the ODRL policy metadata contract for the implemented shape.

DSP alignment

Registry Relay is not a Dataspace Protocol connector. It may publish DSP-relevant DCAT and ODRL evidence, such as dspace:participantId, dataset-level odrl:hasPolicy Offers, and dcat:DataService access metadata, but it does not implement DSP catalog request, contract negotiation, or transfer process endpoints.

For that reason Registry Relay should not emit Relay-specific dspace:dataServiceType values such as REST, OGC API, or SP DCI service names. The current renderers use standard DCAT and Dublin Core fields for Relay access services instead. DSP defines dspace:dataServiceType for Dataspace Protocol endpoints, with dspace:connector as the known connector type. Relay access services should be described through: dcat:endpointURL, dcat:endpointDescription, dcterms:conformsTo, and dcterms:format.

These signals are intended to make Registry Relay metadata useful to DSP-aware catalogues without acting as a DSP control plane. Implementing DSP catalog request, contract negotiation, and transfer processes would be a separate product surface.

Demo assumptions

The demo metadata intentionally gives stronger standard evidence to:

• farmer_registry, via applicable legislation and a CPSV farmer registration service that produces the farmer registry dataset, plus illustrative ODRL terms for agricultural-subsidy eligibility discovery.
• disability_registry, via applicable legislation and a CPSV disability registration service that produces the disability registry dataset, plus illustrative ODRL terms for disability-benefit eligibility discovery.
• education_registry, via illustrative ODRL terms for student-support planning discovery. This policy evidence is not source-of-truth evidence for disability registration.

The demo does not give the same source evidence to every dataset that happens to contain a related field. For example, education_registry.student may include a disability_status field, but that does not make the education registry the source for disability registration.

The demo datasets are hypothetical. They are not official OpenCRVS, OpenSPP, SP DCI, SEMIC, or PublicSchema profiles. Real project-specific profiles should be created from reviewed artifacts, not from the demo fixtures.

Endpoint publication assumptions

/metadata is the canonical discovery entry point for live Registry Relay instances. It links to scoped metadata artifacts such as:

• /metadata/catalog;
• /metadata/dcat;
• /metadata/dcat/{profile};
• /metadata/shacl;
• /metadata/policies;
• /metadata/datasets/{dataset_id}/policy;
• /metadata/schema/{dataset_id}/{entity}/schema.json.

Use /metadata/*; the former /catalog aliases were removed.

/metadata/policies is a collection of dataset-scoped policy documents. It is not one global policy for the whole deployment.

Version assumptions

The current metadata model is aligned with the DCAT-AP and BRegDCAT-AP profile family, and it uses CPSV evidence where that profile family already models public services.

SEMIC SHACL validation currently runs against BRegDCAT-AP 2.x shapes, while some Registry Relay demo manifests claim bregdcat-ap 3.0. Until BRegDCAT-AP 3.0 SHACL shapes are pinned, SEMIC validation should be treated as an advisory conformance check rather than the only release gate.

Validation assumptions

Registry Relay tests verify that configured metadata is rendered consistently and that the demo configs load. They do not replace external profile conformance validation.

Recommended validation layers:

• local unit and integration tests for deterministic rendering;
• golden fixtures for profile outputs;
• optional SEMIC SHACL validation for DCAT-AP and BRegDCAT-AP conformance;
• human review for legal basis, source-of-truth, and access governance claims.