dcatap:applicableLegislation

[joshcornejo]

From your diagram, every class with the dcatap:applicableLegislation is a descendant of dcat:Resource, it would be better to place the new attribute in dcat:Resource rather than repeating it everywhere.

[bertvannuffelen]

@joshcornejo that is intentionally done this way.

In DCAT-AP we focus on the real classes Datasets, Distributions and Data Service and Dataset Series. Not on the abstract class catalogued Resource. In many cases there is a semantical/intentional difference between the same property of 2 subclasses. For instance language in the case of a Dataset is the language in which the data in the dataset is recorded/stored/maintained, while for a Data Service (API) this is the language in which the API keys are provided or the language in which the API may provided the data in the repons. Same property but very distinct values. It even might be useless to provide the value in some cases: for an API with an autotranslation on top is the language rather meaningless.

Those differences cannot be expressed at the abstract class, and therefore, to avoid complicated explanations why some are expressed below and others are kept on the abstract we try to be as precises as possible.

In addition DCAT-AP is an application profile: in that case it may state additional information/requirements for a property in one real class only. For instance, listing the property language on Dataset and not on Data Service has the slight interpretation that language is important to be considered for Datasets, but for Data Services it is less important and thus can be ignored.
This is a more subtle argument, but whether or not it is listed in DCAT-AP is sometimes considered important for some implementers. Even in the case that it does not has any additional requirement compared to W3C DCAT.

It is a choice, and sometimes a grey zone, but at least there is no ambiguity: the usage of each property is expressed in its class usage context.

Note that the property dcatap:applicableLegislation could (technically) be applied beyond DCAT-AP. I would not recommend it, but it is possible.

[joshcornejo]

Understood, I agree it is a matter of preference.

I have always considered the diagrams as "related to the class definition" rather than related to the "object/instance definition", as such it should be understood that in a specialisation case, the properties of the class "spread implicitly" to the descendants, whilst it is understood they will vary on instantiation?

Also, I wouldn't infer that the presence/absence of a property makes it "mandatory/important/optional/obfuscated". (I rather have that explicitly marked somehow in the diagram and the descriptions.

At least for me, it makes the diagrams cleaner and easier to understand.