This looks like a very specific DCAT capability that is appropriately modeled

No-one advocating for changes here.

I'll bring this proposition to the next DCAT team telecon for resolution.

+1 to no change

Goal is to support dataset catalogs, not provide general purpose predicates for the semantic web

https://www.w3.org/2018/03/21-dxwgdcat-minutes
resolved: no change to domain/range of dcat:themeTaxonomy

I think that this resolution is inconsistent with the others where the domain was removed. But that is just my view.

Accessing https://www.w3.org/2018/03/21-dxwgdcat-minutes results in a 403 error.

Yes - there was a bug generating the minutes. I clipped a copy of the IRC log and have forwarded it to W3C to process.

On consistency @akuckartz the argument is that dcat:themeTaxonomy is a specific predicate to link a skos:ConceptScheme to a dcat:Catalog whose members may use elements from the concept scheme. It is not a goal of DCAT to be a source of general purpose predicates for the semantic web, it is to support catalogs of datasets and related resources. So it is reasonable for a catalog to indicate which classification systems are in scope for its members.

As mentioned in the telco, I think the naming of the property is inconsistent with the purpose that it should be used to indicate the classification scheme for a Catalog. If that is the desired semantics, then catalogTheme or themeCatalog would certainly make sense. It if is generically called themeTaxonomy, I would not expect a domain. I was voting 0, though, no objection, but I agree with @akuckartz that it is inconsistent.

are we still leaving the range constraint of dcat:themeTaxonomy in place? - it precludes using a skos:Collection at present

Good point @pwin
Many potential vocabularies that would provide a set of theme classifiers are not organized as skos:ConceptSchemes - in fact many are not SKOS at all, though they are nevertheless good choices.
I suggest dropping the global range constraint (and maybe add sdo:rangeIncludes skos:ConceptScheme, skos:Collection which is a non-exclusive statement).

Core issue resolved here, and actioned some time ago. Use of sdo:rangeIncludes tracked via #912. I think we can close this one.

agreed