I noticed a pattern.

[finegeometer]

After reading the min-relations RFC, I noticed a pattern.

• A Component attaches some arbitrary data to an entity.
• A Relation attaches some arbitrary data to an ordered pair of entities.
• A Resource attaches some arbitrary data to an empty tuple of entities!

This seems to suggest that Resource, Component, and Relation are all special cases of a single more general concept, which is not implemented in Bevy.

I'm not sure if this observation is useful, but it is interesting.

[bjorn3]

Resources are internally represented as components for inaccessible "entities". With min-relations components will be represented as relations I believe.

[Byteron]

You're right, sort of.
Components are the default.
And Both Resources as well as Relations can technically be achieved with Components too.
For Relations you could very well just use Components that hold an Entity as field.
For Resources you could very well use Components instead, and query for them.

Both Resources as well as Relations are essentially just specialized components for their specific use case.
That being Relations for defining relationships between certain entities, and Resources for storing (sort of) global data.

[finegeometer]

That's one way to think about it, but it's not what I was trying to get at in this post.

What I was trying to say is that all three are special cases of the more general concept of "Attach some arbitrary data to an ordered list of entities". (Conceptually, not implementation-wise.)

• Components are the special case where the list has one element.
• Relations are the special case where the list has two elements.
• Resources are the special case where the list has zero elements.

From this perspective, Resources and Relations aren't special cases of Components. Instead, Resources, Relations, and Components are all special cases of this more general concept.