iiRDS Consumer: the software role that reads and processes iiRDS packages

Example

A food producer operates packaging lines from three suppliers. Its content delivery portal is the iiRDS Consumer: it imports each supplier's .iirds file, reads META-INF/metadata.rdf and indexes every topic by product variant, lifecycle phase and qualification. A service technician scans the machine's type plate, selects "maintenance" and sees only the tasks for that variant, together with the tools and spare parts each task needs. An index.html that one supplier added to the root for VDI 2770 is not referenced in the metadata, so the portal ignores it.

How it applies

Technical documentation

For documentation teams, the consumer is where metadata quality becomes visible. Filtering, directory rendering and supply lists all depend on the relations the generator wrote. Consumers find proprietary classes through their iiRDS superclasses, which is why proprietary extensions must comply with the standard.

Migration

A consumer that already supports earlier iiRDS versions should adopt the 1.3 recommendation to ignore iirds:has-rendition on nested packages. The specification also notes that RDF/XML metadata may become deprecated in future versions; reading metadata.jsonld as well, mandatory for iiRDS/H, prepares for that.

MedTech

A MedTech consumer might be a document management system that files handover packages to the right device. In self-contained packages such as iiRDS/A, consumers may omit the few exempt cross-references, for example without internet access, and the content must still be consumable.

AI and retrieval

A retrieval pipeline that ingests iiRDS packages is a consumer too. It can chunk along information units, keep their IRIs as stable identifiers and store product and lifecycle metadata as filters, so an assistant answers for the right machine instead of the closest match.

Consumer vs. Generator

	iiRDS Consumer	iiRDS Generator
Side	Receiving	Sending
Task	Reads and processes packages	Creates packages from source formats
Must support	iiRDS ZIP archive	Writing a valid container and ZIP archive
Must ignore	Unreferenced root files	—

The iiRDS Generator and the consumer never need to know each other; the package format is their only contract.

In RDF

These are the kind of statements a consumer queries to select content for a variant, phase and role. Shown in Turtle for readability — inside a package, metadata.rdf is written in RDF/XML.

@prefix iirds: <http://iirds.tekom.de/iirds#> .

<https://example.com/iirds/topics/replace-sealing-jaw> a iirds:Topic ;
    iirds:relates-to-product-variant <https://example.com/iirds/products/packer-p40> ;
    iirds:relates-to-product-lifecycle-phase iirds:Maintenance ;
    iirds:relates-to-qualification <https://example.com/iirds/roles/service-technician> .

<https://example.com/iirds/products/packer-p40> a iirds:ProductVariant .
<https://example.com/iirds/roles/service-technician> a iirds:Role .

In topic-based authoring and modular architectures

Topic-based authoring pays off at the consumer. Because content arrives as individual topics with their own metadata, the consumer can assemble task-specific views instead of showing whole manuals, and it can combine topics from several suppliers in one interface. In modular delivery architectures the consumer is replaceable: a portal, a mobile service app and an AI retrieval index can all read the same package without changes on the authoring side. The consumer should treat the iiRDS XHTML5 class attribute as styling only; the specification requires that an iiRDS XHTML5 consumer can ignore or modify class values without loss of meaning.