For some content, the most pertinent grouping would be by a date property. This would need the ability to specify a granularity (for example, group by year/decade/century)
This could be useful for works with a regular publication, like TV soaps (that generally don't have seasons) or comic-strips. Century-grouping could be useful for eg battles, elected individuals, writers etc.
A hack would be to check if grouping starts with a Pid. If not then escape the wdt: prefix allowing for more complex statements. That would in theory open up for other convenience switches based on input (e.g. year:P577) in the future.
That sounds like T224229: Grouping by property is not powerful enough for some use-cases, which is more or less tractable (mostly I’d need to make up my mind :)
I think grouping by date would be more complicated, as every other query would need to be time aware:
SELECT ?grouping (COUNT(DISTINCT ?entity) as ?count) WHERE {
?entity wdt:P31 wd:Q41960.
?entity wdt:P551 ?grouping .
FILTER EXISTS { ?entity p:P19 [] } .
}
GROUP BY ?groupingSELECT ?grouping (COUNT(DISTINCT ?entity) as ?count) WHERE {
?entity wdt:P31 wd:Q41960.
?entity wdt:P569 ?date .
BIND(YEAR(?date) AS ?grouping).
FILTER EXISTS { ?entity p:P19 [] } .
}
GROUP BY ?groupingA plain YEAR turns out to be easy enough ; however per @Ash_Crow ’s original post, users might want to group by century or month, which would be another story...
Mentioned in SAL (#wikimedia-cloud) [2021-10-28T12:38:44Z] <wm-bot> <jeanfred> Deploy 0a8e7fb (T236590)
Mentioned in SAL (#wikimedia-cloud) [2021-10-29T09:49:04Z] <wm-bot> <jeanfred> Deploy af49bab (T236590 and T273226)