[ckan-discuss] Tag_count per group / packagecount in grouplist
friedrich at pudo.org
Tue Oct 12 22:21:40 BST 2010
On Oct 11, 2010, at 8:24 PM, Martin Borman wrote:
> We're integrating CKAN in a seperate website using the API (version 2). We've encounterd some difficulties. Perhaps one of you can help us out?
> Is it possible to get a tag-list, with count, for a specific group, using the API?
> For example, we get the packagelist for Delft, using $locator/api/2/search/package?groups=gemeente_delft&all_fields=1
> To show a taglist alongside this resultset we've only came up with a pretty inefficient solution; Using the received JSON we count the tags and build the list by examining each dataset. For the catalog as a whole we can use $locator/api/2/tag_counts. Is there some way to use this method as well for a specific group, e.g. $locator/api/2/search/package?groups=gemeente_delft&tag_counts=1 ?
> The same issue we encounter when building a grouplist. It's no problem at all to show a grouplist. We want to show a packagecount per group as well. The only way to achieve this seems to be to request a jsonfile per group in the background, and extract the packagecount. When you paginate per 30 items, this means 30 requests to the CKAN API. This seems very inefficient to us and perhaps you know a better solution?
As for as I'm aware there is no simple way to gather the counts you're looking for at the moment.
It seems to me like what you're trying to build is very similar to faceted browing. The numbers you're asking about would then relate first to the entire system and later to the result set of a specific search query (i.e. a group:foo query). We're planning to have a first go at putting this into the main CKAN this weekend (there's already a prototype implementation on iati.ckan.net), and while I have not considered this before, it would make perfect sense to include that data into the REST API (v.2).
So if there's no protest from anyone, I'll try to implement this both in the WUI and in the REST API in a way that is non-intrusive to the current API. To find out how we can best help you:
- is it still ok for you to have this available in production in 2-3 weeks?
- would you be willing to help us spec this out as a "test customer"?
More information about the ckan-discuss