I am in favour of being the least restrictive as possible with domain axioms. I would suggest that rather than "dropping those that are not needed" we could use an approach of "keeping only those that are absolutely necessary".

+1

Properties for which the domain axiom seems to be necessary are:

• For dcat:Catalog: dcat:dataset, dcat:record
• For dcat:Dataset: dcat:distribution
• For dcat:Distribution: dcat:accessURL, dcat:downloadURL (are domain axioms really necessary here?)

I do note that by removing the domain axiom from dcat:mediaType, it becomes identical to its super-property dct:format -- the only difference then being the usage note recommending IANA media types for dcat:mediaType and anything else for dct:format.

For dcat:theme it is similar, although the difference with dct:subject remains because of the narrower range of dcat:theme (skos:Concept) versus dct:subject (undefined).

+1

I agree with the idea of "keeping only those that are absolutely necessary" and for those applications that that do need more restrictions, I think they could be provided in terms of a DCAT 1.1 profiles. However, we might need to think about the implications on terms of reasoning that this added flexibility will have. Additionally, I think it would be important to link these changes to a relevant use case, and derive the requirement from that.

I also agree with Makx' proposal to drop domain axioms as much as possible. There are currently 12 non-deprecated properties in DCAT with a domain restriction (see below). Dropping the domain restrictions will make these properties more broadly reusable; although it may be difficult to think of specific use cases for them in advance.
Regarding the implications in terms of reasoning, dropping domain axioms would no longer make it possible to infer class membership from the use of the property. I think most users of dcat would expect this to be stated explicitly in the metadata.

dcat:dataset	rdfs:domain	dcat:Catalog. 
dcat:record	rdfs:domain	dcat:Catalog. 
dcat:themeTaxonomy	rdfs:domain	dcat:Catalog.
dcat:contactPoint	rdfs:domain	dcat:Dataset. #see also #95 
dcat:distribution	rdfs:domain	dcat:Dataset. 
dcat:keyword	rdfs:domain	dcat:Dataset.
dcat:landingPage	rdfs:domain	dcat:Dataset.
dcat:theme	rdfs:domain	dcat:Dataset.
dcat:accessURL	rdfs:domain	dcat:Distribution.
dcat:byteSize	rdfs:domain	dcat:Distribution.
dcat:downloadURL	rdfs:domain	dcat:Distribution.
dcat:mediaType	rdfs:domain	dcat:Distribution.

+1

As discussed in today's meeting, I have created separate issues for each of the non-deprecated DCAT properties so that the discussion on each can be recorded discretely. dcat:contactPoint already has #95 and #109

Remaining to be discussed as part of this general issue is the possible impact on tools and applications of any changes to the constraints - as discussed in part in https://www.w3.org/2018/02/14-dxwgdcat-minutes#x06

We may also need to reflect the motivation for this discussion up into the UCR tracking.

As suggested by @philarcher #131 (comment) maybe replace (or supplement) rdfs:domain and rdfs:range constraints with schema:domainIncludes and schema:rangeIncludes annotations (from schema.org)

What exactly is meant by "dropping" and "relaxing"?

The properties already are specified in a W3C Recommendation:
https://www.w3.org/TR/vocab-dcat/

Is it indended to obsolete that spec? (How would that work?)

However, there can be a lightweight profile of DCAT in a seperate namespace

... or in the original namespace, particularly if the lightweight description is strictly just 'annotations'.

I've just looked through the current DCAT vocabulary, seeing if there are any domain/range declarations that look potentially restrictive. I found very few things to worry about. That is, the ones that are present almost all seem to be entirely untroublesome. For example, it seems to me that declaring the range of dcat:distribution as dcat:Distribution is entirely sensible. Many of the properties have a domain of dcat:Dataset, dcat:Catalog or dcat:Distribution - and they don't look wrong.

Where there might be room for change - by which I mean relaxation - is in the ranges of
dcat:contactPoint (v:Kind)
dcat:landingPage (foaf:Document)
dcat:mediaType (dct:MediaTypeOrExtent)

