Audience in iiRDS: how Qualification, Role and SkillLevel model the target group

Example

A packaging machine manufacturer delivers its documentation as an iiRDS package. The topic "Adjusting the sealing jaw pressure" is linked to the role "Mechanical service technician" and the skill level "Trained". The topic "Changing the film reel" is linked to the role "Machine operator". Both roles are declared once in the manufacturer's namespace. On the plant's service tablet, a technician signed in with the service role sees both topics, while the operator app hides the jaw adjustment and shows only the reel change. The same package serves both groups without duplicated content.

How it applies

Technical documentation

Most instructions already state a target group in the front matter or in a safety note. iiRDS makes that statement machine-readable. Map the audience definitions from your style guide or risk assessment to a short list of iirds:Role instances, and add iirds:SkillLevel where the same role covers novice and experienced users. Keep labels stable, because consumers filter on the IRI, not on the display text.

Migration

In PDF manuals, audience is prose ("only for qualified electricians"), so it has to be extracted by hand or by rule. From DITA, the @audience attribute and a subject scheme map give a controlled value list that can be mapped one to one to iiRDS roles. Values from a legacy CMS map the same way, provided each has one clear meaning.

MedTech

Medical device documentation often separates content for clinical users, biomedical engineers and field service. A role such as "Certified biomedical technician" makes that separation explicit in delivered content. The metadata supports, but does not replace, the manufacturer's own controls on who may service a device.

AI and retrieval

An assistant that knows the user's role can restrict retrieval to matching content, or answer with a notice that a task requires a different qualification. Because every custom role is an instance of iirds:Role, a retrieval pipeline can recognize it as a qualification even without knowing the manufacturer's vocabulary.

Qualification role vs. party role

	Qualification role (iirds:Role)	Party role (iirds:PartyRole)
Metadata group	Functional metadata	Administrative metadata
Question	Who is qualified to carry out the task?	Who created, approved or supplied the resource?
Linked with	iirds:relates-to-qualification	iirds:has-party-role on an iirds:Party
Values	Company-defined only	Standard values such as Author, Manufacturer, Supplier

A reviewer who approved a topic is a party; the technician who performs the task it describes is a qualification.

In RDF

A task topic linked to a company-defined role and skill level. Shown in Turtle for readability; inside a package, metadata.rdf is written in RDF/XML.

@prefix iirds: <http://iirds.tekom.de/iirds#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

<https://example.com/iirds/roles/mechanical-service-technician> a iirds:Role ;
    rdfs:label "Mechanical service technician"@en .

<https://example.com/iirds/skills/trained> a iirds:SkillLevel ;
    rdfs:label "Trained"@en .

<https://example.com/iirds/adjust-jaw-pressure> a iirds:Topic ;
    iirds:has-topic-type iirds:GenericTask ;
    iirds:relates-to-qualification <https://example.com/iirds/roles/mechanical-service-technician> ,
        <https://example.com/iirds/skills/trained> .

In topic-based authoring and modular architectures

In topic-based authoring, audience belongs on the smallest unit that differs by target group, usually the task topic, not the whole manual. That keeps topics reusable: one topic, one qualification statement, many publications. In a modular delivery architecture the qualification list works like a shared taxonomy. Authoring, the CMS and every consumer resolve the same role IRIs, so filtering happens at delivery time instead of through separate audience-specific builds. Changes to the role list should go through the same change control as other controlled vocabularies.