[ckan-discuss] Resource Formats, Mimetypes etc

Rufus Pollock rufus.pollock at okfn.org
Wed Apr 27 12:57:16 BST 2011

On 25 April 2011 08:01, Egon Willighagen <egon.willighagen at gmail.com> wrote:
> On Thu, Apr 21, 2011 at 8:03 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>> * Straightforward file extensions formats e.g. 'csv', 'xls'
>> * Different 'kinds' of resource (api/file/examples/service) api/sparql, service
>> * Nested resources (this is zipped json = zip:json)
> I use these three.
>> Suggested changes:
>> 1. Introduce a kind field on Resource which contains api/file/example/
>> (rather than having this in format)
> OK.
>> 2. Introduce mimetype on Resource which is a proper mimetype (and
>> should be mimetype of 'outer' object e.g. zipfile for zipped json)
>> 3. Format is the 'unparsed' version that is user-provided. Still keeps
>> conventions for nested and 'or' resources and its simple approach
>> (e.g. can just csv or xls)
> Can you give an example of how, for example, zip:n3 would look like in
> the new formalism?

In 'new formalism' would not be different for user of web interface:

# or, possibly application/zip:application/n3 (for those being really precise)
format: zip:n3

# optional as this is default kind
kind: file

# you wouldn't provide the mimetype probably (we'd 'guess' it for you)
[mimetype: application/zip]

# i'm wondering whether we should have mimetype inner
[mimetype-inner]: application/n3

> :some CKANEntry
>    :resourceMimeType "application/zip" ;
>    :format "application/n3" .
> Like that?

Yes, basically though there would also be:

     :resourceKind "file"


More information about the ckan-discuss mailing list