iiRDS Generator: the software role that creates iiRDS packages

Example

A packaging machine manufacturer writes its documentation as DITA topics in a component content management system. For each machine model, an export job acts as the iiRDS Generator: it renders every topic to HTML and PDF, stores the files under content/, and writes META-INF/metadata.rdf. Each topic becomes an iirds:Topic whose IRI is built from the CMS module ID, so the same topic keeps the same IRI in next year's package. The job adds product variant, lifecycle phase and qualification metadata, puts the mimetype entry first and zips the result as packer-p40_en.iirds for the customer's portal.

How it applies

Technical documentation

In documentation departments the generator is usually part of the publishing chain, next to PDF and web output. The quality of its metadata decides what consumers can do: a topic without product or lifecycle metadata can be delivered, but not filtered. Mapping CMS attributes to iiRDS classes and docking points is therefore the main design work.

Migration

Legacy PDF manuals can be wrapped as whole Documents with PDF renditions before any restructuring. Generators written for earlier iiRDS versions should note a 1.3 change: nested packages are no longer located through iirds:has-rendition; the specification recommends omitting that relation and reading content from the nested package's own metadata.

MedTech

Medical device manufacturers who keep documentation for long retention periods can configure a generator to write iiRDS/A packages, which restrict content to long-term formats such as PDF/A-3. The package format supports archiving; whether the documentation meets regulatory content requirements remains a separate question.

AI and retrieval

A generator that writes stable IRIs and rich metadata produces datasets that retrieval systems can index without scraping. When a topic changes, its IRI stays the same, so an index can replace the old chunk instead of storing a duplicate.

Generator vs. Consumer

	iiRDS Generator	iiRDS Consumer
Side	Sending	Receiving
Task	Creates packages from source formats	Reads and processes packages
Typical software	CMS export, DITA pipeline, converter	Content delivery portal, service app, server
Defined in the vocabulary	No, role only	No, role only

The iiRDS Consumer relies on the generator having followed the specification. One system can play both roles, such as a portal that imports supplier packages and exports merged ones.

In RDF

A minimal result of a generator run: one Package with exactly one iiRDS version, and a topic with a concrete type, an IRI and a rendition. 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/packages/packer-p40> a iirds:Package ;
    iirds:iiRDSVersion "1.3" .

<https://example.com/iirds/topics/replace-sealing-jaw> a iirds:Topic ;
    iirds:title "Replacing the sealing jaw"@en ;
    iirds:is-part-of-package <https://example.com/iirds/packages/packer-p40> ;
    iirds:has-rendition [
        a iirds:Rendition ;
        iirds:format "text/html" ;
        iirds:source "content/html/replace-sealing-jaw.html"
    ] .

In topic-based authoring and modular architectures

In topic-based authoring, the generator is where modular source content meets a delivery format. Each DITA topic can become an iiRDS Topic, and a DITA map can become a Document or a directory structure. Metadata that authors assign to modules, such as audience or product, is translated into iiRDS relations instead of being lost in the rendered output. In modular delivery architectures, the generator decouples authoring from delivery: any authoring system that can generate iiRDS can feed any consumer, and changing one side does not require changing the other.