[chore] Assign area:data to Service and Deployment SIG

[Ayushi-12]

Changes

This PR assigns the newly introduced area:data attribute group to the Service and Deployment Special Interest Group (SIG).

By updating the areas mapping, we ensure that:

1. Pull requests and issues tagged with area:data are correctly routed to the Service and Deployment approvers.
2. The AREAS.md documentation accurately reflects SIG oversight for data-related semantic conventions (Category and Sensitivity).

Why Service and Deployment SIG?

• Operational Context: This SIG already manages service-level metadata (e.g., service.name, service.criticality). Since data attributes (category, sensitivity) describe the data services handle, this SIG is best positioned to govern how services declare and propagate these data characteristics.
• Semantic Synergy: A service's operational importance (service.criticality) and environment information (deployment.*) is often linked to the sensitivity and nature of the data it processes (data.sensitivity and data.category). Managing both under this SIG ensures a cohesive strategy for risk-aware observability and security.
• Resource Attribute Alignment: This SIG has the expertise to ensure these attributes adhere to established patterns for resource-level metadata and lifecycle management which is closely tied to the service and deployment semantics.

In summary, data sensitivity is inherently tied to the services and environments. This SIG provides the necessary architectural oversight to maintain consistent conventions for these attributes.

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Ayushi-12 / name: Ayushi Asthana (c7467d0)

[kamphaus]

Have there already been some PRs using the data area?
If yes, could you link them?

Why should the Service and Deployment SIG have oversight of the data area?

[Ayushi-12]

Have there already been some PRs using the data area? If yes, could you link them?

Why should the Service and Deployment SIG have oversight of the data area?

The data area is a new dimension proposed in #3579
Relevant changes in #3644

The proposa has been discussed in the Service & Deployment SIG.

Why Service and Deployment SIG?
The Service and Deployment SIG should own the data area because data attributes describe the "cargo" of a service, directly complementing existing metadata like service.criticality or deployment.environment and contributing to the overall description of the infrastructure.
This SIG has the relevant context and expertise to manage this area and build towards a cohesive semantic convention of service, deployment and data.

I have also updated the description with a detailed rationale. PTAL.

[kamphaus]

Discussed in SemConv SIG:
More discussion is needed.
A question that was raised was why the top-level data namespace should be used.
It could be helpful if someone from the Service and Deployment SIG could present this and related PRs in the next general SemConv meeting.