Add dcat:Catalog binding rule for DCAT-AP compliance to CCMM documentation

[OndrejZamazal]

Following the raised issue of missing Catalog, a straightforward way to ensure DCAT-AP 3.0.1 compliance without expanding the core CCMM model is to clarify the catalog binding rule in the CCMM documentation:

When publishing CCMM metadata to a DCAT-AP compliant interface, CCMM datasets are simply encapsulated within a dcat:Catalog object representing the publishing repository (including its mandatory properties dct:title, dct:description, dct:publisher).

See https://semiceu.github.io/DCAT-AP/releases/3.0.1/#Catalogue

[MichalMed]

what about Repository class profiling Catalog directly?

[OndrejZamazal]

Making Repository profiling dcat:Catalog makes total sense. There should be three mandatory properties: dct:title, dct:description, and dct:publisher.

Repository.label is directly profiling dct:title. Publisher information is available via Repository.qualifiedAttribution, but it is not explicitly profiling dct:publisher; would this need additional mapping? Next, the mandatory dct:description is missing altogether. I would also say there should be a profile for the dcat:dataset property (though it is technically recommended, not mandatory).

Even if we fully map Repository to dcat:Catalog (which I think is currently not the case), a description of how to publish CCMM metadata to a DCAT-AP compliant interface would still be very useful.