@akuckartz this is an important question. However, 'change semantics' is a fuzzy concept. In a formal sense I agree that dropping the domain is a change. But it would really only affect applications that apply reasoning, and elsewhere in the discussion I get a strong sense that DCAT is not primarily used in reasoning environments - in fact there seems to be a fairly strong push back against formal semantics.
In other standards environments the issue is phrased as 'backward compatibility' but that is not a clean concept as it totally depends on the entailment regime.

I suggest we raise this in plenary. Would also be interested in @draggett and @philarcher and @danbri opinion.

I'd say (I imagine uncontroversially), that defining a new namespace for DCAT2 should be an absolute last resort. Doing so would set the clock back in terms of establishing DCAT's acceptance - and it already has a lot of competition. Even if you were to define a new namespace, you'd then have the problem of people using, say, dcat:Distribution when in fact, oh silly developer, you meant dcat2:Distribution; don't you know the difference?

No - unless there are strong reasons backed by real world evidence, stick with the existing namespace.

But... don't fret too much. Removing a domain restriction or other such relaxing of the rules isn't cause to consider a new namespace. Even tightening semantics would only entail a new namespace if you had clear evidence of people using the existing looser semantics - which as Simon says, I think would be surprising.

I remember many years ago, Chaals McN saying that people add domain and range constraints to try and push people to use their vocabulary they way they want it used. Actually, all it does is to restrict your audience. If you need to specify domains and ranges for the thing to work, OK. If you can live without them, don't do it. People are much more likely to use your terms if they can use them the way they want to. Hence schema.org's 'domainIncludes' notion - which may be useful here?

The alternative is to go down the route followed by SSN/SOSA where a simple lightweight vocabulary, SOSA, is extended and the semantics are more tightly defined by the more sophisticated SSN. If the WG really feels that a separate namespace is needed for DCAT2

1. Strip out as many semantic restrictions as possible from DCAT (and goodness knows, there aren't many)
2. Define DCAT2 as an extension - or, given the DXWG context - I guess the world is profile ;-)

But again, this should be a last resort. At the end of the day, DCAT is doing a pretty straightforward job - it probably doesn't need a lot of semantics for everyday, widespread use.

I fully agree with Phil. My worry is that if this group were to define a new namespace for DCAT2 with roughly the same semantics as DCAT1, very few implementers of DCAT1 might see the need to upgrade.

This was considered in plenary meeting 2018-02-27 and resolved to retain the original namespaces
https://www.w3.org/2018/02/27-dxwg-minutes#x06