Clarify need for @odata.id in nested response structures

This issue is to clarify, if nested entities included in the response to an aggregation request need to be equipped with an @odata.id control information.

Consider example 24 from the Data Aggregation specification:

GET ~/Sales?$apply=groupby((Customer/Country,Product/Name),aggregate(Amount with sum as Total))

results in

{
  "@odata.context": "$metadata#Sales(Customer(Country),Product(Name),Total)",
  "value": [
    { "@odata.id": null,
      "Customer": { "Country" : "Netherlands" },
      "Product": { "Name": "Paper" },
      "Total": 3 },
   [...]
 

Top-level entities do have an @odata.id, but nested projections of related entities currently not. Is this according to rules defined in the format specs to be considered as a gap that needs to be discussed for the Data Aggregation spec?

The JSON specification describes in section 8.3 for expanded navigation properties that the content is to be rendered according to the entity representation. Two cases exist: 1) If the nested entity is a projection of a "real" entity, this could imply mentioning its @odata.id in the response. 2) If the nested entity is a result of an aggregation and therefore transient, section 4.5.8 of the JSON spec states: "If the entity is transient (i.e. cannot be read or updated), the id annotation MUST appear and have the null value."