Why DCAT-AP metadata changes the open data portal build
A ministry, agency or city that must exchange catalog metadata with a national portal or the EU data catalog has a different build from one that only publishes files. The common self-hosted route is CKAN with the ckanext-dcat extension, which provides DCAT-AP v1, v2 and v3 schemas, DCAT RDF endpoints and an RDF harvester. The work, however, is decided by three things: which DCAT-AP version and national profile the receiving catalog expects, which national extensions add mandatory or recommended fields, and how the output is validated before it is pushed or harvested. Teams that treat these as details after the portal is live usually rebuild their dataset schema later, at a higher cost.
The difference from a generic portal is that the metadata itself is the deliverable. A standard CKAN installation can show datasets to people, but a DCAT-AP exchange is judged by machines and by reviewers who check each field against a profile. Dataset titles, publisher identifiers, licence values, temporal and spatial coverage and contact points must map from CKAN fields such as extras and custom schema keys into RDF properties that the receiving catalog reads without errors. Start by asking the national coordinator or the catalog operator for the exact profile version, the validation rules they apply and a sample of accepted records, then compare those against your current schema before any development begins.
DeployOpen prepares the field mapping, the harvest and endpoint configuration, the test records and the validation evidence that your team can review, but it does not issue any validation certificate or conformance statement. Those decisions belong to your organization and, where a national scheme applies, to the body that operates it. Confirm in writing who will run the final validation, which tool and rule set they will use, and how failures are logged and resolved within the agreed fixed scope.
Which metadata obligations shape the DCAT-AP build
This table maps the EU and open data obligations that affect a CKAN portal's DCAT-AP work to the parts of the build they touch: field mapping, RDF endpoints, harvesting and validation. Read each row as a question to settle with your legal team and the receiving catalog before the build starts. The main takeaway is that the target DCAT-AP version and national profile drive most of the mapping work, so confirm them first.
| Obligation | What it means for the build | What to confirm |
|---|---|---|
| Interoperable Europe Act (Regulation (EU) 2024/903) | Pushes public bodies toward reusable, interoperable data exchange, so the mapping should use published DCAT-AP terms rather than local field names for anything that leaves the portal. | Whether your body falls under the Act's interoperability obligations and which exchange partners expect DCAT-AP output. |
| NIS2 scope for public administration | Central government entities are covered regardless of size, and public administration is a high-criticality sector. Metadata endpoints and harvest jobs become part of the security scope, so logging, access limits and change control apply to them. | Whether your entity is covered directly or through a Member State extension, and which exemptions (such as national security or law enforcement) apply to any datasets. |
| Open data publication rules | Metadata must describe each dataset accurately enough for reuse, including license, publisher and update frequency. Missing or inconsistent values fail validation and reduce reuse, so required fields need controlled vocabularies. | The license codes and publisher identifiers your jurisdiction and the receiving catalog accept. |
| DCAT-AP version | Versions differ in classes, properties and constraints. The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas, so the version selected sets the mapping file and the validation rules. | Which DCAT-AP version the receiving catalog ingests, and whether it accepts older or newer output. |
| National profile | A national profile adds mandatory properties and vocabularies on top of DCAT-AP. Custom fields in CKAN must map to these additions, and they often differ from the base European profile. | The national profile in force, its mandatory fields and the validator the national catalog uses. |
| ckanext-dcat support on CKAN 2.10 and 2.11 | The extension is supported on these CKAN minor versions. Running it on another version means testing the RDF endpoints and harvester before go-live. | The CKAN version you plan to run and whether your extension version matches it. CKAN 2.12.0 is current, so plan the upgrade path. |
| RDF endpoints | The portal must serve dataset metadata in RDF that matches the chosen profile, so content negotiation and serialization formats need testing against real records. | Which serialization formats and endpoints the receiving catalog requests, and how often it polls them. |
| Harvesting in and out | Harvesting from other catalogs brings in records with their own identifiers and quality gaps. Harvesting out requires stable URIs so the receiving catalog does not create duplicates. | Whether the receiving catalog harvests on a schedule or by push, and how it handles updated or deleted records. |
| Validation of output | Validation confirms conformance before publication. Keep a repeatable test set so each change to the mapping or profile is checked against the same records. | The validator and rule set the receiving catalog applies, and who owns failures when records are rejected. |
Choosing a DCAT-AP version and national profile
When your portal feeds only a national catalog, the national operator's profile is usually the constraint that matters most. The national profile sits on top of a DCAT-AP version and often adds mandatory properties, controlled vocabularies or identifier rules. Your portal must produce what that catalog accepts, not the broadest version available. The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas, so the target version is a configuration decision that has to match the receiving side.
- Version the national catalog accepts: Ask which DCAT-AP version its harvester parses and whether it accepts newer schemas.
- National extensions: Identify any additional mandatory fields, vocabularies or code lists the national profile adds.
- Language and licence rules: Confirm required language tags and the licence vocabulary the catalog expects.
- Publisher and identifier conventions: Check how organizations, publishers and dataset identifiers must be expressed.
- Test harvest: Agree on a small sample of datasets the operator will harvest and validate before go-live.
Confirm the profile version and any national extension in writing with the receiving catalog's operator before mapping starts, because changing the target after mapping means rework across every dataset.
When your metadata goes to the EU open data catalog, the target is the DCAT-AP profile the EU portal ingests, which may differ from the version your national catalog uses. A portal that serves both national and European exchange often has to produce more than one serialization or profile from the same CKAN records. Plan for this split early, because the richer the source metadata, the easier it is to satisfy several targets from one set of fields.
- Confirm the EU ingestion version: Check with the EU catalog operator which DCAT-AP version and RDF serialization it harvests.
- Separate dual targets: Decide whether one RDF endpoint serves both profiles or whether each needs its own endpoint.
- Mandatory and recommended properties: Map the properties the EU profile requires before optional ones, and record gaps in source metadata.
- Controlled vocabularies: Use the EU authority tables for themes, formats and licences where the profile requires them.
- Version drift: Track when either side moves to a new DCAT-AP version, since a version change can alter how fields are read.
Before mapping, ask the EU catalog operator to confirm the version and any required vocabularies, and request a sample file that passes their validation.
A multi-country or regional network publishes to several catalogs, each with its own profile, and often hosts several CKAN instances that must stay consistent. The common mistake is to fix one version for the whole network without checking each member's receiving rules. A workable pattern keeps one canonical metadata model in CKAN and treats each national or regional profile as a documented output mapping with its own test set.
- Profile inventory: List every receiving catalog, its DCAT-AP version and any national extension it requires.
- Canonical model: Keep one internal field set and document how each profile maps from it.
- Per-target validation: Run each profile's validator against sample output, not only the default schema.
- Governance of changes: Name who approves a change in a national profile and how member portals are notified.
- Shared versus local extensions: Decide which extension fields are common to all members and which belong to a single country.
Request from each member operator a written statement of the profile version and extensions they accept, since a network-wide assumption will fail at the first member that differs.
How CKAN fields map to DCAT-AP properties
This sequence turns an existing CKAN catalog into DCAT-AP output that national and European catalogs can harvest without manual repair. Each step produces a reviewed artifact, so the mapping, vocabularies and configuration can be audited before any metadata leaves the portal.
Inventory CKAN fields and custom schema
Export the field list of every dataset and resource schema in use, including custom fields added by extensions or by departments. Record which fields are populated, which are free text, and which exist only in a local schema. The output is a field inventory with counts of populated values per field, reviewed by the portal owner and a metadata lead. You know it is done when every field in production appears once in the inventory with a named owner.
Map each field to DCAT-AP
Assign every CKAN field to a DCAT-AP class and property, such as dataset title to dct:title or license to dct:license, and mark fields with no equivalent as local extensions. Check the target against the DCAT-AP version and national profile your catalogs expect, because property cardinality and required fields differ between versions. The output is a signed-off mapping sheet listing source field, target property, transformation and mandatory status. Done means the data owner and the catalog maintainer have both approved it.
Define controlled vocabularies and identifiers
Fix the value lists that DCAT-AP expects, including licenses, file formats, themes and spatial or temporal references, and map local terms to those lists. Decide how datasets, publishers and contact points get persistent identifiers and stable URIs, since harvesters match records on them. The output is a vocabulary file and an identifier policy that developers implement and editors follow. Confirm the list sources and versions with the national profile authority before freezing them.
Document the custom schema
Where local fields have no DCAT-AP counterpart, define them in the CKAN schema with names, types, validation rules and an explanation of their purpose. Record which local fields are exported as extension properties and which stay internal. The output is a documented custom schema kept under version control alongside the mapping sheet. Done means a developer can rebuild the schema from the document alone and every field has a stated export decision.
Configure ckanext-dcat
Install and configure the ckanext-dcat extension on a staging instance matching your CKAN version, selecting the DCAT-AP schema version that matches the mapping sheet and enabling the RDF endpoints. Apply the field mappings and vocabulary rules through the extension's scheming and profile configuration, and keep the settings in code. The output is a staging portal with working RDF endpoints and a configuration record tied to the mapping sheet version. Confirm that the extension release supports your CKAN minor version before you start.
Test with a sample dataset set
Build a test set of representative datasets covering each resource type, optional fields, multilingual values, missing licenses and edge cases from the inventory. Export them as RDF, validate the output against the DCAT-AP shapes for the chosen version, and round-trip a sample through a harvester on a second catalog. The output is a test dataset set, a validation report with zero unresolved errors, and a log of harvest results. Done means the test set passes and the exceptions are recorded with owners.
Sign off and freeze the configuration
Present the mapping sheet, vocabulary file, custom schema, configuration record and validation report to the portal owner and the catalog maintainers for joint approval. Store the approved versions together and tag them, so any later change to a field or vocabulary is traced to a review. The output is a signed-off mapping release that governs production exports. Confirm with the receiving catalogs which DCAT-AP version and profile they accept before the release is tagged.
Which open-source options fit a DCAT-AP exchange portal
A DCAT-AP exchange portal needs a catalog that can publish and read structured dataset metadata, not just a website that lists files. The options below share one question: which platform gives you a metadata layer that maps to DCAT-AP, exposes RDF and harvests from other catalogs. Check each choice against the metadata profile your national or European catalog expects before you commit.
CKAN as the primary fit
CKAN is the open-source data management system built for data hubs and portals, and it is the platform this topic assumes. Pair it with the ckanext-dcat extension, which provides DCAT-AP v1, v2 and v3 schemas, DCAT RDF endpoints and an RDF harvester. The extension is supported on CKAN 2.10 and 2.11, so the CKAN version you deploy must match the extension's supported range. Confirm that before you pin versions.
Version choice against the extension
CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11 on the same day. Because ckanext-dcat is supported on CKAN 2.10 and 2.11, a deployment on 2.12.0 needs a written check that the extension version you plan to use supports it. If it does not, you choose between a supported pairing and waiting for compatibility. Ask your implementation partner to document the pairing in the scope.
Licensing and public catalog precedent
CKAN is licensed under the GNU Affero General Public License v3.0, so any modifications you run as a network service carry source-availability duties that your legal team should review. Public catalogs such as catalog.data.gov and open.canada.ca/data run on CKAN, which gives you working examples of DCAT-based publication to study. Confirm with counsel how AGPL obligations apply to your custom extensions before you build them.
General CMS and wiki options
A general content management system or wiki can publish dataset pages and file downloads, but it does not provide a metadata model that maps to DCAT-AP classes and properties. It also lacks native RDF endpoints and harvesting from other catalogs. For that reason this page does not present them as alternatives for an exchange portal. They may still front a CKAN instance as a public website, with CKAN holding the metadata.
Supporting components to plan
A CKAN deployment that publishes metadata depends on PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, Redis and Python 3.10 or newer, with uWSGI and Nginx recommended for production. Each component adds upgrade and patching work. Confirm with your partner which of these run as managed services inside your infrastructure and who owns their updates. Solr and Redis can run from Docker images tagged per CKAN version.
Release policy and upgrade planning
CKAN targets about two minor releases a year and supports the latest patch of the current minor version plus the previous minor version. Patch releases do not break backwards compatibility, but minor releases may include incompatible changes. Plan a test environment for each minor upgrade, and re-check the ckanext-dcat compatibility matrix before every move. Outdated patch releases lose support once a newer patch is out, so schedule patching as recurring work.
How to validate DCAT-AP output before it reaches other catalogs
How do I check that DCAT-AP output is valid against the schema version I chose?
Pick the DCAT-AP version your receiving catalogs expect, then validate the RDF your portal serves against that version's schema before any harvester sees it. The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas, so confirm which one your target catalog uses and configure the portal to match. Run validation on the RDF output of the DCAT endpoints for a representative set of datasets, including datasets with multiple resources, spatial values and multilingual titles, since these are where mappings usually fail. Record the validator version and the input set so the result can be repeated after changes. Ask your implementation partner to include this check in the written scope and to define what counts as a pass.
Which mandatory properties does my national DCAT-AP profile require?
The mandatory and recommended properties come from the national profile your ministry or national catalog publishes on top of DCAT-AP, not from the European base specification alone. Obtain the current profile document and its change history from the body that maintains it, then list every property it marks as mandatory and map each one to a CKAN field or extra. Check that each mandatory value is populated for every published dataset, and report datasets that fail rather than letting them pass silently. Confirm with the national coordinator whether controlled vocabularies, such as licence or format codes, must use specific URIs, because a valid string can still be rejected by a national catalog.
How do I run a sample harvest before the receiving catalog imports my datasets?
Arrange a test harvest with the receiving catalog's operator against a staging copy of your portal, not production. Agree in advance which datasets form the sample, which harvester settings the receiving side uses, and what result counts as acceptable, such as the number of datasets imported, skipped or rejected and the reason for each. The ckanext-dcat RDF harvester can also import from a catalog to test your own inbound mapping, so you can check round trips in both directions. Ask the receiving catalog to confirm whether it accepts the same DCAT-AP version and profile you publish, because harvesters often differ in how strictly they enforce them.
Do I need regression tests after a CKAN minor upgrade?
Yes. CKAN patch releases do not break backwards compatibility and exclude schema changes and new features, while minor releases may include backwards-incompatible changes, so a minor upgrade can alter the metadata your DCAT mapping produces. Before upgrading, keep a baseline of the RDF output for a fixed set of datasets, then rerun the schema validation, profile checks and sample harvest against the new version and compare the results. Plan this as a standing step in each upgrade cycle, because CKAN targets about two minor releases a year and only the latest patch of the current and previous minor versions receives security and bug fixes.
Who should own DCAT-AP validation: my team, a partner or the receiving catalog?
Ownership usually splits in three. Your team owns the decision on which profile and version to publish and the content quality of each dataset. A delivery partner can build and run the validation pipeline, write the mapping tests and document the results as part of a fixed-scope engagement. The receiving catalog owns acceptance of your output on its side. Put the responsibilities in writing before work starts, including who fixes a failing mapping, who approves a profile change and who reruns tests after a CKAN upgrade. Ongoing validation after go-live can be covered by a support retainer if you do not want an internal team to run it.
How long does DCAT-AP validation take to set up, and what changes the effort?
No duration is fixed here, and the effort depends on several factors you should confirm before asking for a quote. The main drivers are how many dataset types and custom fields you publish, how complete the existing metadata is, how many profiles or target catalogs you must satisfy, and whether the receiving catalog gives you a test environment and a named contact. Mapping work increases quickly when national profile rules and CKAN extras disagree. Ask a prospective partner to break the work into validation setup, mapping fixes, sample harvest rounds and upgrade regression steps, with each deliverable and acceptance check described in the written scope.
What evidence should I keep to show DCAT-AP output was validated?
Keep a dated record that ties each published DCAT-AP version to the validation run that approved it. A useful record includes the DCAT-AP version and national profile used, the validator and its version, the dataset sample, the pass and fail results with the reason for each failure, the receiving catalog's sample harvest outcome and the regression comparison after each CKAN upgrade. Store these records with your change management documents so auditors or oversight bodies can trace a published metadata field to a tested mapping. Confirm with your compliance lead which retention period applies, since that depends on your own legal and records rules.
Can my team validate DCAT-AP output without outside help?
Yes, if your team has staff who can work with RDF, CKAN extensions and your national profile, and if someone owns the upgrade cycle. Validation itself relies on open tools and the ckanext-dcat extension, so the cost is mostly internal staff time and the ongoing discipline of running tests after each change. Outside help makes sense when profile interpretation is contested, when mappings for custom CKAN fields are complex, or when you need the work documented for an assessment. DeployOpen plans, implements and documents self-hosted open-source platforms inside your infrastructure and can run validation as part of a fixed-scope engagement or a support retainer, but the decision on profile and publication remains with your organization.
Integration points and deployment pattern for metadata exchange
A DCAT-AP exchange portal is only as reliable as the components around CKAN that publish, harvest and authenticate metadata. The cards below cover the production stack, the DataStore's separate database, the RDF and harvest paths, and the identity layer, with the checks each one needs before go-live.
Production stack for CKAN
CKAN runs on PostgreSQL, Solr, Redis, uWSGI and Nginx. CKAN source installs require Python 3.10 or newer and PostgreSQL 12 or newer, and the install guide recommends Solr 9, with Solr 8 also supported. Confirm the exact versions against the CKAN release you choose, since CKAN 2.12.0 was released on August 26, 2026 and older minor releases lose support on their own schedule. Plan the Solr index, since search results and facet counts depend on it being rebuilt after metadata changes.
DataStore on a separate PostgreSQL
The DataStore keeps structured resource data in its own PostgreSQL database, separate from the CKAN metadata database. It uses a write user for loading and a read-only user for the Data API, so the public API cannot alter stored rows. Check that backups, restore tests and connection limits cover both databases. Large DCAT-AP exchanges describe resources, not their rows, so the DataStore matters mainly when a catalog also publishes tabular data through the API.
RDF endpoints and DCAT-AP schemas
The ckanext-dcat extension exposes DCAT RDF endpoints and supports DCAT-AP v1, v2 and v3 schemas. Choose the schema your national or European counterpart expects, because a catalog that validates against one version can still fail another. Test each endpoint with the serialization formats your recipients request, and confirm that exposed profiles match the national profile you have agreed to publish. Document which CKAN fields map to which DCAT properties so the mapping stays reviewable.
RDF harvester for inbound catalogs
The RDF harvester imports datasets from other DCAT catalogs into CKAN. Harvested records keep their source identifiers, so decide early how duplicates are matched and whether a harvested dataset can be edited locally. Schedule harvest jobs, log rejected records, and check that licence and publisher fields survive the import. Test with a sample from each source catalog, since differences in optional fields and vocabulary usage are where imports most often break.
National catalog connector
A national or European catalog connection is a set of agreed push or pull paths, credentials and validation rules, not just an endpoint. Confirm with the receiving catalog which DCAT-AP version, national profile, and identifier scheme it accepts, and whether it harvests from your RDF endpoint or expects a push. Keep a log of each exchange and a rollback path for records that fail validation. Ask the catalog operator for its test environment before go-live.
Staff identity with ckanext-saml2auth
Publishers and editors usually sign in through the agency's own identity provider, and ckanext-saml2auth is one community option for SAML-based single sign-on. Confirm that the extension supports your identity provider, attribute mapping and the CKAN version you run before committing to it. Keep API tokens separate from interactive sign-in, because harvesters and scripts need credentials that do not depend on a person's session. Agree who approves changes to role and organization mappings.
Evidence a reviewer asks for in a metadata exchange
This table maps each piece of evidence a reviewer typically asks for to the component that produces it and the question it answers. Read it as a checklist for planning: confirm early which artifacts your receiving catalog or auditor expects, and which ones your own team must keep current after go-live. DeployOpen prepares these artifacts for an independent auditor or the receiving catalog's operator, but does not issue reports or attestations.
| Evidence item | Produced by | Question it answers | Keep current when |
|---|---|---|---|
| Approved mapping specification | Field mapping document covering CKAN fields to DCAT-AP properties, agreed with the data owner | Which CKAN field feeds each DCAT-AP property, and which profile version applies | The DCAT-AP version, national profile or ckanext-dcat version changes |
| Validation reports | Validator runs against exported RDF from the DCAT RDF endpoints | Does each exported dataset conform to the agreed profile and mandatory properties | Datasets are added, or the mapping or extension changes |
| Sample RDF exports | DCAT RDF endpoints in the CKAN instance, captured for representative datasets | What a receiving catalog actually receives, in each serialization offered | Schema extensions, scheming fields or licence values change |
| Harvest logs | CKAN harvester jobs, including the RDF harvester for inbound catalogs | Which records were imported, updated, skipped or rejected, and why | Source catalogs change their feed format or harvest schedule changes |
| Outbound exchange records | Logs of what was published to or pulled by partner catalogs, with timestamps | Which versions of which records left the portal, and when | Publication workflow or receiving endpoint changes |
| Change records for CKAN upgrades | Upgrade tickets, release notes reviewed, test results on a staging copy | What changed in the software, what was tested, and who approved the rollout | Each CKAN patch or minor release, or ckanext-dcat update |
| Access control configuration for RDF endpoints | Web server and CKAN configuration, plus role settings for private or restricted datasets | Which records are public, which are restricted, and who can reach internal metadata | Roles, reverse proxy rules or dataset visibility policies change |
| Ownership and review evidence | Publishing workflow records in CKAN, including named data owners and approval steps | Who is accountable for each record's accuracy and licence | Staff roles change or a new department joins the portal |
Security baselines that apply when the catalog sits in government infrastructure
A public body hosting its own CKAN catalog should expect control expectations drawn from NIST SP 800-53 Rev. 5, usually passed down through a national or agency framework rather than written into the open data law itself. The control catalog is organized into low, moderate and high baselines defined in SP 800-53B, which select 149, 287 and 370 controls and enhancements respectively. The baseline is set by the impact level the agency assigns to the system, so the first decision is which level the catalog is assigned. A catalog that only publishes open datasets is usually a different impact case from one that also holds access-controlled or restricted resources, and the agency's security office should confirm that classification in writing before any control mapping starts. Reference the current release, Release 5.2.0 of 27 August 2025, when you ask which revision the agency applies.
FedRAMP is the point where many teams assume the scope lies, and it often does not. FedRAMP covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A self-hosted CKAN running in the agency's own cloud account or data center, used for that agency's operations and not offered as a shared service, is generally outside that scope. That position is a reading to test, not a conclusion to rely on. Ask the agency's security office whether the catalog, its Solr and PostgreSQL components, and any hosting provider fall inside the agency's authorization boundary, and whether a national or state framework applies in addition to federal rules. Record the answer, the controls selected and the owner who signed off, because auditors will ask for that decision trail.
Accessibility is the control area that reaches the public-facing pages of the catalog directly. The ADA Title II rule requires state and local government web content and mobile apps, including content provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. Compliance dates are 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. Dataset landing pages, the search interface and the API documentation are all in scope, and the DCAT RDF endpoints themselves are machine-readable rather than rendered pages. Confirm with the agency's counsel or accessibility lead which of the catalog's pages count as web content, and schedule an accessibility test on the CKAN theme before the applicable date.
Rollout from mapping to a validated exchange
The sequence moves a CKAN portal from an agreed metadata profile to a tested, monitored exchange with the catalogs it must feed and be fed by. Each phase closes with a written output that the agency signs off before the next one starts.
Confirm target catalogs and profile versions
Before any configuration, the agency identifies every catalog it must publish to or harvest from, and the DCAT-AP version and national profile each one expects. DeployOpen reviews the receiving catalogs' documentation with the agency's data team and records which profile version, mandatory properties and vocabularies apply. Confirm these with the receiving catalog's operator, because profiles change over time. The phase closes with a signed profile scope document listing each exchange partner, its profile version and its open questions.
Map CKAN fields to the profile
The team builds a field-by-field mapping from existing CKAN dataset fields, extras and resource attributes to DCAT-AP classes and properties. Gaps, such as missing publisher identifiers, licence codes or temporal coverage, are assigned to owners in the agency before anything is hard-coded. Where a national profile adds local properties, the team defines a custom schema extension in the ckanext-dcat configuration rather than editing core code. The output is a versioned mapping document and a list of metadata fields that publishers must now complete.
Configure RDF endpoints and harvesters
The team enables the DCAT RDF endpoints for the chosen profile and configures the RDF harvester for each inbound source. Serialization formats, endpoint paths and harvester schedules are set in the staging configuration under version control, with credentials kept outside the repository. Inbound harvests are first run against a sample source to check how identifiers, duplicates and deleted records are handled. The phase closes when a test harvest and a test RDF export both complete and the outputs match the mapping document.
Validate output against the profile
Exported RDF is checked with automated validation against the agreed profile's shapes and rules, and the results are reviewed by a data steward who can explain each failure. Failures are classified as mapping defects, missing source metadata or profile interpretation questions, and each class has a named owner. Validation runs again after every change to the mapping or the CKAN schema. The output is a validation report with zero open defects against mandatory properties and a list of accepted, documented deviations.
Test the exchange with the receiving catalog
The agency and the receiving catalog's operator run a joint test in staging. The receiving side harvests the agency's sample RDF, reports how it parses and maps each record, and the agency harvests a sample back. Both parties compare dataset counts, identifiers, licences and publisher data for a agreed set of test records. The phase ends with a written acceptance from each partner that the exchange works for the agreed records, with any remaining differences recorded as known issues.
Run a controlled production go-live
The mapping, endpoints and harvester schedules are promoted to production through the same change process used for other CKAN changes, with a rollback plan written beforehand. The first production harvests and exports are watched closely and compared with the staging results, and the receiving catalog confirms ingestion. Publishers are told which fields changed. The phase closes with a go-live record showing the versions deployed, the first successful exchange and the rollback steps that were not needed.
Hand over runbooks and monitoring
DeployOpen documents the mapping, the validation procedure, harvester operations and the process for profile updates, then trains the agency's operators on them. Monitoring covers failed harvests, validation drift after CKAN upgrades and changes announced by receiving catalogs. The agency decides who approves profile changes, who receives alerts and how often validation is repeated. The handover is complete when the agency's team runs a harvest and a validation without assistance and the runbooks are accepted in writing.
Questions to ask an implementation partner about DCAT-AP work
Start by asking which DCAT-AP versions and national profiles the partner has mapped in production, not in a demo. The supplied facts confirm that ckanext-dcat provides DCAT-AP v1, v2 and v3 schemas, but they do not say which national profiles the extension covers or how each one differs, so ask for the mapping specification for each profile you must meet. Ask the partner to show the field-level mapping for two or three of your real datasets, including how they handle mandatory properties that your source system does not hold, and whether any mapping was written for a national profile the partner has not delivered before. Confirm the version of ckanext-dcat they will pin and the CKAN versions it is tested against, since the extension is listed as supported on CKAN 2.10 and 2.11 only.
Next, ask how output is validated and against which schema. A good answer names the validator, the shapes or rules used, the exact DCAT-AP version and profile under test, and whether validation runs on every harvest, on every change to the mapping, or only at go-live. Ask who decides a validation failure is acceptable and how that decision is recorded. Then ask how the partner handles CKAN minor upgrades. CKAN targets about two minor releases a year, and minor releases may include backwards-incompatible changes, so ask for the regression test set, the staging environment used before an upgrade, and the rollback plan. The mapping specification and the test fixtures should be owned by your team after handover, and the contract should say so in writing.
Finally, ask how the fixed scope defines mapping and harvest counts. Request that the statement of work list the number of dataset types or templates to be mapped, the number of endpoints or external catalogs to harvest from or publish to, and what counts as a change request once work starts. Ask what support covers after go-live, specifically when your staff edit mappings, add extras or change the receiving catalog's requirements. Clarify who fixes an RDF endpoint that breaks because a downstream catalog changed its validation rules, and whether that work is inside the retainer or billed separately. Get the answers in writing before signing, because they determine who pays when the national catalog changes its profile.
What DCAT-AP work costs and what it needs from your team
What drives the cost of DCAT-AP metadata work on a CKAN portal?
The main drivers are the number of datasets to map, how many custom fields sit outside the standard schema, how many target catalogs you must serve, and how complex the national profile is. Each extra profile or catalog adds mapping rules, test cases and review rounds, while a clean set of standard fields with a few target catalogs is the simplest case. Because DeployOpen does not publish a price list, the quote follows from the written scope, so ask for each driver to be listed as a separate line with its assumptions stated. An illustrative case: a portal with one catalog and a clean field set costs far less to map than one with four catalogs and a dozen local extension fields.
Which DCAT-AP costs are one-time and which recur?
Most of the mapping, profile configuration, RDF endpoint setup, harvester configuration and validation tests are one-time costs of the initial build. Recurring costs come from keeping the work current: upgrading ckanext-dcat as CKAN moves to new minor releases, re-validating output after each profile change, and maintaining harvest jobs as neighboring catalogs change their own metadata. CKAN targets about two minor releases a year and supports only the latest patch of the current minor and the previous minor, so plan for upgrade work at least that often. Ask any partner to separate the one-time build from an ongoing support retainer in the quote.
Can our internal staff do the DCAT-AP field mapping themselves?
Yes, a team with CKAN and RDF knowledge can map fields internally, and many agencies start there. The mapping itself is manageable, but the hard parts are interpreting the DCAT-AP and national profile rules, deciding how local fields map to the standard, and testing RDF output against validators. Internal staff usually need a developer comfortable with Python, CKAN extensions and RDF, plus a steward who can answer what each field means. If your team lacks RDF experience, a partner can build the first mapping and hand over documentation and tests, which lowers the risk of silent errors in exported metadata.
How long does DCAT-AP work take when receiving catalogs must review it?
The schedule depends heavily on the receiving catalog's review cycle, which you do not control. Your own build can be planned in fixed phases, but a harvester or national catalog may need to test your endpoint, reject records, or ask for corrections before accepting them. Build time is therefore only part of the calendar. Ask the target catalog operator for its validation process, its intake dates and the format it expects before you commit to a go-live date, and agree in writing which party owns each review round. Any duration in a proposal should state these external dependencies as assumptions.
What does the work require from our data stewards?
Data stewards must confirm what each dataset means, which fields are mandatory in the target profile, and which licence, publisher and temporal values are correct for each record. They also decide how to handle gaps, such as datasets missing a theme or a contact point, and they approve the mapping rules before testing. Expect stewards to review sample outputs at each phase rather than only at the end. Agree a named steward for each organization on the portal and a decision log, because unresolved field meanings are the most common cause of rework.
Does DeployOpen issue a compliance certification for our DCAT-AP metadata?
No. DeployOpen prepares the systems, controls and evidence for compliance assessments, including DCAT-AP output that can be checked against the profile, but it does not issue audit reports, attestations or certifications. Validation results from your tests and the receiving catalog's acceptance are evidence you can present, while any formal assessment is carried out by the relevant independent body. Ask any partner to show which test results and configuration records it will hand over at the end of the engagement.
Is DCAT-AP work a fixed-scope engagement or an ongoing retainer?
The initial mapping and endpoint build is normally a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. Ongoing work such as profile updates, upgrades, continuous validation and new catalog connections is better handled as a retainer, because the number of changes is not known in advance. Ask for the fixed scope to name the datasets, profiles, catalogs and validation criteria covered, and for any retainer to state what triggers additional work. Changes to scope after signature should be priced through a written change request.
What should we ask a partner to include in a DCAT-AP quote?
Ask for a quote that lists the datasets in scope, the DCAT-AP version and any national profile, the number of target catalogs, the custom fields to map, and the validation method. Request the one-time build and recurring support as separate lines, and ask which items are assumptions about the receiving catalog's review. Also ask who performs the stewardship review, what handover documentation and tests you will receive, and how upgrades to ckanext-dcat and CKAN are handled. A quote that cannot state these assumptions in writing is harder to compare.
How DeployOpen scopes and supports DCAT-AP metadata work
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including CKAN portals. For DCAT-AP metadata, we start from the profiles your catalog must exchange with, then build and test the mapping, endpoints and harvesting against that written scope before handover.
How we scope
- Confirm which DCAT-AP version and national profile your catalog must publish and harvest against.
- List the source catalogs, target catalogs and harvest schedules that the written scope will cover.
- Agree in writing which ckanext-dcat mappings, custom fields and validation checks are in scope.
- Engagements are fixed-scope, so deliverables and timelines are defined before work starts.
How we build
- Configure the CKAN metadata schema and ckanext-dcat mappings from your agreed field inventory.
- Enable and test the RDF endpoints that expose dataset metadata to external harvesters.
- Set up RDF harvesting jobs and check imported records against the agreed mapping rules.
- Run validation of exported RDF against the chosen DCAT-AP profile and record the results.
How we hand over
- Document the mapping tables, endpoint URLs, harvest configurations and validation procedures for your team.
- Walk publishing staff through how metadata gaps are found, fixed and re-validated before harvest.
- Provide evidence of validation runs and configuration records for your compliance and audit files.
- Hand over the platform in your own infrastructure, with your team holding the administrative access.
How we support
- Ongoing support, upgrades and testing are available as a retainer after go-live.
- Review CKAN and ckanext-dcat upgrades against the mappings before they reach production.
- Revalidate output when a national profile or DCAT-AP version changes, within the retainer scope.
