[ckan-discuss] Resource Formats, Mimetypes etc

[Richard Cyganiak]

On 27 Apr 2011, at 13:05, William Waites 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.

How common is it? How common is two levels, even? How many of the more-than-one-level resources contain multiple files of different media types?

These questions *can* be answered accurately by analysing the resources currently registered in CKAN. Decisions should be made based on such data whenever possible.

Best,
Richard




> 
> 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.
> 
> 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
> 
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss