How CKAN DCAT-AP publishing works with ckanext-dcat
A portal team that must expose its catalog to a national or European aggregator, and also pull records from other catalogs, needs one extension that handles both directions. ckanext-dcat is the supported extension for DCAT-AP v1, v2 and v3 schemas, DCAT RDF endpoints and an RDF harvester, and it is supported on CKAN 2.10 and 2.11. The publishing direction turns local CKAN datasets into DCAT-AP RDF that an aggregator can read. The consuming direction brings RDF records from other catalogs into CKAN as datasets. Both directions depend on the same schema decisions, so a choice made for one affects the other. The endpoint and harvester sections that follow cover the details.
On the publishing side, the extension maps CKAN dataset fields onto the DCAT-AP classes and properties for the schema version you select, then serves them through DCAT RDF endpoints. Your first decision is which DCAT-AP version the receiving aggregator validates against, since each version defines its own requirements. Ask the aggregator for its current validator and the version it accepts, and confirm that version is one ckanext-dcat implements. Next, audit your metadata. Properties that the chosen profile requires, such as publisher, license and contact details, must exist in CKAN fields or extras, or the output will fail validation even when the endpoint responds. Confirm the endpoint paths and serialization formats in the documentation for the version you deploy, then test them with the validator before the portal is listed.
The consuming side uses the RDF harvester to import records from other catalogs. It runs inside the harvesting framework, so each source is configured as a harvest source and each run is a harvest job. The queueing, gather, fetch and import stages and the scheduling of runs are covered in the CKAN harvesting topic. The decision that matters most here is the source itself. Confirm that the source publishes valid DCAT-AP RDF for the version you expect, and decide how incoming records map onto your own dataset fields. Plan for identifiers as well, because a source that changes its record URIs can cause re-harvests to create duplicate datasets. Test each new source against a staging copy of the portal before it runs on a schedule against production.
Version limits set the boundary for this work. The supported combination for ckanext-dcat is CKAN 2.10 and 2.11. CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11. CKAN supports the latest patch of the current minor version and the previous minor version, and older patch releases lose support once a newer patch is out. Before you choose a CKAN target, check the ckanext-dcat repository to confirm whether a release supports 2.12. Plan the upgrade so the extension version, the CKAN minor version and your DCAT-AP profile move together. Minor releases can include backwards-incompatible changes, so retest the RDF output after every upgrade.
CKAN DCAT-AP prerequisites and the CKAN version limit
A DCAT-AP deployment depends on a platform baseline, a production serving layer, and a ckanext-dcat support statement that stops at CKAN 2.11. The cards cover what to install, what to confirm before any upgrade to CKAN 2.12, and what the RDF harvester needs in place.
Python and PostgreSQL version floors
CKAN installed from source requires Python 3.10 or newer and PostgreSQL 12 or newer. Check these floors against the operating system packages on your build image before scheduling work, because distribution defaults are often older. PostgreSQL also hosts the DataStore, which uses a separate database with a write user and a read-only user, so capacity and roles should be planned for that database too. Confirm exact versions against the install documentation for your chosen CKAN release.
Production serving with uWSGI and Nginx
The install documentation recommends uWSGI and Nginx for production deployments. Nginx handles client connections and serves static assets, while uWSGI runs the CKAN application processes behind it. Decide early who owns TLS certificates, worker sizing and log rotation, and test this layer against the CKAN version you plan to run. Development server results from staging do not show how this layer behaves under production traffic.
Solr and Redis service choices
Solr 9 is the recommended search index, and Solr 8 is also a supported option, so choose one line and keep it through upgrades. Redis backs the job queues that CKAN uses for background work, including the harvest queues that the RDF harvester depends on. Solr and Redis can run from Docker images tagged for each CKAN version, which helps match versions, but your team still owns their backups, memory sizing and network access rules. Confirm that each image tag matches the CKAN release you deploy.
CKAN 2.12.0 and the support gap
CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11 on the same day. The ckanext-dcat support statement covers CKAN 2.10 and 2.11 only, so a 2.12 deployment with DCAT-AP endpoints has no stated extension support today. Treat this as a blocking question for any upgrade plan that keeps DCAT-AP publishing or the RDF harvester. CKAN's release policy supports the latest patch of the current and previous minor versions, so 2.11 remains a supported line to plan around.
Confirm ckanext-dcat before upgrading
Before moving a portal to CKAN 2.12, request written confirmation of ckanext-dcat support from the extension maintainers, and check the ckanext-dcat repository for a release that names that CKAN version. Stage the upgrade on a copy of production with the DCAT plugin enabled, then check the output for each DCAT-AP version in use and the RDF endpoints that national or European catalogs read. Minor releases may include backwards-incompatible changes, so review the CKAN release notes before the test begins.
Harvesting extension for the RDF harvester
The RDF harvester runs on the harvesting extension, ckanext-harvest, so that extension must be installed and its job processing running before the RDF harvester can import anything. Enable the harvester in staging, run a test import from a source catalog, and confirm that jobs move through the queue to completion. Check that the harvesting extension also supports your target CKAN version, since the DCAT harvester cannot be validated on a platform where its dependency is unsupported.
Which DCAT-AP version to publish and consume
The DCAT-AP version you choose determines two things: what your portal's RDF catalog endpoints emit and what the aggregator receiving that metadata will accept. Settle the target before you touch configuration. Ask the aggregator, in writing, which DCAT-AP version and application profile it requires, which properties are mandatory, recommended or optional, which controlled vocabularies it expects, and how it wants the RDF serialized. Ask whether it accepts more than one version during a transition period. Without that written answer, any mapping work is built on assumptions that an aggregator's validator may later reject.
Next, confirm what the ckanext-dcat release you plan to install actually emits and parses. The extension provides DCAT-AP v1, v2 and v3 schemas, but support is not the same as full coverage of every property in every version. Check the release notes and documentation for the version you intend to deploy, then run a test on a staging instance. Verify the endpoint output, the RDF harvester's import of sample files in each version, and the result when the two are combined. The extension is supported on CKAN 2.10 and 2.11, so the release must also match your CKAN minor version, which you should confirm against the CKAN release policy before planning an upgrade.
A portal may need to serve one DCAT-AP version while harvesting another. For example, an illustrative portal might harvest from upstream catalogs that publish a older profile while publishing a newer one to a national aggregator. Each direction can drop, rename or restructure fields, so a dataset that validates on export may lose a required value after a round trip. Decide which CKAN fields are authoritative, document where a mapping is applied, and test with representative datasets from every source. Confirm whether the aggregator accepts the output of a mapped record or only native records, since that decision changes the scope of mapping work.
Turn these decisions into a version matrix before any build starts. List each endpoint and harvest source, its direction, its target DCAT-AP version and profile, the ckanext-dcat and CKAN versions tested, and the evidence that proves the output was accepted. Keep the fixture datasets under version control so the tests can be repeated after each upgrade, because minor CKAN releases may include backwards-incompatible changes. In any quote, ask for validation of both directions, the mapping specification and the profile documentation as named deliverables. Validation shows that output meets the stated profile, but acceptance by an aggregator or a conformance outcome remains the decision of that aggregator or an independent assessor.
Setting up CKAN DCAT-AP endpoints in order
This sequence takes a CKAN portal from version confirmation to a tested DCAT-AP catalog and RDF harvest, with a check at every step. Each stage proves the previous one works before the next begins, so production only receives configuration that has already been verified on staging.
Confirm CKAN and extension versions
Your platform or data team checks the CKAN version in use and the ckanext-dcat release that supports it. The extension's documentation lists CKAN 2.10 and 2.11 as supported, and CKAN 2.12.0 was released on August 26, 2026, so confirm compatibility with that minor version before you choose it. Also confirm which DCAT-AP schema version (v1, v2 or v3) your national or European reporting requires. Done when you have a written version matrix that names CKAN, the extension, the schema and the target portal.
Build the staging instance
Your platform team installs CKAN from source on a staging host with Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis. Staging should mirror production's operating system, reverse proxy and sitewide settings so results carry over. Done when the CKAN web interface loads, the action API returns a status response, and a test dataset can be created and found in search.
Install ckanext-dcat on staging
Your platform team installs ckanext-dcat into the same Python environment as CKAN, then adds the DCAT plugins to the plugins setting in the configuration file, following the extension's README. Restart the services and watch the logs for plugin load errors or missing dependencies. Done when CKAN starts cleanly, the plugins appear as loaded, and the dataset edit form shows the DCAT fields without errors.
Select and apply the DCAT-AP schema
Your metadata lead configures the DCAT-AP schema version chosen in step one and maps required fields, such as publisher, license and contact point, to the fields your editors complete. Test with a small set of representative datasets, including one with missing optional fields. Done when those datasets serialize to RDF with every mandatory property present, and a reviewer confirms the field mapping against the schema documentation for that version.
Expose and test the RDF catalog endpoints
Your platform team confirms the catalog and dataset RDF endpoints are reachable through the staging proxy, using the paths documented for ckanext-dcat. Fetch the catalog in each RDF serialization you publish, then parse it with an RDF library and validate it against the DCAT-AP shapes for your schema version. Confirm the validator and version with your reviewer before you rely on the result. Done when the catalog parses without errors and the validation report shows no mandatory failures.
Test a harvest against a known catalog
Your data team creates a harvest source in staging that points to an RDF catalog whose contents you know in advance, such as a catalog you operate or a small public sample. Run the harvest job and compare the imported datasets with the source's listing, checking titles, counts and key fields. Investigate any dataset that fails to import or maps to the wrong organization. Done when the job completes and the expected datasets appear with correct metadata.
Move the configuration to production
Your platform team applies the same configuration files, plugin list and schema mapping to production through your normal change process, and does not edit the production host by hand. Repeat the endpoint fetch and validation checks, then schedule the production harvest only after those checks pass. Done when production serves valid catalog output, the first scheduled harvest imports the expected datasets, and the staging and production configuration match in version control.
Mapping CKAN dataset fields to DCAT-AP properties
This table lists the core CKAN dataset fields, the DCAT-AP properties they correspond to, the direction of exchange and the check to run before go-live. Use it as a starting checklist, not a finished specification. The mapping depends on the DCAT-AP version you adopt and on the custom extras your portal defines, and ckanext-dcat defaults can change between releases. Confirm each row against the ckanext-dcat documentation for your release before you rely on it.
| CKAN field or extra | DCAT-AP property or class | Direction | Check to confirm |
|---|---|---|---|
| Dataset title | dct:title on dcat:Dataset | Both | Title appears in the RDF output and survives a round trip through the harvester in a test catalog |
| Dataset description (notes) | dct:description on dcat:Dataset | Both | Markdown or HTML in notes is converted as your release expects, with no stray markup in published RDF |
| Organization as publisher | dct:publisher on dcat:Dataset, pointing to a foaf:Agent | Both | Publisher name and identifier are populated for every dataset, and the agent URI resolves to a stable value |
| License identifier | dct:license on dcat:Dataset and distributions | Both | License values map to URIs in the controlled vocabulary your DCAT-AP version expects, not free text |
| Resource records | dcat:Distribution linked through dcat:distribution | Publish | Each resource yields one distribution with an access URL or download URL, and format values map to a controlled vocabulary |
| Resource format and media type | dct:format and dcat:mediaType on dcat:Distribution | Publish | Format strings resolve to the vocabulary URIs your validator accepts, and unknown formats are flagged rather than dropped |
| Maintainer and maintainer email | dcat:contactPoint on dcat:Dataset, using vcard:Organization or vcard:Individual | Both | Contact points are present for each dataset and the email address is formatted as a mailto value |
| Custom extras (for example, spatial, temporal or security classification) | Local extension, or a mapping to a DCAT-AP property if one exists | Both | Decide each extra explicitly: map it, keep it local, or exclude it. Check that the chosen DCAT-AP version defines the target property |
How RDF catalog endpoints and the RDF harvester interact
The first decision is whether this portal publishes its datasets as RDF, harvests RDF from other catalogs, or does both, because the two directions share identifiers and can feed each other. The ckanext-dcat extension provides RDF catalog endpoints that serialize the portal's public datasets as DCAT-AP metadata, so national aggregators, European harvesters and other catalogs can read them without a CKAN login. The RDF harvester works in the opposite direction. It fetches RDF from an external catalog and creates or updates local CKAN datasets from it. Both directions use the same DCAT profile, so a field mapped in one direction affects the other. Confirm which DCAT-AP version each consumer expects before go-live, since ckanext-dcat supports the DCAT-AP v1, v2 and v3 schemas.
An endpoint is a read-only view, but its content depends on how well the portal's metadata is filled in. Datasets without a stable identifier, publisher, license or contact point may be published with gaps that aggregators reject or silently drop. Sample datasets from each organization, inspect the endpoint output, and compare it with the DCAT-AP mapping your target aggregator applies. Test visibility as well: private datasets, drafts and deleted datasets should not appear in public output. Endpoint paths, serialization formats and configuration options come from the extension documentation for the installed release, so confirm them against your own instance rather than copying settings from another portal.
The round trip is the main risk. Suppose Portal A publishes its catalog over RDF, Portal B harvests from A and republishes what it collected, and Portal A later harvests from B. Without a rule, a dataset that originated in A returns to A as a new local dataset with a different CKAN ID, and the same underlying data appears twice. Illustrative example: a dataset created in Portal A is harvested by B, then harvested back into A as a second entry with its own edit history. To prevent this, decide before go-live which portal owns each dataset, which identifier is authoritative (the DCAT identifier, the source catalog URI or the local CKAN ID), and whether a harvester may overwrite a locally owned dataset. Record the originating catalog on every harvested dataset so the harvester can recognize and skip records it published itself.
Before go-live, list every external catalog this portal will harvest from and every consumer that will harvest from it, then map which catalogs feed each other. Agree the identifier scheme and an ownership table, and test a full round trip in staging using a copy of production metadata. Name the person who handles duplicates after launch and how they are reported. Also check version constraints: ckanext-dcat is listed as supported on CKAN 2.10 and 2.11, and CKAN 2.12.0 was released on August 26, 2026, so confirm extension support for the target CKAN version before any upgrade. Job scheduling, queues and harvest run monitoring are covered in the harvesting section of this topic.
Securing CKAN DCAT-AP endpoints and harvested metadata
The RDF endpoints and the harvester expose and import metadata, so both need decisions before go-live. The controls below cover what is published, how connections are protected, which external catalogs are trusted, who can change harvest sources, what is logged, and how all of it maps to any compliance baseline the portal must meet.
Decide public datasets and fields
Before the RDF catalog endpoints go live, decide which datasets, resources and metadata fields are publishable. DCAT-AP output carries what the CKAN record holds, including contact details, descriptions and resource URLs, so private or draft datasets and internal fields need an explicit review. Check each endpoint's output against an approved field list, and confirm with data owners which organizations may appear in the public catalog. Repeat this review after any schema or profile change.
TLS on endpoints and harvest connections
Serve the DCAT RDF endpoints only over HTTPS, with TLS terminated at the Nginx or load balancer layer you run for production CKAN. Harvest jobs also fetch remote catalogs over TLS, so confirm that certificate validation is enabled and that the trust store includes any internal certificate authority used by source catalogs. Agree protocol and cipher settings with your security team, and test that plain HTTP requests redirect to HTTPS without returning metadata.
Trust in external harvest sources
Each harvest source is a catalog you do not control, so its RDF may contain malformed, misleading or hostile content. Record who approved each source, its business owner and its purpose, and review the list on a schedule. Confirm how the RDF harvester maps imported records to your DCAT-AP profile and whether harvested records are reviewed before they become public. Treat harvested text as untrusted input wherever a page renders it.
Restrict who changes harvest sources
Creating or editing a harvest source changes what the portal fetches and publishes, so treat it as an administrative action. Limit those permissions to a named group of administrators, and remove access promptly when staff change roles. Confirm that ordinary editors can view harvest results without changing source URLs, schedules or configuration. Record each source change in a change log so that the approval trail is available to the assessor.
Log harvest and endpoint activity
Record harvest activity and endpoint access so you can answer what was fetched, from where, when and by which job. Harvest job status and errors in CKAN are one source, and web server access logs for the RDF endpoints are another. Confirm where each log is stored, how long it is kept, who can read it and whether it is forwarded to a central system you operate. Check that logs do not capture credentials embedded in source URLs.
Map controls to the compliance baseline
If the portal sits under a framework such as NIST SP 800-53, FedRAMP, CJIS or CUI rules, map the endpoint and harvest controls to that baseline before go-live. Each applicable control needs a named implementation, an owner and evidence, and the mapping should cover public endpoints, harvest connections, source approval and logging. Confirm scope with your assessor, because the applicable baseline depends on the data handled and the hosting model.
Common CKAN DCAT-AP failures and how to fix them
This table pairs common symptoms in ckanext-dcat deployments with their likely causes and a specific check to run before changing anything. Read each row as a diagnostic path: confirm the CKAN version and extension compatibility first, then validate the RDF output, the harvest mapping, the dataset identifiers and the proxy configuration. Most failures trace back to one of these five areas.
| Symptom | Likely cause | Fix and check to run |
|---|---|---|
| Extension fails to load after a CKAN upgrade | The CKAN version is outside the range the installed ckanext-dcat release supports, or the extension was not reinstalled into the new virtual environment | Check the ckanext-dcat release notes against your CKAN version (the extension is supported on CKAN 2.10 and 2.11). Pin a compatible release, reinstall it into the CKAN virtualenv, then read the startup log for plugin load errors before restarting uWSGI |
| RDF output rejected by a validator for a missing mandatory property | The dataset lacks a value that the DCAT-AP profile in use requires, or the profile version configured does not match the validator's profile | Confirm which DCAT-AP version the validator expects, then fetch one dataset's RDF from the catalog endpoint and check it for the mandatory properties of that profile. Fill the missing fields in the CKAN schema or the mapping, and re-run the validator on a sample of datasets |
| Harvested datasets arrive without expected fields | The source publishes metadata in a different profile or syntax than the harvester maps, or the field is mapped to a property the source does not populate | Inspect one harvested dataset and the source's raw RDF side by side. Compare the source's property names with the harvester mapping for that profile, adjust the mapping or the source configuration, and rerun the harvest job for a single source to confirm the field appears |
| Duplicate datasets created by a round trip | Datasets are exported to another catalog and harvested back without a stable identifier, so the importer treats each return as a new record | Check that each dataset has a persistent identifier that survives export, and that the harvester matches on it. Search for duplicate titles in the catalog after a test round trip, and confirm the identifier appears unchanged in the exported RDF before enabling a scheduled harvest |
| Endpoints return errors behind a reverse proxy | The proxy strips or rewrites the Accept header or the path, or the CKAN site URL does not match the public host, so content negotiation and links fail | Request the catalog endpoint with explicit RDF Accept headers, both directly to the application server and through the proxy. Compare status codes and returned content types, then verify the configured site URL and forwarded headers match the public hostname |
| Endpoint output differs between environments | Different ckanext-dcat versions, profile settings or schema plugins are enabled in test and production | Compare the installed extension version, the enabled plugins in the CKAN configuration file and the profile setting in each environment. Align the configuration, then compare the RDF output of the same dataset in both environments |
How to test DCAT output before publishing to an aggregator
Test DCAT output in a staging environment before any aggregator harvests your portal, because a harvester that rejects or misreads your records will report a problem to the aggregator's operators, not to you. The test plan has three parts: validation of the serialized RDF against the DCAT-AP version you chose, a harvest round trip into a second staging instance, and a check that edits and deletions propagate. Agree the target DCAT-AP version with the aggregator first, since a validator run against the wrong profile produces a clean result that proves nothing.
Start with validation. Pull the RDF from the catalog endpoints that ckanext-dcat exposes on the staging portal, in each serialization the aggregator accepts, and run it through the aggregator's own validator if it publishes one. If it does not, use an independent validator that supports the same DCAT-AP version and confirm in writing which profile rules it applies. Record every error and warning, decide which ones block publication, and keep the raw output. Pay particular attention to mandatory properties, controlled vocabulary values, date formats and the links between catalog, dataset and distribution resources, because these are where mappings from CKAN fields most often drift.
Next, run a harvest round trip. Point a second staging CKAN instance, with its own copy of the RDF harvester configuration, at the staging portal's catalog endpoint and import the records. Compare the dataset count between the two instances, then compare key fields for a sample that covers each organization, each license, datasets with resources and datasets with spatial or temporal extents. Mismatches in titles, identifiers, publishers or contact points usually come from a mapping gap rather than a harvester fault, so trace each one back to the field mapping before you change anything.
Then test change handling. Edit a dataset's title and one resource, delete a second dataset, and re-run the harvest in both directions as your aggregator will do it. Confirm that the edit appears in the second instance, that the deletion is reflected and that nothing is duplicated. Ask the aggregator how it handles deleted or moved identifiers, because a catalog that reuses identifiers can cause silent overwrites that this step will not reveal unless you check the sample by hand.
Finally, record versions. Write down the CKAN version, the ckanext-dcat version, the DCAT-AP version and the validator name and release used for each run, together with the harvester configuration and the date. Confirm these values from your own installed packages, not from memory. A later CKAN or ckanext-dcat upgrade can then be retested against the same evidence, and any difference in output can be traced to a specific change. Keep these records with your change log so that the next person running the plan can repeat it exactly.
Questions buyers ask about CKAN DCAT-AP implementation
What drives the cost of a CKAN DCAT-AP implementation?
Cost follows the scope you agree in writing, and five factors move it most: the number of datasets to map and publish, the number of DCAT-AP versions the portal must serve, the complexity of your metadata mapping, the number of external harvest sources, and the CKAN upgrade path your portal needs. Each one-time item (mapping design, extension setup, testing, aggregator validation) is separate from recurring items (patching, extension updates, harvest monitoring). Ask the quote to price each driver as its own line, state the CKAN version assumed, and list which items are optional. Confirm with your vendor whether any hosting or licensing costs fall on your side, since the software itself is open source.
How many DCAT-AP versions can one CKAN portal serve?
The ckanext-dcat extension provides DCAT-AP v1, v2 and v3 schemas, so the technical limit is set by the extension rather than by your data. Each version you serve adds mapping rules, RDF output checks and test cases, so the effort grows with the number of versions and with how different their property sets are. Confirm which versions your national or European aggregator accepts before you scope the work, because some aggregators only ask for one version. In the quote, ask for each version as a separate line with its mapping and test effort, and ask how future version changes would be handled.
How long does a CKAN DCAT-AP project usually take?
Duration depends on scope and on how available your team is, and no single figure applies to every portal. The largest variables are the number of mapping decisions still open, how many harvest sources need to be configured, how quickly your data owner can answer mapping questions, and how long the aggregator takes to review and validate output. A project waiting on staging access or on a decision from the data owner will stall regardless of engineering speed. Ask for a written timeline that shows dependencies, client review points and the aggregator validation window as separate phases, and ask which phases assume your team is available full time.
What does our organization need to provide for a DCAT-AP engagement?
Three inputs decide whether the work moves on schedule. First, a named data owner who can approve the metadata mapping and resolve questions about dataset quality and licensing. Second, access to a staging CKAN portal that matches production in version and configuration, so RDF output can be tested before publication. Third, the written profile requirements of the aggregator you publish to, including the DCAT-AP version, required and recommended properties, and any validation rules. Ask the vendor to list these inputs in the scope document with an owner and a due point for each, so missing inputs show up as dependencies rather than as schedule surprises.
Can our internal team implement CKAN DCAT-AP without outside help?
An internal team can do this if it already runs CKAN in production and has engineers comfortable with Python, PostgreSQL, Solr and Redis, plus someone who understands DCAT-AP and the aggregator's profile. The CKAN install guide lists Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, so check your current versions first. ckanext-dcat is supported on CKAN 2.10 and 2.11, so an upgrade may come before the extension work. The main risks for in-house teams are underestimating mapping decisions and having no one to test RDF output against the aggregator's rules. A partial engagement, such as a mapping review or validation check, can cover those gaps.
Which CKAN version should a DCAT-AP project target?
Target a version that ckanext-dcat supports and that still receives fixes, then plan the upgrade path around it. The extension is supported on CKAN 2.10 and 2.11, and CKAN 2.12.0 was released on August 26, 2026, so confirm extension support for 2.12 before you commit to it. CKAN aims for about two minor releases a year, and the project supports the latest patch of the current minor version and the previous minor version. Patch releases do not break backward compatibility, while minor releases may include incompatible changes, so a minor upgrade needs its own test cycle. Ask the quote to state the target CKAN version and the extension version it was tested against.
What usually breaks in CKAN RDF endpoints, and what should we check?
Most problems come from mapping, not from the software. Common issues include required DCAT-AP properties left empty for some datasets, controlled vocabulary values that do not match the aggregator's list, licence or contact fields filled inconsistently across organizations, and RDF output that changes after an extension or CKAN upgrade. Check the RDF endpoint output on staging against the aggregator's validation rules after every mapping change and after every upgrade. Confirm that the harvester handles the external catalogs you consume using the same vocabulary rules. Ask the vendor to show how the test cases map to the aggregator's requirements, so you can review them yourselves.
How DeployOpen scopes and delivers the CKAN DCAT-AP integration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For CKAN DCAT-AP metadata and RDF endpoints, that means scoping the DCAT-AP profile, catalog endpoints and harvester against your portal's CKAN version and running them in your cloud accounts, data centers or air-gapped network. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Confirm the CKAN version and whether it falls within ckanext-dcat support for CKAN 2.10 and 2.11.
- Agree which DCAT-AP version (v1, v2 or v3) each published and harvested catalog must follow.
- Document in the written scope which national or European RDF catalog endpoints and harvest sources are in scope.
How we build
- Configure ckanext-dcat schemas, field mappings and RDF endpoints in a staging instance before production.
- Set up the RDF harvester with source definitions, schedules and validation of imported DCAT records.
- Customize or extend the DCAT mapping only where the agreed profile requires it, and record each change.
How we hand over
- Test endpoint output against the agreed profile with sample datasets and RDF serialization checks.
- Provide written runbooks covering endpoint configuration, harvest jobs, upgrades and rollback steps.
- Hand over documentation and the configuration as code your team keeps in its own repositories.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan CKAN upgrades around the release policy, since minor releases may include backwards-incompatible changes.
- Confirm ckanext-dcat compatibility with each new CKAN minor version before upgrading a production portal.
