dcat:mediaType - check constraints

[dr-shorthair]

In DCAT v1 the property dcat:mediaType is axiomatized

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

1. Verify that the range is appropriate and necessary
2. Verify that the domain is appropriate and necessary (see Review global domain axioms on dcat properties #110)
3. Consider whether any guarded constraints (using owl:Restriction) should be introduced (see Use owl:Restriction constraints to bind DC properties to DCAT classes  #105)

[makxdekkers]

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?

[akuckartz]

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.

[akuckartz]

Maybe this can be helpful:

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

[dr-shorthair]

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

[dr-shorthair]

Proposal:

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

[nicholascar]

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

[makxdekkers]

@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.

[makxdekkers]

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?

[dr-shorthair]

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.

[makxdekkers]

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.