Include query parameter valid values

[cyberhobo]

A user interface can provide features like menus and auto-completion if it can get the valid values for additional parameters relative to the current query.

OpenContext provides some good examples of this. A top level query (http://opencontext.org/sets/facets/.json) provides only valid values for a few parameters (context, project, category, date range). Submit a query for a valid value for one parameter, and the result includes values for other parameters that are valid in combination with the submitted parameter, and this way a search can be incrementally refined.

We might not want pre-defined date ranges, but this approach would work well for artist and genre. Perhaps country also.

Other data consumers might not want this information or might want to avoid the cost of querying it -

[cyberhobo]

I've been thinking that the opencontext example is complicated because it delivers both valid parameter values and paged query results in one package. It might be simpler and perfectly functional to have a separate service just for getting valid parameters. So a query like

http://geodev.lib.purdue.edu/dossin/api/parameters/json?year_start=1946&year_end=1969&abstractexpress=1

might produce something like

{
    "count": 189, /* Exhibitions returned by given parameters */
    "given": {
        "year_start": 1946,
        "year_end": 1964,
        "abstract_express": 1
    },
    "valid_to_add": {
        "artist": [
            { "name": "Jackson Pollack", "value": 1, "count": 31 },
            { "name": "Franz Klein", "value": 2, "count": 12 },
            ...
        ],
        "country": [
            { "name": "France", "value": "FR", "count": 43 },
            { "name": "United Kingdom", "value": "GB", "count": 2 },
            ...
        ],
        "surrealism": [
            { "name": "surrealism", "value": 1, "count": 203 },
            { "name": "surrealism", "value": 0, "count": 171 }
        ],
        ...
    }
}

Just one of many possible ways to go, but maybe easier to implement.

[cyberhobo]

And if time is too crunched, a minimal spec would be a parameter query that returns JSON with all possible query parameters and all possible values for each (or a range for numerics like years).

This would still allow for menus in the interface, but they would include options for queries that would produce no results.

[cecois]

Ok, I returned to this and found that it actually existed (kind of) early on and I forgot about it. What I had at one point was a reach into the db's internal catalog for all table fields and I pulled out the field name, type, and comment (but only if there was a comment and at that time only for the exhibitions table). So I fixed this up a little and committed and now we're a little closer to what you need, I think, with some missing pieces still.

Now you can do http://geodev.lib.purdue.edu/dossin/api/filters/exhibitions/json and get an array of the table columns that have comments (which means I need to go in and finish writing comments for the fields -- if I limit comments to only those fields that can be used in the API it would amount to more or less a piece of what you need for making menus, I think).

...Where this falls short is in the valid values and counts request, which I'll follow up on offline.