[METADATA UPDATE][Merge by 2024-10-30] Global ms.service and ms.subservice metadata update

[learn-build-service-prod[bot]]

A Pull Request has been made from the Learn Platform's Metadata Management System. Please review and merge this Pull Request within 5 days. If you have any questions or concerns about the purpose of these metadata updates, please contact docs-allowlist-mgmt@microsoft.com. If you are not the correct contact for this content and repository, please notify Metadata-Management@microsoft.com.

If this Pull Request is not merged within 14 days, it will be automatically merged by our system to ensure the timeliness of the metadata update. This includes bypassing the Repository's Branch Policy, including if Review Required is enabled. Please notify Metadata-Management@microsoft.com if you have questions or concerns or would like Pull Requests for metadata updates to merge automatically in future.

Fixing#992946 Remove ms.service = iot-dps. Replaced by ms.subservice = azure-iot-hub-dps paired with ms.service = azure-iot-hub

Who initiated this PR? The Learn Platform and Product (LPP) Site Experience team manages the Learn platform's reporting taxonomies that enable content analytics for OKR reporting and content portfolio management. Reporting taxonomy values populate metadata attributes.

We regularly review reporting taxonomies to ensure they are accurate, useful, and align to current business needs. Updates to reporting taxonomies and associated metadata make reports cleaner, easier to use, and more consistent.

Why are we updating ms.service/ms.subservice metadata? Objective: Ensure ms.service attribute reliably reflects product affiliation.

Issues: 1. Currently, ms.service taxonomy values mix product and non-product concepts. Non-product concepts represent real reporting needs but aren't strictly about products. 2. Slugs (machine readable identifiers) don't reflect Microsoft branding guidelines. This is leading to inaccurate metadata on content.

Actions: 1. Revise taxonomy structure so "ms.service" represents the name of a branded Microsoft product, product family, or branding terminology. 2. Update slugs to comply with branding guidelines.

Outcome: 1. Establish a baseline for a comprehensive product data model representing all Microsoft offerings. 2. Ensure that report filters driven by ms.service will be based on product. 3. Improved metadata quality.

Why it matters

• Efficiency in Content Auditing: Revising the taxonomy structure will enable more precise content audits, fostering repeatable business processes and alleviating the burden of large-scale, one-off audit projects.
• Semantic Precision: The ms.service taxonomy will have meaningful, universally understood semantic values.
• Consistent Metadata: This work contributes to the accuracy and uniformity of contextual metadata within the Learn Knowledge Base.
• RAG Pipeline Efficiency: The Learn Knowledge Service's RAG pipeline will benefit from increased accuracy of product attribution of content.

How does this affect me? After changes are complete, standard dashboards and reports will reflect new values, so you'll need to use new filter values. If you have any custom dashboards or Kusto queries, you might need to update those also.

Frequently Asked Questions Why does this Pull Request appear to be made by the Repository Owner? We open Pull Requests two different ways.

• For Git Repos with a permissioned Service Account, we open the PR from our Document Build Service Account.
• For Git Repos that we either do not have Service Account permission for or the repo is in Azure Repos (ADO) we open the Pull Requests in an automated way with the PR creator as the Repo owner.

How can I revert a Pull Request that has been merged and created an unexpected issue? Whether a PR has been merged manually or automatically, you can revert it if an issue arises. See Reverting a pull request - GitHub Docs.

[learn-build-service-prod[bot]]

Learn Build status updates of commit ad506ca:

:bulb: Validation status: suggestions

File	Status	Preview URL	Details
docfx.json	:bulb:Suggestion		Details

docfx.json

• Line 95, Column 51: [Suggestion: value-deprecated-replace - See documentation] The 'ms.service: iot-hub' you used is now deprecated and can no longer be used. We suggest you replace it with 'ms.service: azure-iot-hub'.

For more details, please refer to the build report.

Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[github-actions[bot]]

Expectations

Thanks for your submission! Here's a quick note to provide you with some context for what to expect from the docs team and the process now that you've submitted a PR. Even if you've contributed to this repo before, we strongly suggest reading this information; it might have changed since you last read it.

To see our process for reviewing PRs, please read our editor's checklist and process for managing pull requests in particular. Below is a brief, high-level summary of what to expect, but our contributor guide has expanded details.

The docs team begins to review your PR if you request them to or if your PR meets these conditions:

• It is not a draft PR.
• It does not have a WIP prefix in the title.
• It passes validation and build steps.
• It does not have any merge conflicts.
• You have checked every box in the PR Checklist, indicating you have completed all required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to help! You do not need to submit a fully polished and finished draft; the docs team can help you get content ready for merge.

While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your PR is merged, it is included the next time the documentation is published. For this project, the documentation is published daily at 3 p.m. Pacific Standard Time (PST).