iiRDS Topic: the self-contained unit of topic-based documentation

Example

A machine builder publishes the service content for a palletizer from its component content management system. The procedure “Replacing the air filter” becomes one iiRDS Topic with an HTML rendition for the service portal and a PDF rendition for print. It is typed with iirds:GenericTask, related to the lifecycle phase iirds:Maintenance and to the component “air filter”. When a technician scans the machine and selects the filter, the portal shows exactly this topic. The warning at the start of the procedure stays inside the topic, so it is never shown without the steps it belongs to.

How it applies

Technical documentation

The Topic is the delivery counterpart of a module in topic-based authoring. Each topic is written, reviewed and translated once and can then appear in several deliverables. In iiRDS, it carries its own metadata, so a portal can find it by product, phase or topic type without knowing which manual it came from.

Migration

Topic-based sources such as DITA map to iiRDS Topics directly after publishing. Legacy PDF manuals can be made granular without rewriting: a chapter addressed with a RangeSelector can be typed as its own Topic, as long as it is self-contained. Content that needs context is better modeled as a Fragment.

MedTech

Procedures for cleaning, setup or troubleshooting of a device can be delivered as individual topics to the point of use. Language versions and revisions of the same topic link to one information object, so a portal can show the current revision in the reader’s language. Delivery granularity does not change which content must be approved.

AI and retrieval

A self-contained topic is a strong retrieval chunk: it can be answered from correctly without its surroundings. Topic type and lifecycle phase work as filters, for example task content for “how do I” questions. The topic IRI gives an assistant a stable source to cite.

Topic vs. Fragment vs. Document

Unit	Scope	Understood alone	Typical example
Topic	One subject	Yes	Task “Replacing the air filter”
Fragment	Part of a subject	No, needs context	A single hazard statement or table row
Document	Many subjects for one purpose	Yes, read as a whole	Operating instructions

When in doubt, ask whether a reader could act correctly on the unit without seeing anything else. If yes, it is a Topic.

In RDF

A task topic with metadata and two renditions. 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/components/air-filter> a iirds:Component .

<https://example.com/iirds/replace-air-filter> a iirds:Topic ;
    iirds:title "Replacing the air filter"@en ;
    iirds:language "en" ;
    iirds:has-topic-type iirds:GenericTask ;
    iirds:relates-to-product-lifecycle-phase iirds:Maintenance ;
    iirds:relates-to-component <https://example.com/iirds/components/air-filter> ;
    iirds:is-version-of <https://example.com/iirds/objects/replace-air-filter> ;
    iirds:has-rendition [
        a iirds:Rendition ;
        iirds:format "text/html" ;
        iirds:source "content/replace-air-filter.html"
    ] , [
        a iirds:Rendition ;
        iirds:format "application/pdf" ;
        iirds:source "content/replace-air-filter.pdf"
    ] .

In topic-based authoring and modular architectures

In topic-based authoring, a DITA topic or a CCMS module is the unit of writing and reuse; the iiRDS Topic is the same unit at delivery time. DITA information types map onto iiRDS topic types: a DITA task becomes a topic with iirds:GenericTask, a concept one with iirds:GenericConcept. The map that orders topics is not carried inside the topics. iiRDS models order separately with directory nodes, so one topic can appear in several documents without duplication. In modular delivery architectures, this separation lets a portal assemble topics dynamically by metadata, while the directory structure preserves the author’s intended reading order where it matters.