[ckan-discuss] Resource Formats, Mimetypes etc

Wed Apr 27 13:15:48 BST 2011

On 27 April 2011 13:05, William Waites <ww at styx.org> wrote:
> Actually, just wrote this in IRC but beter to put it here.  mimetype
> and mimetype-inner force a two level hierarchy. It is very common to
> have three-levels.
>
> So considering the guidance on the wiki for format foo in a tar.gz, we
> really want gz:tar:foo, not least because people also use bzip2 with
> tar, so we could have bz2:tar:foo.
>
> If we write these out more explicitly with mime types, which we
> should, we still want a nested structure and mimetype, mimetype-inner,
> mimetype-inner-inner seems more than a little kludgy.

I was thinking of just two:

mimetype: the outer (this is here because it what's you would actually
get if you got the file)

mimetype-inner: most innermost (important because it's what you get at
the end of the day once you've unpacked -- it's the actual form of the
data you would work with).

Rufus

> Doubtless I'll be accused of over-engineering here but really what we
> seem to have is a set of nested resources, the inner resources not
> particularly having a URI.
>
> -w
>
> * [2011-04-27 12:57:16 +0100] Rufus Pollock <rufus.pollock at okfn.org> écrit:
>
> ] 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"
> ]
> ] Rufus
> ]
> ] _______________________________________________
> ] ckan-discuss mailing list
> ] ckan-discuss at lists.okfn.org
> ] http://lists.okfn.org/mailman/listinfo/ckan-discuss
>
> --
> William Waites                <mailto:ww at styx.org>
> http://river.styx.org/ww/        <sip:ww at styx.org>
> F4B3 39BF E775 CF42 0BAB  3DF0 BE40 A6DF B06F FD45
>

-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/