PR22 - Remove dcat:mediaType and only use dct:format

10/03/2015

Description

From: http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile/2015-March/000128.html

Using both dcat:mediaType and dct:format is confusing. We recommend that you only use dct:format and that the range are strings that are IANA recognized media types.

Proposed solution

Remove dcat:mediaType and only use dct:format

Component

Code

Category

improvement

Comments

Tue, 24/03/2015 - 19:59

Proposed resolution: investigate use in existing applications. Reject if dcat:mediaType is being used in practice.

Tue, 24/03/2015 - 23:44

Leaving aside whether to keep or not dcat:mediaType, I wouldn't be in favour of using only media types registered in IANA. We have a number of examples of widely used media types that are not yet registered in IANA. See, for instance, the INSPIRE media type register, which list the main formats used for data available through the INSPIRE infrastructure:

http://inspire.ec.europa.eu/media-types/

 

And another example is given by the URI register of file formats operated by W3C:

http://www.w3.org/ns/formats/

Personally, I would stick to the current DCAT-AP recommendation of using the file type URIs available in the Metadata Registry of the EU Publications Office:

http://publications.europa.eu/mdr/authority/file-type/

They provide a greater level of flexibility wrt the IANA media types, for the reasons said above.

If there's anyway the need of using (also) IANA media types, then we should keep dcat:mediaType, which is exactly meant to be used in this specific case - see:

http://www.w3.org/TR/vocab-dcat/#Property:distribution_media_type

Wed, 25/03/2015 - 23:29

I agree that limiting the use to only recognized IANA mediatypes may not be acceptable in some cases. 

(Although, according to RFC 2046/RFC 4288 it should be quite simple to register things in the vendor or personal trees if the standard tree is to challenging. In addition there is the unregistered option, i.e. the x- tree that is in use by the INSPIRE infrastructure.)

 

But, we should still be able to rely on mediatypes (as shown by the list in use by INSPIRE).

The current suggestion to use the file-type of the Metadata Registry of the EU Publications Office is problematic as there is no connection to mediatypes at all. Applications that know about mediatypes needs to maintain their own mapping.

 

I would prefer that something so important such as mediatype is actually interoperable with other standards rather than reinvented specifically for DCAT-AP (as is the case with the file-type vocabulary which is in fact a SKOS concept scheme which does not at all feel like something that fullfills the dct:MediatypeOrExtent class indicated by the dct:format). Also the amount of concepts (corresponding indirectly to mediatypes) seems to be rather arbitrary. 

 

Regarding compatability with DCAT:

1) Using mediatypes directly as literals is what is done in the examples.

2) DCAT says that dcat:mediaTypes should be used for IANA mediatypes and for dct:format for indicating the "file format" in other cases. I would re-interpret DCATs written "IANA mediatypes" rather as "following the RFC 2046/RFC 4288 specification" which would include also the x- tree.

 

Hence, I think this the suggestion I made originally should be amended and not read "IANA mediatypes" but "mediatypes acording the RFC 2046/RFC 4288 specification". Also, if it is important to follow DCAT very closely, I think recommending to use only dcat:mediaType (instead of only dct:format as suggested before) works equally well. The important thing here is to minimize confusion and make it easier for applications (developers) to follow the specification and provide added value based on information expressed according to principles outlined in DCAT-AP.

Thu, 09/04/2015 - 21:01

At Publications Office there is a distinct use of dct:mediaType (technical view on the file format using mdr:file-type) and dct:format with a more human oriented information about the file format or data delivery channel and with a new controlled vocabulary mdr:product-form.

Thu, 16/04/2015 - 13:34

Let me add that the mediatype exists actually in XML distribution of the File types authority table, but not in the SKOS distribution:

<internet-media-type type="application" sub-type="zip">application/zip</internet-media-type>

We will be releasing soon a rich RDF format (SKOS-AP-OP (euvoc)) of our authority tables that contains all elements contained in the XML.

As Jean has mentioned, we have released a table called "product-form" for the different manifestation types.

This list is work in progress. We are currently adding new concepts requested by the EU ODP.

 

Wed, 22/04/2015 - 22:25

Both properties will continue to be used.

Mon, 27/04/2015 - 16:50

The content of this field is kept private and will not be shown publicly.