[ckan-discuss] Resource Formats, Mimetypes etc

William Waites ww at styx.org
Wed Apr 27 13:05:13 BST 2011


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.

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



More information about the ckan-discuss mailing list