I would suggest to avoid, as much as possible, including constraints in a base specification; only if it is absolutely necessary. It could lead people to invent another vocabulary if they can't work with the constraints.

I would suggest to avoid, as much as possible, including constraints in a base specification; only if it is absolutely necessary. It could lead people to invent another vocabulary if they can't work with the constraints.

+1

I would suggest to avoid, as much as possible, including constraints in a base specification; only if it is absolutely necessary. It could lead people to invent another vocabulary if they can't work with the constraints.

+1

Discussion on this topic for the DCAT properties that might be affected should now be in the individual issues #95 #109 #117 #118 #119 #120 #121 #122 #123 #124 #125 #126 #127 .
Some non-DCAT properties may also be affected, primarily from DCT -

I would suggest to avoid, as much as possible, including constraints in a base specification; only if it is absolutely necessary. It could lead people to invent another vocabulary if they can't work with the constraints.

+1

This issue caught my eye and I'm rather new to this discussion. Is the issue still unresolved?

@dr-shorthair I'm not sure what you mean when you say that OWL cardinality constraints "constrain use of a property in the context of a class". OWL restrictions place constraints on a model of reality but say nothing about cardinality that is intended to be enforced in actual data, which I take to be the requirement here. The proper place to declare cardinality constraints for the purposes of closed-world validation would be in a data shape or schema language (e.g., ShEx or SHACL), not in a model expressed with open-world semantics in OWL.

In my opinion, DCAT v1 got it right when it said simply "The following properties are recommended for use on this class" (which I take as shorthand for: "The following properties are recommended for use in describing instances of this class"). An OWL class is a named set of things (the class extension). OWL cannot be used to formally put properties "on" a class. Schema.org, for example, is perfectly usable as a source of associations between classes and properties without trying to formalize that association.

Thanks @tombaker for reiterating the utility and purpose of the various tools, in particular the distinction between models off the world and constraints on data. I think we can probably close this issue.