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.
Refs #298 , fixes #332
This adds preliminary support for exposing Dataset Series and their members (managed by ckanext-dataset-series).
Datasets of type
dataset_series
(TODO: support custom series types) are serialized asdcat:DatasetSeries
, and member Datasets include thedcat:inSeries
property. If the series is ordered, navigation is included for both entities (dcat:first
/dcat:last
anddcat:previous
/dcat:next
respectively):Example Dataset Series (http://localhost:5000/dataset_series/test-dataset-series.ttl)
Example member Dataset (http://localhost:5000/dataset/test-series-member-2.ttl)
When requesting the catalog endpoint (e.g. http://localhost:5000/catalog.ttl) Dataset Series are typed as
dcat:DatasetSeries
and member datasets contain thedcat:inSeries
property but the navigation properties are not provided for performance reasons. I think this is a good compromise for now as the full properties can be accessed on each dataset serialization.A note on URIs
At first I though about constructing the Dataset URIs using
/dataset_series/
for consistency:But that brings extra considerations. If we want to support custom series dataset type (i.e. stuff like
/projects/
or/collections/
) those should also have the same URI pattern, probably using/dataset_series/
and not the custom type. This would involve makingdataset_uri()
aware of the preferred dataset type, probably via a param.We definitely don't want to change the URIs for any arbitrary dataset type (as this might break existing URIs in existing sites with custom dataset types), but for those types that describe Dataset Series perhaps it's worth the added complexity (and other entities could also have different URI patterns in the future if they are implemented with dataset types, like Data Services).
Any thoughts @seitenbau-govdata @hcvdwerf ?
TODO: