-
Notifications
You must be signed in to change notification settings - Fork 3
Facet display and functionality
Usage of terms
- facet: a whole facet such as category or occupation
- filter: a value / filter with a facet
- By default all the filters are unselected, unless the user arrives with a 'canned query'
- All facets use AND logic by default (ie. they filter down the result set)
- The position of each facet remains the same regardless of selected filter
- The selected values within each facet should remain (post selecting/display of results)
- Ordering of values within each fact block should be by count
- Selecting filters of one category influence/filter the other filters of the other categories
- Category
- Date
- Maker
- On display (i.e. museum location) [1]
- Object type
- Place
- Images [Commercial : Non-Commercial] [2]
- User (note: it is likely that this will be dropped for launch; but for testing it would be useful to have)
[1] On Display, should list the following filter values
- Science Museum
- National Railway Museum
- National Media Museum
- Museum Science & Industry
[2] Images, this facet should allow users to restrict/filter the result set to a)results with a CC licensed image ie. non-commercial or b) those results with an image, but that isn't CC licensed ie. commercial
- Commercial
- Non-Commercial
- Occupation
- Date (born / died) [1]
- Place born
- Organisation / Person
[1] there should just be one date selector (to-from) that matches if either the born or died date falls within it's range, ie. was this person or company active between these two dates
- Archive ('fonds' name) [1]
- Format
- Date
- Creator
- Type
- Place
- Organisation
- Images (i.e. as above re. Non-Commercial / Commercial mapping to records with CC licensed image)
[1] Archive - I suspect these will be unusable due to length, but be interesting to see for testing.
The facets are build based on a search of a user. The search use a multi_match query and a filter based on the type of the documents : 'agent', 'archive', 'object'.
Depending on which category is selected the results are filtered by type (agent, archive or object) by using a post filter query. The post filter query filter the list of results without breaking the aggregations. This allow us to keep the right count of result per category.
Most of the aggregations used are filtered aggregation: The list of results is filtered before creating the aggregation.
All the aggregations which belong to total per category are first filter by type. Only the results with the type agent, archive or object are kept:
filter: {
bool: {
must: filters.type
}
},
aggs: {...}
where filters.type is [{terms: {'type.base': ['agent', 'archive', 'object']}}]
aggs: {
all_total: {
terms: {field: 'type.base'}
}
}
This aggregation is a terms aggregation, it will create a buckets property containing the number of document per type
The example describe how the aggregation is build for the people type but it is the same logic for the other types
people: {
filter: {
bool: {
must: filters.people.concat([{term: { 'type.base': 'agent' }}])
}
},
aggs: {
people_total: {
value_count: {field: 'admin.id'}
}
}
}
The people aggregation is first filtered by the selected filters on people and by the type agent. Then the value_count aggregation people_total just return the number of documents after the filter is applied
Users have the possibility to reset the filters of each facets. The clear facets links are just links of the current url and query parameters but with the facet query parameter excluded from the url:
- 1 collect all the name of the facets of the current page ("filter[occupation]", "filter[type]"...)
- 2 for each of the facets name create a url based on the current on but which doesn't have anymore the query parameter of the facet
- 3 for each facet display the right link with handlebars