iiRDS container and ZIP archive: how an iiRDS package is structured and exchanged

Example

A machine builder exports the documentation for a packaging line as packline-p40_en.iirds. Unpacked, the container shows one root with a mimetype file, META-INF/metadata.rdf, META-INF/metadata.jsonld, and the folders content/html, content/pdf and content/media. A rendition of the topic "Changing the sealing jaw" states iirds:source "content/html/change-sealing-jaw.html". The conveyor supplier's documentation sits beside it as a nested ZIP archive in content/suppliers. The customer's portal reads the first bytes of the file, recognizes application/iirds+zip, and imports the package without guessing which file belongs to which product.

How it applies

Technical documentation

The fixed layout separates metadata from content. Authoring systems can organize subdirectories freely, because renditions reference files by relative path. File names are case-sensitive, unique within their folder, limited to 255 characters, with full paths up to 260, and a few characters are excluded so that containers work on common file systems.

Migration

Moving from a plain ZIP of PDF manuals means adding META-INF/metadata.rdf, moving files out of the root into subdirectories and writing the mimetype entry first. For nested packages, iiRDS 1.2 and earlier referenced the nested archive through iirds:has-rendition; iiRDS 1.3 recommends omitting that relation. The specification notes that RDF/XML metadata may become deprecated in future versions, so providing JSON-LD as well is a reasonable preparation.

MedTech

For handover documentation, iiRDS/H adds container rules: an index.html content list in the root, which is not referenced in the metadata, mandatory metadata.jsonld, and no nested ZIP archives. Optional checksums, such as SHA-256, must be provided separately, never inside the package. These rules support traceable handover; they do not replace a regulatory assessment.

AI and retrieval

An ingestion job needs no crawler: check the mimetype entry, parse META-INF/metadata.rdf, then follow each rendition's iirds:source. One archive per delivery is also a convenient unit to version, verify with a separately supplied checksum, and reload into a retrieval index when a new revision arrives.

Container vs. ZIP archive vs. Package

Concept	Nature	Key rules
iiRDS container	Logical directory structure	Single root, META-INF for metadata only, content in subdirectories
iiRDS ZIP archive	Default physical implementation	.iirds extension, first entry mimetype stored uncompressed, UTF-8 names, Stored or Deflated, ZIP64 when needed, no encryption
iiRDS Package	RDF class iirds:Package	Exactly one instance per package, exactly one iirds:iiRDSVersion

Nested containers are included side by side in the ZIP archive of the highest-level package, and each one is declared as an iirds:Package in the parent metadata. The root may also hold extra files needed for interoperability with other standards, such as VDI 2770; Consumers must ignore them unless the metadata references them.

In RDF

The container itself has no RDF representation. What the metadata expresses is the Package and the relative paths into the container. 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/packline-p40> a iirds:Package ;
    iirds:iiRDSVersion "1.3" .

<https://example.com/iirds/change-sealing-jaw> a iirds:Topic ;
    iirds:is-part-of-package <https://example.com/iirds/packages/packline-p40> ;
    iirds:has-rendition [
        a iirds:Rendition ;
        iirds:format "text/html" ;
        iirds:source "content/html/change-sealing-jaw.html"
    ] .

In topic-based authoring and modular architectures

Topic-based sources, such as DITA topics organized by a DITA map, are usually published to HTML or PDF before packaging; the container then holds those outputs in subdirectories, one file per topic or one per publication. Because metadata sits in META-INF and not in the content files, the same HTML output can be repackaged with different metadata without regeneration. In modular delivery architectures, the ZIP archive is the unit of exchange between systems: suppliers ship their own archives, a machine builder nests them in unrestricted packages or relates them through component trees in iiRDS/H, and a portal swaps complete archives by revision.