Re: ISSUE-12 (valuesForDataFormat): What values to use to describe formats of dcat:Distribution? [DCAT]

On 12-01-26 10:45 AM, Government Linked Data Working Group Issue Tracker 
> ISSUE-12 (valuesForDataFormat): What values to use to describe formats of dcat:Distribution? [DCAT]
> Raised by: Fadi Maali
> On product: DCAT
> Raised in the original eGov wiki where it is Issue 42

I'll try to address the issues here and combine the ones from issue 27 [1].

If we put aside the simplest option for a moment:

0) ex:download1  dcterms:format "text/csv".

We have the following:

1) bnode case (mentioned in issue 27).

2) URIs for MIME types [3] (mentioned in issue 27).

3) File types [4] (mention in issue 27).

Options 0, 1, and 2 are at odds with formats that are not standardized.

"1. some formats like ESRI shape files do not have a standardised MIME 
type." [2] is dealt with by creating "a few key ones fairly quickly" [1] 
with option 3 above, and /maybe/ get away with it in option 1 without 
specifying rdf:value.

Option 1 is not preferable because a) it is a bnode mess (IMHO), b) 
excessive work, and c) it can be achieved with option 2. I don't find it 
to be much of an improvement.

"2. Do we use 
URIs("") or the 
textual description("text/csv")?" [2] is once again at odds with formats 
that are not standardised.

I believe it is safer and easier to go with either option 0 (at worst 
case, something like Shapefile for dcterms:format is "Shapefile") or 3.

I favour option 3, provided that we do some homework and gather a list 
of formats that are currently published in the wild, and mint up those 
URIs e.g., . Naturally, there is 
a maintenance cost there, and it still doesn't really solve the 
format:media_type . It does however put less load on the publisher when 
new media types comes available, where they don't have to update their 
data. And, I think that's fairly important.



Received on Thursday, 9 February 2012 17:54:07 UTC