I was investigating implementing (CA) sets for the OAI set facets, but that looks like a big task at first glance.
I was then looking as an alternative to use the (oai) setFacets sets through the existing attributes facets implementation that could then be populated/manipulated from (CA) sets bulk editing, by having for instance plain text or listitems as facet content.
I'm seeing two issues at the moment.
The first is that facets used appear to be browsed only on non-"" query parameter in else condition of query= .* if-branch in the facet-if-condition does a search instead of browse, without applying the chosen set to it. That feels inconsistent/off; both "all" and "some query" are facettable, and the available facets are already the result of the query itself.
It appears(?) that I can fake "*" with "%" and have the facet somewhat all-like. Having a real query (like "query=apple") with a real facet (set(Spec)=12345 ~ redPill) seems to behave like an OR rather than AND (endlessly debated what should be the better default).
A bigger issue to me is that the set facets get not the most intuitive identifiers attached; that makes automation of harvesting from the other end a bit more labour intensive (you have to do a ListSets and parse the response for the non-obvious identifier).
When I add to a textfield "redPill" for 20 items from set A, and "bluePill" for 30 items of set B, they seem to get the first value_id of each series (2172230,2172250 - and so when the item with 2172230 would loose the redPill, tomorrows redPill id might be 2172231).
To have more predictability I was attempting to extend the current implementation with selectable keys (id|label|idno), so that you have a little bit more liberty in the upfrond selection (for instance text fields by the label - setSpec=bluePill,setName=bluePill, or listitems by their idno - setSpec=FF0000, setName=RED).
for instance
oai_facet = {
type = attribute,
element_code = oai_current_text,
useIdentifiersForSets=label,#id|label|idno
we do use "query = set:whateve_set_identifier" currently, but that make us have to change the config files directly for each use-case (also labour intensive, with or without rebuilds, singleton-ish or need for duplication of OAI's to have multiple sets harvested,...)
Do you see value in these features (ca sets as oai sets, both * and non-* facettable, more predictable identifiers for sets)
It feels a bit like introducing dynamic queries (like query=oai_current_tag:July2026Highlights); that too (overriding query from querystring) would be a nice thing although not OAI-PMH compliant (but also non-breaking :p)
