Yes it's a 1:1 match. There is also an AI summary for each cluster (key). And a global AI summary for the whole conversation:
{
"metadata": {
"aiSummary": "People discussed city park plans—some wanted more green space, others more parking. Consensus grew around adding trees without cutting access."
},
"clusters": {
"0": {
"aiLabel": "Maximalist",
"aiSummary": "Maximalist embraces excess, complexity, and bold expression—favoring richness over simplicity in art, design, or lifestyle."
},
"1": {
"aiLabel": "Green Space Advocates",
"aiSummary": "Participants supported expanding green areas to enhance community well-being, biodiversity, and environmental sustainability."
},
"2": {
"aiLabel": "Practical Access Supporters",
"aiSummary": "This group prioritized parking and accessibility, emphasizing the need for practical infrastructure alongside beautification efforts."
}
}
}
I wonder if this best fits in consumer code, as regular CSV manipulation? python ecosystem is very good at csv's even without extra packages, since csv package is part of standard lib.
Here's the pandas version: https://gist.github.com/patcon/baf04d76b688ae30b7532e2cda71822f
Or the csv version: https://gist.github.com/patcon/e244968be5782575c1a70ae8f71a8179
This doesn't feel to me like it belongs in codepaths of the library that exports the polis format 🤔 Do you feel differently?
EDIT: Or alternatively, what if we added helpful functions to support this? Or if we documented these sorts of post-processing steps in example notebooks?
Generally I would have agreed that library consumers do their post-processing later, but I am not here. Why? Because it's far from trivial to know exactly WHERE to store this data WITHOUT breaking backward compatibility for tools that consume pol.is reports, which is one of the core goal of this repo (reproducting pol.is but opening up for new explorative work).
That's why I suggest an easy way, built-in the library, for library consumers to add these custom data.
Like I said we don't need nor should we do anything Agora-specific.
The export function could take these optional params:
- any key:value associated uniquely with a given cluster key ("0", "1", "2"...etc) so it will write it in an appropriate section of the report without breaking backward compatibility and in a way that will be standard for everyone using reddwarf.
- any key:value associated more globally with the whole conversation without breaking backward compatibility in a way that will be standard for everyone using reddwarf.
This suggestion seems perfectly in line with the following Goal of red-dwarf in the README: "Re-usable. It should be easily used in contexts in which its original creators did not anticipate, nor perhaps even desire."
as well as the following from polis-community's Vision: "Plurality over uniformity: Welcome diverse visions and use cases rather than enforcing a one-size-fits-all approach."
Re-ticketed from #78 (comment)
Am I summarizing in a way that does this justice? (feel free to edit my text if you have that repo permission! 🙏 🙂 )
Discussion Summary
@nicobao [original comment]
@patcon [original comment]
@nicobao [original comment]