RE: [dxwg] dcat:mediaType - check constraints

Stephane,

 

You absolutely right about the confusion that is created by having two properties that do the same thing but do it slightly differently. See https://github.com/SEMICeu/DCAT-AP/issues/26. 

 

However, the way that Project Open Data uses dcat:mediaType with a string is in violation of DCAT; I don’t think there can be any doubt about that. The example in section 4 (https://www.w3.org/TR/vocab-dcat/#vocabulary-overview) is wrong, but there is a clear statement at the beginning “This section is non-normative“. The definition at https://www.w3.org/TR/vocab-dcat/#Property:distribution_media_type is normative.

 

As far as I see it, we can’t change the range from the current dct:MediaTypeOrExtent to rdfs:Literal without breaking existing implementations that do the ‘right’ thing. At most, we could decide to remove the range axiom which would allow both types of usage. 

 

Of course the same argument could be used for all DCAT properties, as for all properties in all Linked Data vocabularies. Lots of people do not worry about the distinction between ‘strings’ and ‘things’. Schema.org even makes this explicit:

 

“We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can.” http://schema.org/docs/datamodel.html 

 

But is that the way we want to go?

 

Makx.

 

 

From: Stephane Fellah [mailto:stephanef@imagemattersllc.com] 
Sent: 15 February 2018 19:55
To: public-dxwg-wg@w3.org
Subject: Re: [dxwg] dcat:mediaType - check constraints

 

The range of the property of dcat:mediaType has been a source of confusion in the DCAT specification, as the basic example section 4.1 shows the dcat:mediaType modeling the MIME type as a string, but the spec defining the range as dct:MediaTypeOrExtent  and as a subproperty of dct:format.  As a consequence of this confusion, we see two forms of encoding the mime type today in the industry. Project Open Data specification (which is based on DCAT) defines the dcat:mediaType range as a string (https://project-open-data.cio.gov/v1.1/schema/#distribution-mediaType). 

 

I think dcat:mediaType range should be defined as a string (because it is simple and already used out there) and we should keep dct:format to capture format information as an object (Shape, GeoJSON, CSV, GeoPDF, GML, XSLT) , which can also provide information about version, etc.  This should also not make dcat:mediaType as subproperty of  dct:format. The updated specification needs to address this ambiguity by having a clear description of their usage. 

 

On Thu, Feb 15, 2018 at 3:43 AM, makxdekkers via GitHub <sysbot+gh@w3.org <mailto:sysbot+gh@w3.org> > wrote:

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?

-- 
GitHub Notification of comment by makxdekkers
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/127#issuecomment-365859856 using your GitHub account





 

-- 

Stephane Fellah

Chief  Knowledge Scientist

Image Matters LLC

Office: +(703) 669 5510

Cell: 703 431 9420