Glossary · Information delivery

Content delivery portal

Also known as: Content delivery platform, Content delivery system, CDP, Documentation portal

German: Content-Delivery-Portal

In technical communication, a content delivery portal is a server-based system that imports technical documentation from one or more sources — typically as iiRDS packages — and delivers it to users as single topics or documents rather than as complete manuals. Readers reach the content through full-text search, metadata facets such as product, component, task or audience, and through APIs that feed service apps, machine HMIs and assistants. The portal is a consumer of intelligent information: it does not author content, it indexes the metadata that came with it. "Content delivery portal" is a product category, not a class in the iiRDS ontology.

Information architecture
iiRDS term

In one sentence

A content delivery portal imports iiRDS packages and delivers filtered topics to technicians and operators through search, facets and apps.

Example

A service technician opens the plant's content delivery portal on a tablet, scans the machine's QR code, and the portal filters the imported iiRDS packages down to the maintenance topics for that component, that variant and the qualification level of the logged-in user.

How it applies

Import over authoring: A portal is the read side of the tool chain. It receives iiRDS packages produced by a generator, unpacks the ZIP, parses the RDF metadata and stores content plus metadata in its own index. The iiRDS specification names manufacturers of content delivery systems as one of its target groups and describes the package format as an exchange format between systems such as web portals and content delivery servers.
Facets are metadata, not text: Search filters in the portal are generated from the metadata that arrived with the content — product and component, information type, task, lifecycle phase, audience, qualification. If the authoring side leaves these properties empty, the portal shows empty facets; no delivery feature repairs missing metadata.
Granularity: Because metadata sits on the information unit, a portal can return a single topic instead of a whole document. Packages that contain only PDF renditions still work, but the user gets a file, not a task-sized answer.
Stable identifiers: Portals rely on the IRIs of information units and on iirds:is-version-of relations to replace, not duplicate, content on re-import. Unstable identifiers produce duplicate hits after every delivery.
Multi-vendor plants: Operators aggregate packages from many manufacturers. That only yields useful facets if the suppliers use a shared vocabulary; supplier-specific taxonomies can be carried along with iiRDS ExternalClassification and mapped in the portal.
Handover: Operators often require documentation as a document-based handover set as well. iiRDS/H packages carry handover document classification alongside the topic metadata, so one delivery can serve both a portal and a document repository. Importing content into a portal is an information-delivery step; it is not in itself evidence that any legal duty on instructions for use — language, format, durability, accompanying the product — has been met. Check those requirements separately.
Integration: Typical engineering work is an iiRDS importer, incremental updates, access control per customer, plant or machine, a query API (often JSON, sometimes JSON-LD) for embedding in service apps and HMIs, and archiving of what was delivered, for which iiRDS/A packages are intended.
AI assistants: Portals are a common retrieval backend. The delivered metadata gives a retrieval-augmented assistant pre-labelled chunks with product, variant and audience context that it would otherwise have to infer from the prose.

Content delivery portal vs. CCMS

A component content management system is the authoring side: writers create modules, reuse them, assign metadata, run reviews and translations, and it holds the source of truth. A content delivery portal is the delivery side: it publishes and filters content that is already released, for readers who never log into the authoring system. The two are usually separate products connected by a publishing step — in iiRDS terms, the CCMS or a downstream tool acts as the generator, the portal as the consumer. Some vendors bundle both, which is a packaging decision, not a change of role.

External references

Keep in mind

Content delivery portals are commercial products. Feature names, supported iiRDS versions, import behavior and API details differ between vendors and change with each release; verify them against the current product documentation of the system you are evaluating rather than against this entry.