I apologise for reviving this old topic, but only just had the same problem myself...
This seems absolutely spot on, but is exactly what I see as problematic with the schema. A data object is classified as such not by its implementation, but whatever logical encapsulation the programmer wants to convey. The problem as I see it is that the object must include an id. In fact the schema says the following:
"Within a given API, each resource object’s type and id pair MUST identify a single, unique resource"
So if we're talking about trying to represent some data that we want to represent as an object, but it may not be a single unique resource, we're left trying to push a square peg into a round hole just to satisfy the schema.
We could always hash the contents of the data to ensure that the id is mostly unique, but at that point surely you have to wonder why we're doing that, as it's probably useless and confusing (if the id value of your other objects refer to the PK value in your DB for example, and can be used to fetch them).
Perhaps I'm missing something here, but it would seem reasonable for the standard to allow the dropping of the id if it no longer had any purpose and only sought to confuse the consumer (and implementer!) of the service.