Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specific subproperty dcat:datasetSeries #1598

Open
bertvannuffelen opened this issue Apr 26, 2024 · 3 comments
Open

specific subproperty dcat:datasetSeries #1598

bertvannuffelen opened this issue Apr 26, 2024 · 3 comments
Labels
dcat future-work issue deferred to the next standardization round

Comments

@bertvannuffelen
Copy link

The class Catalog has 3 specific properties to indicate the listed resources in the catalogue.

  • dcat:dataset
  • dcat:catalog
  • dcat:service

It has 2 generic properties

-dcat:record
-dcat:resource

Intuitively, dcat:resource is the shorthand for dcat:record in a catalogue.
The subproperties dcat:dataset, dcat:catalog and dcat:service of dcat:resource can intuitively be seen as the filter on dcat:resource with as range the corresponding DCAT class.

My question is why dcat:datasetseries is not created?

  • Argument 1: it is a subclass of Dataset thus it is not needed.
  • Argument 2: the use of the subproperties such as dcat:dataset is deprecated in favor of dcat:resource

But

  • Argument 1 has also dcat:catalog as counterexample.
  • Argument 2 has no indications in the specification.

So it seems that we are missing here for some unknown reason dcat:datasetseries.

@dr-shorthair
Copy link
Contributor

Probably no specific reason. Classes and properties were added as proposed, discussed and agreed. Some inhomogeneity to be expected.

@riccardoAlbertoni
Copy link
Contributor

riccardoAlbertoni commented Apr 30, 2024

You may find issues #1307 and #1335 helpful in understanding the context that informed our decision-making process at that time.
I recall that the group engaged a quite complex discussions regarding dcat:inSeries and its inverse, dcat:seriesMember.
Overall, decisions were made to reconcile the diverse positions and concerns. In certain cases, the complexity of points of view necessitated compromises, as each option had its own pros and cons.

@riccardoAlbertoni
Copy link
Contributor

You may find issues #1307 and #1335 helpful in understanding the context that informed our decision-making process at that time. I recall that the group engaged a quite complex discussions regarding dcat:inSeries and its inverse, dcat:seriesMember. Overall, decisions were made to reconcile the diverse positions and concerns. In certain cases, the complexity of points of view necessitated compromises, as each option had its own pros and cons.

That reply was intended for issue #1600. I switched the issues, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dcat future-work issue deferred to the next standardization round
Projects
None yet
Development

No branches or pull requests

3 participants