Dropping the domain axiom makes dcat:mediaType identical to dct:format of which it is a subproperty. However, the usage note for dcat:mediaType restricts its use to IANA media types, so maybe the range need to be tightened to a new class dcat:IANAMediaType?

I always found the properties for media types and formats and especially the range "dcterms:MediaTypeOrExtent" confusing. I am in favor of improving that situation.

Maybe this can be helpful:

Ontology for Media Resources 1.0
W3C Recommendation 09 February 2012
http://www.w3.org/TR/mediaont-10/

The domain axiom appears relevant - unless it is required to sometimes say something about a dcat:CatalogRecord.

Proposal:

1. leave domain alone
2. change range to dcat:IANAMediaType or dcat:MIMEtype

+1 to changing to dcat:MIMEType (capital ‘T’?) as this will be better understood by web devs than dcat:IANAMediaType

@dr-shorthair Although I admit that I am the one who suggested the range "to be tightened to a new class dcat:IANAMediaType", on second thought, I think this would not be a good idea as it could break existing implementations. If someone had implemented DCAT using dcat:mediaType and used something that is not an IANA media type as its object but still a valid dct:MediaTypeOrExtent, that implementation would violate the spirit but not the letter of the specification. It could only be accused of not respecting the SHOULD in the Usage Note, which is a very weak axiom, if you could call it an axiom at all. However, after the suggested change, that implementation would violate the letter of the rule. I don't think we want that.
I have always used the rule that you may 'widen' the scope of a property, e.g. by making the domain or range broader, but that you should not narrow domain or scope, as this is not backward compatible.
In this case, then, I would be in favour of adding more guidance information to the specification rather than fiddling with the range.

As a more general comment related to dcat:mediaType and dct:format is that there are implementations that use strings as the object of these properties. @arminhaller referred to an example at data.gov.au in #104 (comment), where strings like "HTML" (in dct:format) and "text/html" (in dcat:mediaType) are used. Maybe there should be a statement in the Usage Note of both properties that explains that the objects must be URI references?

dc:format may have a string as its value.
The range of dct:format is dct:MediaTypeOrExtent which is an RDFS Class.
So I'm not sure if a Literal can appear as the value.

The property is defined in the RDF schema as:

dcat:mediaType a rdf:Property, owl:ObjectProperty

So it cannot have a Literal as value.

Makx.

The examples listed in the current specification use Literal strings (dcat:mediaType "text/csv"). At least for MIME types this is the most common form and there are enough tools around to parse these strings. Forcing people to use URIs instead will not work because it only adds complexity for most applications.

For dct:format this might be different because there is no canonical registry to look up strings such as "HTML". I think Literal for dcat:mediaType and URI for dct:format is the most practical solution.

@nichtich The examples in the 2014 specification are wrong. They are in section 4 which is non-normative. I created an issue for that at #170.
dcat:mediaType has a range of dct:MediaTypeOrExtent, identical to the range of dct:format, and this cannot be a literal text string.
I would agree that it could have been done differently, and that it would have made it easier to use. However, the practical solution that you propose has consequences for backward compatibility which we need to be careful about.

1. Is there a reason for the range to be dct:MediaTypeOrExtent ?
   I suggest it would be better tightened to dct:MediaType
2. There does not appear to be a content model defined for dct:MediaType .
   What is recommended usage? Here's a couple of options:

#Option A:
      dcat:mediaType [
          rdf:type dcterms:MediaType ;
          rdfs:isDefinedBy <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
          rdfs:label "application/rdf+xml" ;
        ] ;

or

#Option B:
      dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;

Or perhaps using the conneg-equiped versions:

#Option B:
      dcat:mediaType <https://w3id.org/mediatype/application/rdf+xml> ;

+1 for option B as we already use it like this in Czech National Open Data Catalog, as discussed in #259.

1. They are the official URIs for Media types
2. Since we wrote to IANA about this (both from DXWG and the Czech side), chances are they are eventually be published also in RDF. But the fact they are not published in RDF now does not mean we cannot use the URIs. If 2 data sources use these URIs, they become interoperable regardless of this.
3. This is currently recommended in DCAT-AP v1.1

Sadly IANA asked me "what is RDF?" when I asked

But what about the first question:

Is there a reason for the range to be dct:MediaTypeOrExtent ?
What is the OrExtent doing there?? Makes no sense to me. It would be better tightened to dct:MediaType

dcat:mediaType
  rdf:type owl:ObjectProperty ;
  rdfs:domain dcat:Distribution ;
  rdfs:range dcterms:MediaType ;
  rdfs:subPropertyOf dcterms:format ;
.

@dr-shorthair I agree with the restriction to dct:MediaType. I am not sure what the Extent could be and I have never seen a usage other than a Media Type.

The current range declaration says that whatever is the object of the property is a dct:MediaTypeOrExtent, which is fine with me. On the other hand, I don't think a change to narrow the range is going to break anything. The usage note actually instructs implementers to use IANA-defined media types, and all of those can reasonably be considered to be instances of dct:MediaType.

Resolution proposed in #304

Resolved https://www.w3.org/2018/07/19-dxwgdcat-minutes#x06