[ckan-discuss] Resources formats

[Rufus Pollock]

On 25 March 2011 15:48, Stefano Costa <stefano.costa at okfn.org> wrote:
> Hi all,
> a bit of bikeshedding for a quiet Friday afternoon..
>
> I am currently translating to Italian the short guide to creating a data
> package in CKAN. The wiki page
> http://wiki.ckan.net/Creating_and_editing_Packages deals with formats
> using MIME types and other conventions, but actually the edit form shows
> the user with simpler strings (CSV, RDF, XML).

Yes since most users don't have a clue what a mime-type means but do
understand file extensions :)

> The problem I see is that automated retrieval is made more difficult by
> using anything that is non-MIME (including "index/html" perhaps), at
> least if there is no functionality in the clients to support such
> syntax. I'm especially thinking of datapkg.

You are right. There's a trade-off here between formats that are
precise and machine usable and formats users can enter. One classic
solution would be do some kind of lookup solution (using something
ajax-y or just a simple select) where users are presented with a
simple list of things they understand but in the background we save
the proper associated mime-type.

Of course this doesn't address the funky extra stuff we are doing such as:

* Having "kinds" of resource (api, file, index, example, ....) e.g.
example/rdf+xml, index/html, api/sparql etc
* Having nested resource: zip:csv, gzip:application/json etc

For the first of these I think we should move away from abusing the
format field in this way and have a separate kind field on resources
(we now support arbitrary k/v's on resources). On the latter I think
we want to think hard about what we do (i.e. do we adopt a policy of
focusing on the innermost resource type when registering the resource
for search or for use in datapkg).

Rufus