Aggregation
Aspects can be assigned a different slice-and-dice role, in order to perform aggregations in a similar way to pivot tables or MDX queries.
Let us take, for example, a hypercube containing the us-gaap:Assets of all DOW30 companies reported for a full fiscal year:
[Public datalake] Aggregation
curl -X GET "http://secxbrl.28.io/v1/_queries/public/api/facts?entity-tag=DOW30&xbrl:Concept=us-gaap:Assets&xbrl28:FiscalPeriod=FY&token=c3049752-4d35-43da-82a2-f89f1b06f7a4"
Let us now specify an aggregation function, say, sum. Nothing happens of course, because the dicers, by default, are exactly primary keys, so that there is only one fact per cell.
[Public datalake] Aggregation
curl -X GET "http://secxbrl.28.io/v1/_queries/public/api/facts?entity-tag=DOW30&xbrl:Concept=us-gaap:Assets&xbrl28:FiscalPeriod=FY&aggregation-function=sum&token=c3049752-4d35-43da-82a2-f89f1b06f7a4"
But now, let us change the entity and period (implicit dicers by default) to be slicers, using the dimension::category=slicer parameter:
[Public datalake] Aggregation
curl -X GET "http://secxbrl.28.io/v1/_queries/public/api/facts?entity-tag=DOW30&xbrl:Concept=us-gaap:Assets&xbrl28:FiscalPeriod=FY&aggregation-function=sum&xbrl:Period::category=slicer&xbrl:Entity::category=slicer&token=c3049752-4d35-43da-82a2-f89f1b06f7a4"
We now see that all the facts are in the one and same cell (Assets concept, and USD unit), aggregated to one single fact.
Let us know make the xbrl28:FiscalYear aspect a dicer to group these aggregations per year. We now get one fact per year that sums the assets of the DOW30 companies (note, this is assuming that they all used that same us-gaap:Assets concepts, which may not apply).
[Public datalake] Aggregation
curl -X GET "http://secxbrl.28.io/v1/_queries/public/api/facts?entity-tag=DOW30&xbrl:Concept=us-gaap:Assets&xbrl28:FiscalPeriod=FY&aggregation-function=sum&xbrl:Period::category=slicer&xbrl:Entity::category=slicer&xbrl28:FiscalYear::category=dicer&token=c3049752-4d35-43da-82a2-f89f1b06f7a4"