Add Entity Type Uniqueness and Attribute Ownership restrictions

[dmitryax]

While working on adding API for managing the Resource Entity references in collector pipelines, I found that it's very complicated to maintain data integrity if we don't explicitly impose the following restrictions on the data model:

1. Entity Type Uniqueness: Enforces that all entities within a resource must have unique types, ensuring unambiguous identification and preventing ID attribute key collisions when combined with the prefix naming convention.

2. Attribute Ownership: Ensures each resource attribute key is owned by at most one entity, preventing description attribute key collisions and data inconsistencies from multiple entities competing for control of the same attribute.

• Related issues: [xpdata/entity] API to manage resource entity references that ensures data integrity opentelemetry-collector#14042
• Related OTEP(s): https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/entities/0264-resource-and-entities.md
• Links to the prototypes (when adding or changing features): [xpdata] Add high-level API for managing entities attached to resources opentelemetry-collector#14039
• CHANGELOG.md file updated for non-trivial changes
• Spec compliance matrix updated if necessary

[dyladan]

The uniqueness requirement at least I think is implied by the merge rules https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/entities/0264-resource-and-entities.md#entity-merging-and-resource

I had thought the attribute ownership requirement was also in the OTEP but I can't find it.

In any case, I think this is overall a good idea to clarify and should be in the spec anyway not just oteps.

This is a draft so I'll hold off on review but +1 on the idea.

[jsuereth]

Overall supportive of this. I think we need this definition here.

I do think we need to account for failure scenarios, so holding of an approval until we either add that section or mark a TODO to add that section.

[jsuereth]

I'm skeptical of relying on naming conventions here. I think we likely need something to describe what to do if folks fail to use our naming conventions going forward (it will happen, so we should make sure we don't get invalid Resources when it does, if we can help it.

In light of how other SDK/model behavior is - we should call out that this would be an error scenario in the model - and we'll be recommending SDKs have some kind of "error log + fallback" behavior.

[dmitryax]

Good point. I've added an Implementation Note to address validation and fallback strategies with given data model restrictions. Since this document isn't intended to provide SDK guidance as far as I understand, I kept it as a note rather than normative requirements.

On the naming convention strictness - the current semantic conventions already follow this pattern (host.id, k8s.node.uid, etc.). I'd prefer keeping the stricter requirement until we encounter concrete cases that break it during semantic convention development.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.