There are a few considerations at play here with regards to building your charts that lead to different approaches when it comes to deciding how to represent your data.
One point up front about charting in Workshop is, as you've observed, the chart expects you to aggregate the granular per-object data to create each data point of your visualization. If you want to instead draw some feature of the chart (a dot or bar) per object, then you'll need to select an appropriately narrow bucket size. In this case, if you have one object per product per month, then choosing a granularity of monthly or less should result in having one data point per object.
As for options related to deriving the average, let's look at three approaches:
- Temporal Metrics Schema
Creating an ontology with a primary object (i.e. the "Product") and then a linked object type for storing values of metrics about that object (i.e. the "Product Metrics") can be a flexible approach that works well with Workshop and Quiver charting expectations.
Consider a modification of your original granular schema like this:
Product | Timestamp | Value | Metric Type
P1 2021-01 13.00 Monthly Price
P1 2021-02 13.50 Monthly Price
P1 2021-03 15.00 Monthly Price
P1 2021-04 14.50 Monthly Price
P2 2021-01 3.00 Monthly Price
P2 2021-02 3.50 Monthly Price
P2 2021-03 5.00 Monthly Price
P2 2021-04 4.50 Monthly Price
P1 2021-03 14.00 Quarterly Average
P2 2021-03 4.00 Quarterly Average
...
This schema is quite flexible and robust; you can easily add new metrics later, or even use a tool like Taurus to let users define their own rules to generate metrics that fit into this schema. It has the advantage of storing the metric type as data itself, which means that in your Workshop app, for example, you can let the user choose, using a Filter List widget, which metrics to display on a chart.
This pattern also ensures consistency of what the date "means" when presented to the user. Having, for example, a quarterly average pre-calculated means that every user will get the same information from reviewing the chart, regardless of what time period they filter to, whereas a dynamic average based on the user's selection could lead two different users to quite different conclusions based on how they chose to filter the data.
And finally, for this pattern, it becomes quite easy to show the chart itself, since you simply choose to plot the filtered object set of metrics and choose the "Metric Type" as the series property, bucket by a small granularity (say "Day") and have the chart interpolate any gaps. This means that even aperiodic metrics along with metrics recorded at different periods can all render on the same chart.
This pattern is somewhat formalized with the nascent Time-Dependent Property feature of the Foundry Ontology. If the Time-Dependent Property feature is available on your Foundry instance, you can read more about it in the Ontology product documentation in the "How to create a Time-Dependent Property" section.
- Dynamic Charts with Functions
Let's say you don't want to precompute the metrics for whatever reason, and instead want your chart to exactly render a line based on the average price values that are in the object set. One approach to accomplish this is to use a Function-backed Chart and a simple Typescript function that takes in as a parameter to object set of price information and returns a 2DimensionAggregation type that represents two data points: the first and last timestamp of the period represented by the input object set each paired with the average value calculated across the price values or a 3DimensionalAggregation since you perhaps want these two data points for each product category.
You can find clear steps in the Workshop and Functions product documentation for producing Function-backed Charts as well as examples of various Typescript Function implementations in the Foundry Training and Resources project on your Foundry instance.
- Dynamic Charts using Quiver
The Workshop XY Chart is still under active development and a number of features that might be useful are not yet available. In some circumstances creating the chart in Quiver and embedding it in your Workshop app with the Quiver Canvas widget can give you flexibility to build charts with "derived" values that you cannot currently accomplish directly with the Workshop chart.
I'm adding this for completeness; I don't actually think it'd be the best solution in this specific case. The power in this pattern comes from taking an object-backed bar or line chart in Quiver and using the "Convert to Timeseries" feature to unlock Quiver's timeseries plotting and transformation capabilities. You can check out the Quiver documentation for more guidance on how to create object-derived timeseries and how to turn a Quiver canvas into an Object Template to be embedded elsewhere.