I'm not advocating relaxation of these, just saying that these are the only ones that are currently defined that look like potential candidates for discussion. My point was only that if DCAT declares domains and ranges that can be shown to have been harmful or that are widely ignored, OK, relax them. And, in general, only apply domains and ranges where they actually help clarify the model, otherwise, leave it open. I'm not advocating relaxing rules for the sake of it.

Add in the properties that take skos:Concept as a range to my short list and I realise that the thing they have in common is that they're all properties in the dcat namespace that declare a range outside of it - and that may or may not be how they're used in the wild.

As @makxdekkers says, DCAT is used widely already. The main task is to add in the terms that usage has shown are lacking. In doing that, and in addressing new use cases, one might find a reason to add in an extra layer of semantics - no problem with that as the SOSA/SSN experience shows.

And as @arminhaller points out, domains and ranges aren't actually restrictions, rather they can allow computers to infer the type of resource. So if you see dcat:landingPage, you can infer that its object is a foaf:Document - and Web pages certainly fit that description.

Where semantics might get more tricky, as recent discussions show, is around things like PROV. That seems more like the area where an additional graph might be handy.

@philarcher - the case that triggered this discussion was #95, where a domain is provided for dcat:contactPoint which limits its re-use in the context of individuals of any other class (or more strictly, it entails that when it is used, the subject is a dcat:Dataset). Multiple domain values are combined with AND not OR, so you can't easily add further classes into the domain.

The suspicion was that there may be other cases in DCAT where an innocent looking global domain constraint would limit its re-use elsewhere, so it was agreed (in the last meeting) to create a complete set of issues for the DCAT properties to trigger evaluation of these.

That makes sense @dr-shorthair of course. My fear was that this would become a general cry to 'burn all domains and ranges' which would I think, risk throwing away those that are actually helpful.

PR #140 adds an RDF file for DCAT-schema.org alignment, which has domainIncludes and rangeIncludes annotations matching all domain and range axioms from DCAT 1.0

Of course any domain/range constraints that are dropped in the revision would be retained in the DCAT 1.0 profile - e.g. see https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat10.ttl

#130 and ID51 are the underlying motivation for this issue and the set of individual issues generated on Feb 15th

@dr-shorthair I am not sure I understand the approach. In https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat10.ttl it notes that the imported namespace http://www.w3.org/ns/dcat continues to contain all existing axioms. Under which namespace URI would the new version with modified axioms be published, and how would it refer to existing properties with different axioms?

I also noticed this line in https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat10.ttl

@Prefix dcat10: http://www.w3.org/ns/dcat10# .

This namespace is new. I do not think that I like the creation of a new namespace for the old version and the use of the old namespace for the new version.

We can defer the namespace question for now.
This RDF file is a simple approach to building a 'profile' which merely imports the current DCAT, and adds the axioms that were removed back in.
It is essentially just bookkeeping until the preferred profile mechanism is determined.

Pending the formal publication of a DCAT 1.0 profile, people can get DCAT 1.0 by using this graph.

BTW - the 'new namespace' @prefix dcat10: http://www.w3.org/ns/dcat10# . merely identifies this graph or file. There are no classes or properties in this namespace.

@dr-shorthair I am still trying to understand how changing domains and/or ranges would work in terms of RDF schemas.
The file at https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat10.ttl owl:imports <http://www.w3.org/ns/dcat>. Doesn't that mean that it imports all the axioms in the RDF namespace? How could a new profile, e.g. DCAT 1.1, reuse the URIs in the existing namespace but with different domain/range axioms?

It imports every triple (axiom) in dcat 1.1, and adds additional axioms (i.e. the ones that were removed relative to dcat 1.0).
Since we have added nothing to dcat 1.1 yet, at present you end up pretty much what we had before - i.e. all the axioms that were in dcat 1.0.

Moving forward it'll likely get more complicated, but for now the dcat10 file is mostly bookkeeping, in a formalized way.

See https://www.w3.org/TR/owl2-syntax/#Imports

One open issue (#125) and a related issued (#313) remain outstanding at publication of 2PWD, so this issue removed from the milestone. All others have been completed for 2PWD

Remaining or associated work here (#113, #125, #313 #317) is either due for closing or future work, so will mark this as due for closing as well since the specific issue does seem to have been addressed.

Specific open aspects are registered in other open issues which are linked to this issue, so this can be closed without harm.