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

Reasoning for Main Entitiy or Supportive Entitiy #388

Open
init-dcat-ap-de opened this issue Aug 30, 2024 · 1 comment
Open

Reasoning for Main Entitiy or Supportive Entitiy #388

init-dcat-ap-de opened this issue Aug 30, 2024 · 1 comment

Comments

@init-dcat-ap-de
Copy link

We also plan to diferentiate between main entities and supportive entities in DCAT-AP.de 3.0. But I am wondering how the distinctions were made? Why are these "Main Entities":

  • Agent
  • Checksum
  • Kind
  • Licence Document
  • Location

Why isn't (especially) "Period of time" a Main Entity?
What is the rule to determin wether it's an supportive or main entity?

@bertvannuffelen
Copy link
Contributor

The choice is a bit arbitrarely, and inspired by the fact that DCAT-AP is a long specification with many classes.
When listing them alphabetically one looses focus on what is more important.

So the list of main entities are those which are closely related to mandatory or recommended information starting from the 5 key classes in DCAT: Catalogue, Dataset, Distribution, Data Services and Dataset Series.
If the range of a property of those has additional information or if the property itself is so important and the range class needs additional attention, then they are included in the Main Entities. Most of these Main Classes come with a number of specific usage constraints expressed in DCAT-AP.

For instance a code of codelist (Concept): one could argue that these are critical. But besides they should follow the best practices of SKOS, which implicitely also is part of the usage of skos:Concept as URI, DCAT-AP does not imposes any additional requirement that would stand out.
The constraint of having a prefLabel is actually part of SKOS and is more as extra documentation included than as necessary rule that DCAT-AP imposes.
Thus the supportive entities are more those one which one thinks: "we know how to use them, but we list them anyhow here for completeness." Making so the document more self-contained.

Another criterion could be frequency of use or frequency of incorrect use. If e.g. Checksum is not very popular (1 in million distributions has it) then it is maybe better to move it to be supportive entity. It was their because in DCAT-AP 2 there was a very strict restriction on the use of SHA1. That constraint was the reason to put it their. Now with its freedom to have any algorithm in DCAT-AP 3, and maybe its low usage it could be shifted to supportive.

Of-course one can argue on the boundary, there is a grey zone. But if one understands and reads the main entities then one grasps the heart of the specification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants