ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter 140,News section on front page,ckan,,ckan-backlog,enhancement,,new,2009-10-07T08:02:21Z,2010-02-08T10:32:39Z,"Have a news section (suggest as a sidebar item). News section will link to latest 3/4 blog posts on CKAN from blog.okfn.org. Details: * Suggest pulling via rss or similar. * Will want to cache this ... Cost: 4h?",rgrp 143,Most active users listed on homepage,ckan,,ckan-backlog,enhancement,thejimmyg,assigned,2009-10-08T13:59:33Z,2011-08-03T11:53:01Z,Display league of users' recent activity on homepage.,dread 235,Resource format normalization and detection,ckan,,ckan-v1.9,enhancement,tobes,assigned,2010-01-18T15:13:24Z,2012-06-25T12:33:44Z,"Try to gather proper MIME information for all package resources in CKAN. This is a shared ticket with dcat-tools (https://bitbucket.org/pudo/dcat-tools), i.e. opendatasearch.org. This can then also be used by ckanrdf, the CKAN RDF conversion service. Sub-tasks: * Create a Google Spreadsheet with two Worksheets: ""MIME-Mappings"", i.e. ""CSV"" -> ""text/csv"" and ""Name mappings"", i.e. ""text/csv"" -> ""Comma-Separated Spreadsheet"". * Collect and map surface forms from all CKANs * Access this via Swiss and apply, store as a PackageResource extra field pending #826 (Resource extras). * Add heuristics for format auto-detections: * Map well-known file extensions * Recognize obvious magic (Zip, Tar) * Peek into Zipfile/Tarfiles * Define a convention for generic data types (many CKAN packages have only ""Spreadsheet"" defined, either detect specific type or set MIME to */tabular-data or similar) * See also: #816 (Autocomplete for the resource format field)",dread 250,RDF link in Atom feed,ckan,,ckan-v1.9,enhancement,icmurray,assigned,2010-02-18T15:41:35Z,2012-06-25T13:37:10Z,Add link to RDF representation of a package in our Atom feed.,dread 253,Package relationships,ckan,,ckan-backlog,enhancement,,assigned,2010-02-22T16:05:21Z,2012-06-15T15:38:46Z,"= Overview = Functionality to formally associate packages. We see a need for specific parent-child, inheriting or dependency relations. Not only should this help navigation between packages in the web interface, but it also provides a mechanism to automatically pull dependencies when downloading a data package, in a similar manner as we see in software package management. = Examples = 1. There are 27 packages in data.gov.uk to do with the Data4NR's Health Poverty Index. There is currently no common link between these, unless you search for 'HPI' (which also brings up House Price Index), or look under tag 'health' (which also has 600 other results). There should be a link on each HPI package page to navigate to the other 'sibling' HPI packages, and to a 'root' package that has info about the set. This could be partially achieved using the existing tag or group concepts, but a more explicit/official/obvious marking of their relationship could be beneficial. 2. In ckan.net is freedict, a collection of translation dictionaries. You could make each dictionary a child package and use this system. But it would probably be better to make each dictionary a different resource in the same package. (There are other ideas to denote a resource as the data making up a 'portion' of package, or a 'whole' of the package, to help people downloading datasets in the software package style.) 3. OSM has had some Naptan data imported (bus stops), with special permission - i.e. a more liberal license. It would be useful to show this link on both OSM and Naptan packages in CKAN: OSM 'derives from' Naptan with a comment about the license change. I'm not sure this is useful to an automatic download or use of these datasets, but may aid exploration on the CKAN website and understanding the provenance of the bus stop data on it. 4. IPCC collection of data linked / mirrored. Not sure if there are useful relationships here? 5. Dracos gets postbox locations from crowd sourcing and OSM. We could say Dracos 'derives from' OSM. See more examples discussed here: http://trac.ckan.org/ticket/253 = Implementation = This is split into four tickets: * Model: ticket:254 * Read in WUI: ticket:255 * Edit in WUI: ticket:256 * API: ticket:257 No need for write access to be provided API for the moment. This ticket also encompasses ticket:169 (Package derivations) and ticket:176 (Package dependencies).",dread 256,Package relationships - 3. Edit in WUI,ckan,,ckan-backlog,requirement,,assigned,2010-02-23T12:36:01Z,2012-06-15T15:38:34Z,"WUI: * Editable as part of package or separately? (e.g. like authz) * Do we normalize to only one type name of the pair? * Do we allow create of relationship from both ends (e.g. only from dependency to dependent or either way?) ",dread 277,Set some config options / settings in WUI (extension),ckan,,ckan-backlog,enhancement,zephod,assigned,2010-03-22T16:21:01Z,2011-10-10T11:45:21Z,"== Use case == As a ckan administrator I want to easily change options about the CKAN install. == Implementation == === Settings to be in DB === Suggested: {{{ ## Title of site (using in several places including templates and