Fix TIME namespace definition to use DCAT recommendation #344
+15
−15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Context
This PR addresses an issue with namespace definitions while working on implementing profiles according to the contributing guidelines. We've been developing custom profiles for the Spanish application profiles - both the current NTI-RISP (based on DCAT) and the future Spanish profile based on DCAT-AP.
Although this can be handled within the harvester, following DCAT's recommendation to use the more common namespace would be beneficial, especially since many publishers rely on ckanext-dcat to serialize their RDF for the national catalog.
Problem
During development, we identified an issue with the TIME namespace definition in base.py. The current implementation defines TIME without the trailing hash (#):
However, the correct URI according to W3C specifications and DCAT-AP should include the trailing hash:
Impact
This incorrect namespace definition causes properties like
time:years
,time:days
, etc. to be serialized with incorrect URIs:http://www.w3.org/2006/timeyears
http://www.w3.org/2006/time#years
This breaks interoperability with standards-compliant harvesters, especially for
dct:accrualPeriodicity
data structures for federation with portals like datos.gob.es.Example of the issue
We found datasets that weren't federating correctly with datos.gob.es. Examining the RDF revealed that years/days properties weren't being properly recognized:
Incorrect (won't federate):
Here,
time:days
points tohttp://www.w3.org/2006/timeyears
instead ofhttp://www.w3.org/2006/time#years
.Correctly federated example:
Solution
This PR updates the namespace definition in
base.py
to use the correct URI with the trailing hash, as specified in DCAT:Also update namespace in tests
Testing & Verification
We've verified this fix by manually applying it to our local installation and confirming that datasets with temporal properties using the TIME ontology (e.g.,
dct:accrualPeriodicity
) are now correctly harvested by external systems.Tests also pass.
References