iiRDS Specification

4. The iiRDS Metadata Model in the RDF Schema

4.1 Glossary

iiRDS Generator: application that creates iiRDS-compliant documentation data from a source format like XML or Word.
iiRDS Consumer: application that reads and processes iiRDS-compliant documentation data on the receiving end, e.g. on a server, in a content delivery portal, or a web application.

4.2 Scope of the RDF Schema

The iiRDS RDF schema contains standardized metadata terms describing technical documentation. The metadata allows for an exchange of technical documentation between distributed services and cyber-physical systems. Metadata for technical documentation comprises for example:

Categories for content
Properties for relations to products
Properties for relations to technical components
Properties for relations to functions
Properties for relations to target audience
Properties for relations to product lifecycle phases

The metadata describes both product-specific properties and properties of the information itself. Based on the metadata, iiRDS Consumers can find specific information and filter documentation variants. Because each company has a different product structure and uses other variant-determining factors, iiRDS focuses on metadata describing the information itself. To enable iiRDS Creators to plug in their specific product and component metadata, the iiRDS schema provides docking points for other ontologies.

iiRDS does not stipulate rules for authoring technical documentation but provides a standardized vocabulary for describing technical documentation in output formats like HTML, webhelp, or PDF. The granularity of delivered documentation may vary largely – from a document to a single fragment within a topic. Also, the classification methods that authors apply when writing the documentation content may vary considerably.

iiRDS follows the principle of “describing what there is” instead of enforcing relations between specific types of metadata or building up a detailed taxonomy tree. For example, iiRDS models documentation subjects and product-lifecycle phases as separate metadata. In XML authoring environments, some subjects like a maintenance plan would be tied to a product-lifecycle phase and could not be used for topics that do not belong to that phase. iiRDS does not enforce this relation in order to cover content from authoring processes that are not that highly structured.

According to the principles of linked data, some iiRDS data structures refer to existing vocabularies like the Dublin Core rather than defining own structures in the iiRDS domain. For example, the Dublin Core contributor specifies the organization or person responsible for the technical documentation. The Dublin Core format specifies the format of the content.

The iiRDS vocabulary uses the following identifiers:

iiRDS Core: http://iirds.tekom.de/iirds

For example, the identifier of the iiRDS topic class is http://iirds.tekom.de/iirds#Topic
iirds Domain: http://iirds.tekom.de/iirds/domain

For example, the identifier of an iiRDS circuit diagram is http://iirds.tekom.de/iirds/domain/machinery#CircuitDiagram. It is part of the iiRDS Machinery Domain.

4.3 Main Classes of the iiRDS Metadata

iiRDS metadata provides the following main classes:

InformationUnit: central class representing an iiRDS package, a document, a topic, or a fragment within a topic or document. Most relations to other metadata, such as product, subjects or events, point from the InformationUnit to the metadata instance. iiRDS Generators can assign iiRDS metadata to documentation content on different levels of detail, ranging from whole documents down to fragments.
InformationType: indicates the type of content. Contains document types, topic types, and information subjects.
DocumentationMetadata: parent node for all metadata representing the product-related classification of the technical documentation. Contains functional metadata like required tools and events, as well as docking points for product and component taxonomies. It also provides classes representing product lifecycle phases.
DirectoryStructure: defines a navigation hierarchy for information units. iiRDS Consumers may use this metadata to build up a navigation structure like a table of contents

4.3.1 InformationUnits and Information Types

4.3.1.1 Subclasses of InformationUnit

The InformationUnit is an abstract base class for chunks of technical information. iiRDS Generators shall not use the InformationUnit class directly but shall use one of the subclasses to assign metadata to content. The class InformationUnit has the following subclasses:

Document: A collection of information for an audience and a specific purpose. Examples of documents are Maintenance Manuals, Operation Instructions, and Sales Catalogs.
Topic: A self-contained chunk of information. A topic deals with a single subject. A reader requires no additional information to understand a topic. Examples of topics are a task about turning on a mobile phone or a list of all UI elements of a computer program.
Fragment: A small chunk of information. A reader requires additional context to understand a fragment. Examples of fragments are a hazard statement or an exploded view drawing of a pump.
Package: A collection of InformationUnits bundled with the corresponding metadata and relation within the package. A Package is organized in a directory structure, which is packed as a standard compliant ZIP archive. A Package is used to deliver generated documentation output to servers or iiRDS Consumers. Packages may have metadata, describing their identity and origin.

The subclasses Document, Topic, and Fragment represent sets of metadata for chunks of technical information. Document, Topic, and Fragment may reference a physical file or a part of a file in the iiRDS package. But Document, Topic, and Fragment can also model abstract entities without a physical file in the iiRDS package. For example, a Document may reference a DirectoryStructure with topics that form an Operation Instruction but may not reference a single physical file directly.

InformationUnits have the following properties:

rdf:about: Shall be used to identify an InformationUnit in the iiRDS package. If no meaningful identifier is available for the InformationUnit, then a blank node may be used.
iirds:title: Shall be used for the title of a Document or Topic. May be used for the title of a Fragment.
iirds:dateOfCreation
iirds:language
iirds:rights: Information about rights held in and over the resource
iirds:identifier: iiRDS Creators may use the identifier to assign additional IDs to documents and topics.

4.3.1.2 Types of Documents and Topics

In order to support user searches for specific types of information, iiRDS provides standardized document and topic types:

Instances of the Document class shall have one or more relations to one of the standardized DocumentTypes defined in InformationType > DocumentType. Examples are transport instructions, repair instructions, or assembly instructions. More than one relation to a DocumentType makes sense for documents with mixed content, for example, a combined document for both transport and assembly instructions.
All instances of the InformationUnit subclasses may have one or more relations to one of the standardized TopicTypes defined in InformationType > TopicType. Examples are task, concept, and learning. TopicType may also be used for fragments, for example, to categorize parts of documents that do not belong to one of the standard document types.
Instances of the Topic and Fragment classes may have a relation of type iirds:applicable-for-document-type to one of the standardized DocumentTypes defined in InformationType > DocumentType. For example, a Topic can be categorized for use in operation instructions and quick reference guides.

4.3.1.3 InformationUnit Identifier

The subclasses of InformationUnit contain instances that assign metadata to chunks of technical documentation. The property rdf:about identifies these instances.

The IRI of rdf:about should be absolute. Additionally, the iiRDS group recommends the following:

Keep the IRI of rdf:about globally unique.
Keep the IRI of rdf:about stable over packages and time if the IRI identifies the same subject.
If the source system provides a meaningful identifier such as a unique ID from the CMS, use it to generate an IRI for rdf:about.

Example 1: A topic with a globally unique resource identifier.

<iirds:Topic rdf:about="https://myCompany.com/iiRDS/myPackage/2017-07-22/123e4567-e89b-12d3-a456-426655440000">
    <iirds:format>text/html</iirds:format>
</iirds:Topic>

Example 2: A fragment with a globally unique resource identifier.

<iirds:Fragment rdf:about="urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66">
    <iirds:format>text/html</iirds:format>
</iirds:Fragment>

4.3.1.4 Content References of Information Units

InformationUnits are abstract entities that assign metadata to content. Renditions of the content are stored as files in an iiRDS package. To assign metadata to a rendition, an InformatioUnit references files. Additionally, an InformatioUnit may reference parts within a file.

4.3.1.4.1 Reference to File

To reference a file, iiRDS provides the property iirds:has-rendition for the class iirds:InformationUnit and its subclasses iirds:Document, iirds:Topic, and iirds:Fragment. The property iirds:has-rendition points from an instance of these subclasses to iirds:Rendition. iirds:Rendition represents the physical file in the package. To identify the physical file, the property iirds:source points from the rendition to the URL of the physical file. The URL is relative to the root folder of the iiRDS package.

Example 3: A fragment with reference to a file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/topic_1">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/xml</iirds:format>
            <iirds:source>rendition/general_safety.xml</iirds:source>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

The example above shows a topic that references a file.

Editor's note

An information unit can reference multiple files with multiple iirds:has-rendition properties.

4.3.1.4.2 Reference by Selector

To reference parts of a file, iiRDS provides the class iirds:Selector. The property iirds:has-selector points from iirds:Rendition to an iirds:Selector. iirds:Rendition shall not directly use iirds:Selector but shall use one of its subclasses to reference parts of a file. The class iirds:Selector has the following subclasses:

iirds:FragmentSelector
Selects a part of a file by a single identifier.
iirds:RangeSelector
Selects a range in a file by a start and an end identifier.

To select parts of a file, a selector has an rdf:value. That value shall conform to an established standard. The selector references an established standard by the property dcterms:conformsTo. For a list of fragment selectors, see https://www.w3.org/TR/annotation-model/#fragment-selector.

4.3.1.4.2.1 Reference by FragmentSelector

The iirds:FragmentSelector points to a single identifier in a file, for example, a page in a PDF. Depending on the file format and the associated standard, a single identifier of a fragment selector may select a range in a file. For example, the Media Fragments URI allows to reference a time range.

The following example shows a topic that references a chapter in an XML file by fragment selector.

Example 4: A topic with reference to a fragment of a file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/topic_1">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/xml</iirds:format>
            <iirds:source>rendition/DocBook_Example_1.xml</iirds:source>
            <iirds:has-selector>
                <iirds:FragmentSelector>
                    <dcterms:conformsTo rdf:resource="http://tools.ietf.org/rfc/rfc3023"/>
                    <rdf:value>xpointer(id('chptr_1')/Section[1])</rdf:value>
                </iirds:FragmentSelector>
            </iirds:has-selector>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

The following example shows a topic that references a time range in an audio file. The topic assigns metadata to a time range in the file Spoken_Words_456.wav. The time range starts at 90 seconds and continues up to 210 seconds of play time.

Example 5: A topic with reference to a range in an audio file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/audio_7654">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>audio/x-wav</iirds:format>
            <iirds:source>rendition/Spoken_Words_456.wav</iirds:source>
            <iirds:has-selector>
                <iirds:FragmentSelector>
                    <dcterms:conformsTo rdf:resource="http://www.w3.org/TR/media-frags/"/>
                    <rdf:value>t=90,210</rdf:value>
                </iirds:FragmentSelector>
            </iirds:has-selector>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

4.3.1.4.2.2 Reference by RangeSelector

The iirds:RangeSelector points to a range in a file by referencing a start and end selector. An iiRDS application can use the range selector to identify a range in a file if the file format or the associated standard do not allow to select a range directly. The range selector references the start selector and end selector by the properties iirds:has-start-selector and iirds:has-end-selector.

The following example illustrates how to select a range in a PDF. As the application/pdf Media Type standard allows only to reference a single page or named destination in a PDF file, an iiRDS application can use the iirds:RangeSelector to define the start and end point. The following topic references multiple pages in a PDF file. The page range starts at page 10 and ends at page 17. The page range includes page 10 but not page 17.

Example 6: A topic with reference to a part of a file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/my_manual">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/pdf</iirds:format>
            <iirds:source>rendition/My_Manual.pdf</iirds:source>
            <iirds:has-selector>
                <iirds:RangeSelector>
                    <iirds:has-start-selector>
                        <iirds:FragmentSelector>
                            <dcterms:conformsTo rdf:resource="http://tools.ietf.org/rfc/rfc3778"/>
                            <rdf:value>page=10</rdf:value>
                        </iirds:FragmentSelector>
                    </iirds:has-start-selector>
                    <iirds:has-end-selector>
                        <iirds:FragmentSelector>
                            <dcterms:conformsTo rdf:resource="http://tools.ietf.org/rfc/rfc3778"/>
                            <rdf:value>page=17</rdf:value>
                        </iirds:FragmentSelector>
                    </iirds:has-end-selector>
                </iirds:RangeSelector>
            </iirds:has-selector>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

4.3.1.4.3 Multiple File References

An information unit may have multiple physical renditions in an iiRDS package. For example, an iiRDS package may contain a topic as an XML file and as a published HTML file. For each rendition, an information unit may reference the whole file or select a part or range.

To reference multiple renditions, an information unit may have multiple iirds:has-rendition properties.

The following example shows a topic that references a DITA XML file and the published PDF representation.

Example 7: A fragment with reference to a file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/topic_1">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/xml</iirds:format>
            <iirds:source>rendition/source/general_safety.dita</iirds:source>
        </iirds:Rendition>
    </iirds:has-rendition>
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>application/xhtml+xml</iirds:format>
            <iirds:source>rendition/web/general_safety.html</iirds:source>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

4.3.1.5 Information Subjects

Subjects narrow down the purpose of a chunk of information and help users to find suitable information for a specific purpose. The iiRDS subjects represent typical information types and usage scenarios for technical documentation.

iiRDS provides subclasses for typical groups of subjects. Examples are:

Collection: Lists and overviews generated by iiRDS Consumers from functional metadata like operating supplies, tools, and spare parts
Conformity: Information related to standard and guidelines, e.g. applicable standards, declaration of conformity.
Formality: Information identifying the product and the manufacturer, e.g. contact information, product identification, and scope of delivery.
Process: Process-related information.
Safety: Safety-related information, such as intended use, safety equipment, and warning notice.
TechnicalData: Technical properties such as dimensions and connection voltage.
TechnicalOverview: Technical information such as circuit diagrams, flow diagrams, software interfaces, or software architecture overviews.

iiRDS Generators shall use the has-subject relation for assigning subjects to InformationUnits. An InformationUnit may have one or more subjects assigned. This enables applications to assign metadata to content of different granularity – whereas a topic usually deals with one subject only, a document may cover several.

4.3.1.6 Relations of InformationUnits

iiRDS Generators may assign relation properties to InformationUnits. For example, the relation properties can describe if the content is suitable for a specific target group, belongs to a specific product lifecycle phase or requires specific tools. The relation properties point to objects in DocumentationMetadata and InformationSubject. With this metadata, iiRDS Consumers can retrieve chunks of information for specific contexts or user roles, assemble lists of required material, or filter content according to products.

All relations are optional and not enforced by the RDF schema.

The main relations are:

relates-to-event: Describes a relation to a specific event. Events may be defined by error codes, for example. With this relation, iiRDS Consumers can retrieve instructions regarding specific events and present them to the user.
relates-to-product-metadata: Describes the relation to a specific product, component, product life-cycle phase, or product feature. This relation enables iiRDS Consumers to filter and retrieve information for specific product-related properties.
has-subject: Describes the subject of the InformationUnit. Subjects narrow down the purpose of a chunk of information and help users to find suitable information for a specific purpose. The iiRDS subjects represent information types and usage scenarios for technical documentation. Examples of subjects are maintenance plans, the scope of supply, or license information.
requires-supply: Describes the relation to required specific tools, spare parts, or other supplies. Supplies are defined in DocumentationMetadata > FunctionalMetadata > Supplies. With relations from content to supplies, iiRDS Consumers can retrieve and summarize required supplies for specific tasks. For example, a service application can create a list of spare parts and tools for selected tasks.
requires-qualification: Describes qualifications that represent professional skills, training certificates, or vocational qualifications of the target audience of a technical documentation. For example, some documents or topics are only intended for service technicians whereas others may also be shown to operators or end users of a product. With this relation, iiRDS Consumers can filter and select topics for specific target audiences. As qualifications are industry- or company-specific, the subclasses SkillLevel and Role in DocumentationMetadata > FunctionalMetadata represent docking points for application-specific subclasses.
requires-time: Describes the duration or interval of tasks of the InformationUnit. The different time periods are modeled in DocumentationMetadata > FunctionalMetadata > PlanningTime. Examples are working time, downtime of machines during a specific task, or service intervals for machines. With relations from content to intervals and durations, iiRDS Consumers can calculate downtimes for a set of tasks or overviews of service intervals for a set of components.

4.3.1.7 Media Files in iiRDS

iiRDS represents media files as instances of information units. As iiRDS is not file-centered but content-centered, a media file is modeled depending on its actual content. For example, a media file that contains a single self-contained piece of information is modeled as an iirds:Topic. The topics rendition and mime type identify it as a media file.

The following example shows a topic that is stored as an mpeg file.

Example 8: Topic that is stored as an `mpeg` file

<iirds:Topic rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/topic_879">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>video/mpeg</iirds:format>
            <iirds:has-source rdf:resource="rendition/intro.mpeg"/>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

If a media file is not self-contained and requires the context of another file, iiRDS models the media file as an iirds:Fragment. The following example shows a fragment that is rendered as an image in an HTML page.

Example 9: Fragment rendered as an image in an HTML page

<iirds:Fragment rdf:about="http://myCompany.com/iiRDS/myProject/myPackage/topic_786">
    <iirds:has-rendition>
        <iirds:Rendition>
            <iirds:format>text/html</iirds:format>
            <iirds:has-source rdf:resource="rendition/general_concepts.html"/>
            <iirds:has-selector>
                <iirds:FragmentSelector>
                    <dcterms:conformsTo rdf:resource="http://tools.ietf.org/rfc/rfc3023"/>
                    <rdf:value>#overview</rdf:value>
                </iirds:FragmentSelector>
            </iirds:has-selector>
        </iirds:Rendition>
    </iirds:has-rendition>
</iirds:Topic>

4.4 Documentation Metadata

iiRDS DocumentationMetadata describes the relevance of the content and also additional requirements related to the content.

iiRDS distinguishes between FunctionalMetadata and ProductMetadata:

FunctionalMetadata represents information that iiRDS Consumers can use for specific features, for example, creating lists of supply for selected tasks.
ProductMetadata represents information on products, components, features, and life cycle phases of the product. If this metadata is assigned to InformationUnits, iiRDS Consumers can use it to filter information by product and retrieve instructions for a specific component and life cycle phase.

iiRDS Generators may fill the DocumentationMetadata with values from the source files.

iiRDS focuses on providing a vocabulary for metadata that can be standardized across branches of industry and types of documentation. For this reason, some DocumentationMetadata represents only docking points for plugging in company- or industry-specific ontologies. Examples are Product and Component. Also, the defined product-lifecycle phases may be extended by industry-specific subclasses.

4.4.1 Functional Metadata

iiRDS Consumers can use FunctionalMetadata for advanced content delivery scenarios. With functional metadata, an application can assemble a maintenance plan, generate maintenance schedules, or calculate the downtime of machines based on repair and maintenance tasks. Authors may add this information in semantic elements or specialized metadata in the source data. For example, in DITA an author may use the semantic element <supplies> in the machinery task.

FunctionalMetadata is optional. The following subclasses are available:

Event: Represents events in the technical equipment. For example, errors, malfunctions, or warnings. Instances of the Event class shall have 2 properties: eventCode and eventType. iiRDS Generators may use the iiRDS Event class to link documentation content with event information code according to OPC-UA. To assign event information to an InformationUnit, iiRDS Generators shall use the relates-to-event relation.
Supplies: Describes tools, spare parts, and supplies required for a task or mentioned in the content. For assigning supplies information to an InformationUnit, iiRDS Generators shall use the requires-supply relation.
PlanningTime: Describes time intervals or durations. Examples are downtime of machines during maintenance or service, working time for a specific task, or maintenance intervals for components. To assign time information to an InformationUnit, iiRDS Generators shall use the requires-time relation.
Qualification: Describes industry- or company-specific vocational qualifications, certificates, training, and roles. iiRDS does not standardize skill levels, certificates, job descriptions or roles because the terms may vary largely between countries and industries. iiRDS Generators shall use the requires-qualification relation for assigning qualification information to content. iiRDS Consumers may use this information to filter content according to the qualification of the logged-in user.

4.4.2 Product Metadata

ProductMetadata contains classes for storing information on products, components, lifecycle phases, and product features. As this kind of information is highly dependent on the industry and company for which the documentation is intended, iiRDS does not provide any standardized subclasses below Product, Component, and ProductFeature. These classes serve as docking points for industry- or company-specific ontologies. Examples are product taxonomies from product data management systems or component diagrams from engineering.

Technical authors use product metadata to distinguish between documentation for different product variants. For this reason, iiRDS Consumers can use this metadata to filter or assemble content according to products, features, and components.

iiRDS provides some standardized subclasses for standard product lifecycle phases.

iiRDS Generators shall use the relates-to-product-metadata relation to assign ProductMetadata to InformationUnits.

4.5 Products and Components in iiRDS

iiRDS models products and components as metadata for technical documentation. As metadata, an iirds:Component or iirds:ProductVariant may have a relation to the physical product or component but they do not represent it. For example, an iirds:Component does not have a weight. Products and components are mere labels for information units.

The property iirds:relates-to-product-metadata can point from an information unit to an instance of iirds:Component and iirds:ProductVariant. The instances shall be part of a proprietary iiRDS extension.

4.5.1 Component Trees in the Package

iiRDS allows to model component trees as part of an iiRDS package. The property iirds:has-component defines part-of relations for products and their components. The component tree is a proprietary iiRDS extension, it shall be stored in the metadata.rdf of the iiRDS package.

The following example shows a simple product tree. The espresso machine has multiple components that also consist of other components. For example, the group head has a shower and a gasket.

Example 10: Product tree of an expresso machine

<iirds:Component rdf:about="http://myCompany.com/iirds/myProject/myPackage#EspressoMachine">
    <rdfs:label xml:lang="en">Espresso machine</rdfs:label>
    <iirds:has-component rdf:resource="http://myCompany.com/iirds/myProject/myPackage#Portafilter"/>
    <iirds:has-component rdf:resource="http://myCompany.com/iirds/myProject/myPackage#Grouphead"/>
</iirds:Component> 

<iirds:Component rdf:about="http://myCompany.com/iirds/myProject/myPackage#Portafilter">
    <rdfs:label xml:lang="en">Portafilter</rdfs:label>
</iirds:Component> 

<iirds:Component rdf:about="http://myCompany.com/iirds/myProject/myPackage#Grouphead">
    <rdfs:label xml:lang="en">Grouphead</rdfs:label>
    <iirds:has-component rdf:resource="http://myCompany.com/iirds/myProject/myPackage#Gasket"/>
    <iirds:has-component rdf:resource="http://myCompany.com/iirds/myProject/myPackage#Shower"/>
</iirds:Component>

<iirds:Component rdf:about="http://myCompany.com/iirds/myProject/myPackage#Gasket">
    <rdfs:label xml:lang="en">Gasket</rdfs:label>
</iirds:Component> 

<iirds:Component rdf:about="http://myCompany.com/iirds/myProject/myPackage#Shower">
    <rdfs:label xml:lang="en">Shower</rdfs:label>
</iirds:Component>

iiRDS does not differentiate between components and products when modeling component trees.

4.5.2 External Product Ontology

In addition to a component tree within a package, some parties may have a full-fledged external product ontology. While iiRDS product metadata represents metadata labels for information units, the products and components in the external product ontology may represent the physical items. A proprietary iiRDS extension can map the metadata labels in the package to the external product ontology. The product ontology does not need to be an iiRDS-compliant ontology and may use another vocabulary than RDF and RDFS.

An iiRDS package shall not use an external product ontology directly. If an external product ontology is available and used in the iiRDS package, then the iiRDS package shall contain components as instances of iirds:Component. iirds:has-component relations are optional.

The following example shows an external product ontology.

Example 11: External product ontology

<!-- 
    Declares dcterms properties as object properties. 
    Otherwise they cannot be used in class restrictions. 
-->
<owl:ObjectProperty rdf:about="http://purl.org/dc/terms/isPartOf">
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="http://purl.org/dc/terms/hasPart">
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty" />
    <owl:inverseOf rdf:resource="http://purl.org/dc/terms/isPartOf" />
</owl:ObjectProperty>

<!-- 
    The component tree is modelled with restrictions on hasPart. 
    An espresso machine can only have the parts Portafilter and Grouphead. 
-->
<rdfs:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#EspressoMachine">
    <rdfs:subClassOf>
        <owl:Restriction>
            <owl:onProperty rdf:resource="http://purl.org/dc/terms/hasPart"/>
            <owl:allValuesFrom>
                <rdfs:Class>
                    <owl:unionOf rdf:parseType="Collection">
                        <owl:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Portafilter" />
                        <owl:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Grouphead" />                        </owl:unionOf>
                </rdfs:Class>
            </owl:allValuesFrom>
        </owl:Restriction>
    </rdfs:subClassOf>
</rdfs:Class>
<rdfs:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Portafilter"/>

<!-- 
    A grouphead can only have parts Shower and Gasket. 
-->
<rdfs:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Grouphead">
    <rdfs:subClassOf>
        <owl:Restriction>
            <owl:onProperty rdf:resource="http://purl.org/dc/terms/hasPart"/>
            <owl:allValuesFrom>
                <rdfs:Class>
                    <owl:unionOf rdf:parseType="Collection">
                        <owl:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Shower" />
                        <owl:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Gasket" />                        </owl:unionOf>
                </rdfs:Class>
            </owl:allValuesFrom>
        </owl:Restriction>
    </rdfs:subClassOf>
</rdfs:Class>

<rdfs:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Shower"/>

<rdfs:Class rdf:about="http://myCompany.com/iirds/externalProductWorld#Gasket"/>

To map the component tree in the iiRDS package to the external product ontology, a mapping ontology may use the property rdfs:seeAlso.

Editor's note

The property rdfs:seeAlso shall point from the instance of the component in the iiRDS package to the external product ontology. The property rdfs:seeAlso may be part of the file metadata.rdf in the iiRDS package or part of the external product ontology.

The following example shows a mapping ontology that combines the component tree of metadata labels in the package with the component tree in the external product ontology.

Example 12: Mapping ontology combining metadata lables in the package with an external ontology

<rdf:Description rdf:about="http://myCompany.com/iirds/myProject/myPackage#EspressoMachine">
    <rdfs:seeAlso rdf:resource="http://myCompany.com/iirds/externalProductWorld#EspressoMachine"/>
</rdf:Description>

<rdf:Description rdf:about="http://myCompany.com/iirds/myProject/myPackage#Portafilter">
    <rdfs:seeAlso rdf:resource="http://myCompany.com/iirds/externalProductWorld#Portafilter"/>
</rdf:Description>

<rdf:Description rdf:about="http://myCompany.com/iirds/myProject/myPackage#Grouphead">
    <rdfs:seeAlso rdf:resource="http://myCompany.com/iirds/externalProductWorld#Grouphead"/>
</rdf:Description>

<rdf:Description rdf:about="http://myCompany.com/iirds/myProject/myPackage#Shower">
    <rdfs:seeAlso rdf:resource="http://myCompany.com/iirds/externalProductWorld#Shower"/>
</rdf:Description>

<rdf:Description rdf:about="http://myCompany.com/iirds/myProject/myPackage#Gasket">
    <rdfs:seeAlso rdf:resource="http://myCompany.com/iirds/externalProductWorld#Gasket"/>
</rdf:Description>

The following figure illustrates the mapping of a component tree in the iiRDS package to the external product ontology. Mapping of external product ontology

4.5.3 Product Variants

Product variants may be more than just the used components. For example, an identical combination of components may be configured in multiple ways and sold as variants of the same product. iiRDS provides the class iirds:ProductVariant to extend the iiRDS core and add proprietary product variants. Just like components, product variants are metadata labels for information units and do not represent a physical product. As product variants are a proprietary iiRDS extension, they shall be stored in the metadata.rdf of the iiRDS package.

The following example shows a definition of a proprietary product variant:

Example 13: Definition of a proprietary product variant

<iirds:ProductVariant rdf:about="http://myCompany.com/iirds/myProject/myPackage#FreshDelightE61">
    <rdfs:label xml:lang="en">Fresh Delight E61</rdfs:label>
</iirds:ProductVariant>

To map product variants in the iiRDS package to an external product ontology, a mapping ontology may use the property rdfs:seeAlso. The mapping is similar to the mapping of a component tree, see External Component Trees.

4.5.4.1 Directory nodes

To model navigation sequences and hierarchies of InformationUnits, iiRDS defines its own class DirectoryNode. With a directory node structure, users can get information on the context of the topic they are currently reading, its position in a document, its predecessors, and successors. In printed documentation, tables of contents usually provide this type of information.

iiRDS models navigation structures as linked lists. It does not use RDFS linked lists because RDFS linked lists cannot easily be used with other modeling languages. iiRDS linked lists consist of DirectoryNode nodes that reference the following node by the property has-next-sibling. Each node of an iiRDS linked list may reference an InformationUnit by the property references-information-unit.

To model closed lists, the last node in a list may reference an instance of the class nil.

The property has-directory-structure-type determines the type of the directory structure, for example a table of contents. The root node of a directory structure shall have one property has-directory-structure-type. Only root nodes of a directory structure shall have the property has-directory-structure-type.

Editor's note

There is no direct relation between information units that represents navigation structures. For example, topic 1 has no direct relation to its successor topic 2. With no direct reference, iiRDS can model reuse of information units in different contexts.

To model hierarchy levels in the navigation structure, a DirectoryNode instance can reference a DirectoryNode instance on the next lower level by the property has-first-child. The directory node on the next lower level is the first item in another linked list.

The directory nodes of a table of contents form a tree-like structure. Each hierarchy level constitutes a linked list. The top-level is a linked list with only one element, the root node. To find the root node of a table of content, query for all DirectoryNodes that satisfy the following conditions:

Property has-next-sibling points to nil
Property references-information-unit points to a document
Property has-directory-structure-type points to iirds:TableOfContents

The property rdfs:label can add a title to a directory node. Blank nodes can be used to add navigation titles that do not represent a topic.

Example 14: Table of Contents

The following example illustrates how to model a simple table of contents in iiRDS. The root node references a document and has a label. The additional label in the directory node structure overrules any title or label of the referenced information unit.

As the root directory node has no following sibling on the same hierarchy level, it forms a linked list with only one member. To close the linked list with only one element, the root directory node has nil as the next sibling. The next hierarchy level contains a linked list with directory nodes referencing chapter topic 1 and chapter topic 2. The first directory node on chapter level has an additional label “Topic 1”. An iiRDS consumer shall use the additional label for rendering in the directory structure. The second directory node on chapter level has no additional label. The iiRDS consumer can use the title of the referenced information unit for rendering. In this example, the instance topic_2 has the title “Transportation”.

<iirds:DirectoryNode rdf:about="http://myCompany.de/iirds/myPackage/manual_1">
    <rdfs:label>Table of Contents</rdfs:label>
    <iirds:has-directory-structure-type 
        rdf:resource="http://iirds.tekom.de/iirds#TableOfContents" />
    <iirds:has-first-child>
        <iirds:DirectoryNode>
            <iirds:references-information-unit 
                rdf:resource="http://myCompany.de/iirds/myPackage/topic_1"/>
            <rdfs:label>Topic 1</rdfs:label>
            <iirds:has-next-sibling>
                <iirds:DirectoryNode>
                    <iirds:references-information-unit
                        rdf:resource="http://myCompany.de/iirds/myPackage/topic_2"/>
                </iirds:DirectoryNode>
            </iirds:has-next-sibling>
            <iirds:has-next-sibling 
                rdf:resource="http://iirds.tekom.de/iirds#nil"/>
        </iirds:DirectoryNode>
    </iirds:has-first-child>
    <iirds:has-next-sibling rdf:resource="http://iirds.tekom.de/iirds#nil"/>
</iirds:DirectoryNode>

An iiRDS Consumer shall render the DirectoryNode structure in this example as follows:

Topic 1

Transportation

4.5.5 iiRDS Domains and Proprietary Extensions

iiRDS domain extensions: Provide a standardized vocabulary for specific domains, for example, iiRDS Machinery Domain. All classes and instances of an iiRDS domain are registered in a dedicated sub-namespace of the iiRDS core namespace.
Proprietary iiRDS extensions: iiRDS supports proprietary iiRDS extensions for company-specific and project-specific instances and classes. For example, a proprietary iiRDS extension may map a product ontology to the iiRDS core vocabulary. A proprietary iiRDS extension shall comply with the standard to allow standardized processing by iiRDS Consumers.

The iiRDS standard provides each iiRDS domain extension as a separate file. A party that generates or processes an iiRDS package can combine iiRDS domains and proprietary iiRDS extensions. All extensions that are used in a package shall be contained in the metadata.rdf file in the iiRDS package.

4.5.5.1 iiRDS Domain Extensions

iiRDS domain extensions provide additional classes and instances that extend the iiRDS core vocabulary. By separating domain-specific vocabulary from the core vocabulary, the standard aims to keep the iiRDS core vocabulary lean and easily accessible.

Instances and classes of iiRDS domain extensions reside in sub-namespaces of iiRDS. Currently, iiRDS provides the following iiRDS domain extensions:

iiRDS Machinery Domain: Classes and instances of the iiRDS Machinery Domain reside in the namespace

http://iirds.tekom.de/iirds/domain/machinery.
iiRDS Software Domain: Classes and instances of the iiRDS Software Domain reside in the namespace

http://iirds.tekom.de/iirds/domain/software.

4.5.5.1.1 Combination of iiRDS Core and Domain Vocabulary

The iiRDS standard does not stipulate how to combine iiRDS core vocabulary with extension vocabulary. Depending on the project requirements, the implementation can use existing frameworks to merge the vocabularies. For example, the JENA command line tool riot can read multiple input files and write them to one merged ontology file.

A tool-independent way of combining ontologies is the OWL import statement. The following example illustrates how to import the iiRDS Software Domain into another ontology.

Example 15: Importing an iiRDS domain into another ontology

<owl:Ontology>
    <owl:imports rdf:resource="file:/yourMachine/yourFolder/iiRDS_Software_Domain.rdfs"/>
</owl:Ontologie>

4.5.5.2 Proprietary iiRDS Extensions

Proprietary iiRDS extensions allow for adding proprietary vocabulary to iiRDS vocabulary. Proprietary iiRDS extensions can contain project specific-instances, classes, and properties. For example, the company-specific products and roles may be added as instances to iiRDS classes.

A proprietary iiRDS extension only complies with iiRDS if it fulfills the following conditions:

Proprietary classes, instances, and properties shall be registered to the namespace of the defining party.
The defining party shall provide the proprietary iiRDS extension to other parties if said other parties are expected to process the proprietary classes and instances.
Proprietary classes shall be subclasses or equivalent classes of existing iiRDS classes.
Proprietary instances shall be instances of existing iiRDS classes or subclasses. Proprietary instances may also be instances of a subclass or equivalent class of an iiRDS class.
Proprietary properties shall be sub-properties of existing properties.

Editor's note

iiRDS limits itself to RDF and RDFS. Proprietary iiRDS extensions shall only use RDF and RDFS vocabulary in their extension ontology. If OWL DL is used in an additional ontology, then the ontology is not iiRDS-compliant but can be mapped to the iiRDS vocabulary by means of the seeAlso property. For details read section External Product Ontology.

4.5.5.2.1 Adding a Proprietary Instance

Proprietary iiRDS extensions can add instances directly as an instance of an iiRDS class. The following example adds the proprietary instance ServiceTechnician to the iiRDS class iirds:Role.

Example 16: Adding a proprietary instance to iiRDS class

<rdf:RDF xml:lang="de" xmlns:iirds="http://iirds.tekom.de/iirds#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
    <iirds:Role rdf:about="http://myCompany.com/myProject#ServiceTechnician">
        <rdfs:label xml:lang="en">Service Technician
        <rdfs:label xml:lang="de">Servicetechniker
    </iirds:Role>
</rdf:RDF>

4.5.5.2.2 Adding a Proprietary Class

Proprietary iiRDS extensions can add classes directly as subclasses to an iiRDS class. The following example adds the proprietary class Error to the iiRDS class iirds:Event as a subclass. A proprietary implementation can add proprietary instances to the Error class and find them by searching for instances of the iirds:Event class.

Example 17: Adding a proprietary instance to an iiRDS class as a subclass

<rdf:RDF xml:lang="de" xmlns:iirds="http://iirds.tekom.de/iirds#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
    <rdfs:Class rdf:about="http://myCompany.com/myProject#Error">
        <rdfs:label xml:lang="en">Error
        <rdfs:label xml:lang="de">Fehler
        <rdfs:subClassOf rdf:resource="http://iirds.tekom.de/iirds#Event"/>
    </rdfs:Class>
</rdf:RDF>

Proprietary iiRDS extensions can add proprietary classes as equivalent classes. The property rdfs:subClassOf can express equivalence of classes. The following example shows the equivalent classes iirds:Component and my:ProductPart.

Example 18: Adding a proprietary class as an equivalent class

<rdfs:Class rdf:about="http://myCompany.com/myProject#ProductPart">
    <rdfs:subClassOf rdf:resource="http://iirds.tekom.de/iirds#Component"/>
</rdfs:Class>
<rdf:Description rdf:about="http://iirds.tekom.de/iirds#Component">
    <rdfs:subClassOf rdf:resource="http://myCompany.com/myProject#ProductPart"/>
</rdf:Description>

4.5.5.2.3 Adding a Proprietary Property

Proprietary iiRDS extensions can add proprietary properties as a subproperty of an iiRDS property. Proprietary properties shall comply with domain and range of the iiRDS property. The following example shows a proprietary property that points from iirds:InformationUnit to iirds:ProductLifeCyclePhase.

Example 19: Adding a proprietary property as a subproperty of an iiRDS property

<rdf:Property rdf:about="http://www.myCompany.com/iirds/myExtension#relates-to-product-life-cycle-phase">
    <rdfs:subPropertyOf rdf:resource="http://iirds.tekom.de/iirds#relates-to-product-metadata"/>
    <rdfs:domain rdf:resource="http://iirds.tekom.de/iirds#InformationUnit"/>
    <rdfs:range rdf:resource="http://iirds.tekom.de/iirds#ProductLifeCyclePhase"/>
</rdf:Property>

4.6 iiRDS RDF Schema Reference

4.6.1 Core

4.6.1.1 Class Definitions

AfterUse

Term	Description
URI:	http://iirds.tekom.de/iirds#AfterUse
Type of Term:	Class
Label:	After use
Sub Class Of:	ProductLifeCyclePhase
Description:	Not intended to be used directly. Use the subclasses instead. For life cycle phases not covered by the iiRDS standard subclasses, define custom subclasses.
Definition:	Parent class for iiRDS standard definitions of product life cycle phases that occur after the active use of the product.

Collection

Term	Description
URI:	http://iirds.tekom.de/iirds#Collection
Type of Term:	Class
Label:	Collection
Sub Class Of:	InformationSubject

Component

Term	Description
URI:	http://iirds.tekom.de/iirds#Component
Type of Term:	Class
Label:	Component
Sub Class Of:	ProductMetadata
Description:	Components may have relations to other components so that iiRDS compilers can build up a simply component hierarchy with iiRDS structures. The iirds#Component may also be used as a docking point for external component definitions.
Definition:	Describes a component of the technical system that the documentation refers to

Concept

Term	Description
URI:	http://iirds.tekom.de/iirds#Concept
Type of Term:	Class
Label:	Concept
Sub Class Of:	TopicType
Description:	Conceptual information helps users to map their existing knowledge to tasks and other essential information about a product or system.Shall only be assigned to information units of type "Topic".
Definition:	Class of topic types that provide background that helps readers understand essential information about a product, interface, or task.

Conformity

Term	Description
URI:	http://iirds.tekom.de/iirds#Conformity
Type of Term:	Class
Label:	Conformity
Sub Class Of:	InformationSubject

DesignAndRealization

Term	Description
URI:	http://iirds.tekom.de/iirds#DesignAndRealization
Type of Term:	Class
Label:	Design and realization
Sub Class Of:	ProductLifeCyclePhase
Description:	Not intended to be used directly. Use the subclasses instead. For life cycle phases not covered by the iiRDS standard subclasses, define custom subclasses.
Definition:	Parent class for subclasses that describe product life cycle phases related to the design, construction, and realization of a product

DirectoryNode

Term	Description
URI:	http://iirds.tekom.de/iirds#DirectoryNode
Type of Term:	Class
Label:	Directory node
Sub Class Of:	iirdsDomainEntitiy
Description:	A directory is a tree-like, ordered collection of information units.Directory nodes are the entries in the directory. Directories help the user to navigate through the information units. A table of contents is a typical example of a directory.
Definition:	A node in a directory

DirectoryNodeType

Term	Description
URI:	http://iirds.tekom.de/iirds#DirectoryNodeType
Type of Term:	Class
Label:	Directory node type
Sub Class Of:	InformationType
Description:	A directory represented by a directory root node and its sub nodes has a type such as 'table of contens' or 'list of figures'.
Definition:	Directory type

Document

Term	Description
URI:	http://iirds.tekom.de/iirds#Document
Type of Term:	Class
Label:	Document
Sub Class Of:	InformationUnit
Description:	A document consists of one or more files. It can be made up from topics. The resource is either a blank node (when there is not a file representing the document) or a file in the iiRDS package.
Definition:	A unit of information in an iiRDS package making up a complete document.

DocumentationMetadata

Term	Description
URI:	http://iirds.tekom.de/iirds#DocumentationMetadata
Type of Term:	Class
Label:	Documentation metadata
Sub Class Of:	iirdsDomainEntitiy
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for functional metadata and product metadata

DocumentType

Term	Description
URI:	http://iirds.tekom.de/iirds#DocumentType
Type of Term:	Class
Label:	Document type
Sub Class Of:	InformationType
Description:	Document types define the intended purpose of a document.
Definition:	The type of a document.

DownTime

Term	Description
URI:	http://iirds.tekom.de/iirds#DownTime
Type of Term:	Class
Label:	Down time
Sub Class Of:	PlanningTime
Definition:	Type of planning time: Period of time during which a technical system is stopped, especially during setup for an operation or when making repairs.

Event

Term	Description
URI:	http://iirds.tekom.de/iirds#Event
Type of Term:	Class
Label:	Event
Sub Class Of:	FunctionalMetadata
Description:	Examples are errors, malfunctions, and warnings. Use the relates-to-event property to create a reference from an information unit to an event.
Definition:	Describes events that happen in the technical system

Form

Term	Description
URI:	http://iirds.tekom.de/iirds#Form
Type of Term:	Class
Label:	Form
Sub Class Of:	TopicType

Formality

Term	Description
URI:	http://iirds.tekom.de/iirds#Formality
Type of Term:	Class
Label:	Formality
Sub Class Of:	InformationSubject

Fragment

Term	Description
URI:	http://iirds.tekom.de/iirds#Fragment
Type of Term:	Class
Label:	Fragment
Sub Class Of:	InformationUnit
Description:	Sections, tables, lists, paragraphs and hazard statement are examples of fragments. Fragments are usually parts of topic or document files in an iiRDS package identified by a fragment identifier in the IRI.
Definition:	A piece of information within a document of topic.

FragmentSelector

Term	Description
URI:	http://iirds.tekom.de/iirds#FragmentSelector
Type of Term:	Class
Label:	Fragment selector
Sub Class Of:	Selector
Definition:	Points to a fragment in a physical resource.

Functionality

Term	Description
URI:	http://iirds.tekom.de/iirds#Functionality
Type of Term:	Class
Label:	Functionality
Sub Class Of:	InformationSubject

FunctionalMetadata

Term	Description
URI:	http://iirds.tekom.de/iirds#FunctionalMetadata
Type of Term:	Class
Label:	Functional metadata
Sub Class Of:	DocumentationMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for metadata supporting advanced content delivery scenarios and content assemblies for specific purposes.

iirdsDomainEntitiy

Term	Description
URI:	http://iirds.tekom.de/iirds#iirdsDomainEntitiy
Type of Term:	Class
Label:	iirdsDomainEntitiy
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	An entity of the iiRDS domain

InformationSubject

Term	Description
URI:	http://iirds.tekom.de/iirds#InformationSubject
Type of Term:	Class
Label:	Information subject
Sub Class Of:	InformationType

InformationType

Term	Description
URI:	http://iirds.tekom.de/iirds#InformationType
Type of Term:	Class
Label:	Information type
Sub Class Of:	iirdsDomainEntitiy
Description:	Not indented to be used directly.
Definition:	Type of information. Abstract base class of document and topic type.

InformationUnit

Term	Description
URI:	http://iirds.tekom.de/iirds#InformationUnit
Type of Term:	Class
Label:	Information unit
Sub Class Of:	iirdsDomainEntitiy
Description:	Not intended to be used directly. Use the subclasses Package, Document, Topic, and Fragment instead.
Definition:	A unit of information. An Information unit is the abstract base class of information units, such as packages, documents, topics, and fragments.

Learning

Term	Description
URI:	http://iirds.tekom.de/iirds#Learning
Type of Term:	Class
Label:	Learning
Sub Class Of:	TopicType
Description:	Learning content may comprise learning plans, learning objectives, learning content details, summaries, and assessments.Shall only be assigned to information units of type "Topic".
Definition:	Class of topic types for learning. Learning content may comprise learning plans, learning objectives, learning content details, summaries, and assessments.Shall only be assigned to information units of type "Topic".

MaintenanceInterval

Term	Description
URI:	http://iirds.tekom.de/iirds#MaintenanceInterval
Type of Term:	Class
Label:	Maintenance interval
Sub Class Of:	PlanningTime
Definition:	Type of planning time: Fixed time interval for the scheduled maintenance of a technical system or its parts.

nil

Term	Description
URI:	http://iirds.tekom.de/iirds#nil
Type of Term:	Class
Label:	End of Directory node
Sub Class Of:	DirectoryNode
Definition:	The end in a chain of directory nodes

Package

Term	Description
URI:	http://iirds.tekom.de/iirds#Package
Type of Term:	Class
Label:	Package
Sub Class Of:	InformationUnit
Description:	There is exactly one Package instance within an iiRDS package. It holds general metadata on the overall iiRDS package. A blank node or the relative resource IRI “#” must be used for the package.
Definition:	A set of information in terms of documents and topics with its metadata

PlanningTime

Term	Description
URI:	http://iirds.tekom.de/iirds#PlanningTime
Type of Term:	Class
Label:	Planning time
Sub Class Of:	FunctionalMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for different types of planning times that may be referenced in technical documentation. Planning times describe periods of time required for or resulting from specific working tasks.

Process

Term	Description
URI:	http://iirds.tekom.de/iirds#Process
Type of Term:	Class
Label:	Process
Sub Class Of:	InformationSubject

ProductFeature

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductFeature
Type of Term:	Class
Label:	Product feature
Sub Class Of:	ProductMetadata

ProductLifeCyclePhase

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductLifeCyclePhase
Type of Term:	Class
Label:	Phase of product life cycle
Sub Class Of:	ProductMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for standardized product life cycle phases that technical documentation may refer to

ProductMetadata

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductMetadata
Type of Term:	Class
Label:	ProductMetadata
Sub Class Of:	DocumentationMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for product-related metadata

ProductVariant

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductVariant
Type of Term:	Class
Label:	Product variant
Sub Class Of:	ProductMetadata

PuttingToUse

Term	Description
URI:	http://iirds.tekom.de/iirds#PuttingToUse
Type of Term:	Class
Label:	Putting to use
Sub Class Of:	ProductLifeCyclePhase
Description:	Not intended to be used directly. Use the subclasses instead. For life cycle phases not covered by the iiRDS standard subclasses, define custom subclasses.
Definition:	Parent class for subclasses that describe product life cycle phases related to putting a product or technical system to use

Qualification

Term	Description
URI:	http://iirds.tekom.de/iirds#Qualification
Type of Term:	Class
Label:	Qualification
Sub Class Of:	FunctionalMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for different types of skills and roles required for working tasks described in technical documentation.

RangeSelector

Term	Description
URI:	http://iirds.tekom.de/iirds#RangeSelector
Type of Term:	Class
Label:	Range selector
Sub Class Of:	Selector
Definition:	Points to a range in a physical resource. Has a start and end point.

Reference

Term	Description
URI:	http://iirds.tekom.de/iirds#Reference
Type of Term:	Class
Label:	Reference
Sub Class Of:	TopicType
Description:	Examples are parameter lists, tables with technical data, UI control overviews, and parts lists. Shall only be assigned to information units of type "Topic".
Definition:	Class of topic types that contain information that supports users as they perform a task, meaning data that is looked up rather than memorized.

Rendition

Term	Description
URI:	http://iirds.tekom.de/iirds#Rendition
Type of Term:	Class
Label:	Rendition
Sub Class Of:	iirdsDomainEntitiy
Definition:	Content of an information unit in a specific format

Role

Term	Description
URI:	http://iirds.tekom.de/iirds#Role
Type of Term:	Class
Label:	Role
Sub Class Of:	Qualification
Description:	Describes a set of connected behaviors, privileges and obligations associated with users (humans, software processes or devices) of a system
Definition:	Docking point for custom roles for users of the technical system and the associated technical information

Safety

Term	Description
URI:	http://iirds.tekom.de/iirds#Safety
Type of Term:	Class
Label:	Safety
Sub Class Of:	InformationSubject

Selector

Term	Description
URI:	http://iirds.tekom.de/iirds#Selector
Type of Term:	Class
Label:	Selector
Sub Class Of:	iirdsDomainEntitiy
Description:	ClassDescription
Definition:	Pointer to a physical resource.

SkillLevel

Term	Description
URI:	http://iirds.tekom.de/iirds#SkillLevel
Type of Term:	Class
Label:	Skill level
Sub Class Of:	Qualification
Description:	Describe the levels of ability required to carry out a specific task described in the technical documentation.
Definition:	Docking point for custom skill levels that the users of the technical system and the associated technical information require

Supply

Term	Description
URI:	http://iirds.tekom.de/iirds#Supply
Type of Term:	Class
Label:	Supply
Sub Class Of:	FunctionalMetadata
Description:	Not intended to be used directly. Use the subclasses instead.
Definition:	Parent class for different types of supplies required for working tasks described in technical documentation.

Task

Term	Description
URI:	http://iirds.tekom.de/iirds#Task
Type of Term:	Class
Label:	Task
Sub Class Of:	TopicType
Description:	Tasks provide instructions and may contain information on other aspects, such as requirements that must be fulfilled or safety instructions.Shall only be assigned to information units of type "Topic".
Definition:	Class of topic types that contains procedural information for work activities.

TechnicalData

Term	Description
URI:	http://iirds.tekom.de/iirds#TechnicalData
Type of Term:	Class
Label:	Technical data
Sub Class Of:	InformationSubject

TechnicalOverview

Term	Description
URI:	http://iirds.tekom.de/iirds#TechnicalOverview
Type of Term:	Class
Label:	Technical overview
Sub Class Of:	InformationSubject

Topic

Term	Description
URI:	http://iirds.tekom.de/iirds#Topic
Type of Term:	Class
Label:	Topic
Sub Class Of:	InformationUnit
Description:	The resource of a topic is a file in the iiRDS package.
Definition:	A topic is a unit of information covering a single subject.

TopicType

Term	Description
URI:	http://iirds.tekom.de/iirds#TopicType
Type of Term:	Class
Label:	Topic type
Sub Class Of:	InformationType
Description:	Possible types include task, learning, and concept. InformationUnits that represent topics may have one or more has-topic-type properties that define the topic's information type. Topics without a has-topic-type property are generic topics, with no specific type.
Definition:	Defines the information type of an iiRDS topic.

Troubleshooting

Term	Description
URI:	http://iirds.tekom.de/iirds#Troubleshooting
Type of Term:	Class
Label:	Troubleshooting
Sub Class Of:	TopicType
Definition:	Class of topic types. Troublesshooting content helps to eliminate a fault by means of appropriate remedial measures

Use

Term	Description
URI:	http://iirds.tekom.de/iirds#Use
Type of Term:	Class
Label:	Use
Sub Class Of:	ProductLifeCyclePhase
Description:	Not intended to be used directly. Use the subclasses instead. For life cycle phases not covered by the iiRDS standard subclasses, define custom subclasses.
Definition:	Parent class for subclasses that describe product life cycle phases related to using a product or technical system

WorkingTime

Term	Description
URI:	http://iirds.tekom.de/iirds#WorkingTime
Type of Term:	Class
Label:	Working time
Sub Class Of:	PlanningTime
Definition:	Type of planning time: Period of time that is required for a specific working task.

4.6.1.2 Property Definitions

dateOfCreation

Term	Description
URI:	http://iirds.tekom.de/iirds#dateOfCreation
Type of Term:	Property
Label:	Date of Creation
Sub Property Of:	http://purl.org/dc/terms/created
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Definition:	Date of creation of the information unit

description

Term	Description
URI:	http://iirds.tekom.de/iirds#description
Type of Term:	Property
Label:	Description
Sub Property Of:	http://purl.org/dc/terms/description
Sub Property Of:	iirdsAttribute
Has Domain:	iirdsDomainEntitiy
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	Typically a free-text acount of the resource
Definition:	An account of the resource

duration

Term	Description
URI:	http://iirds.tekom.de/iirds#duration
Type of Term:	Property
Label:	Duration
Sub Property Of:	iirdsAttribute
Has Domain:	PlanningTime
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Definition:	A span of time

format

Term	Description
URI:	http://iirds.tekom.de/iirds#format
Type of Term:	Property
Label:	Format
Sub Property Of:	iirdsAttribute
Sub Property Of:	http://purl.org/dc/terms/format
Has Domain:	Rendition
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Definition:	Media type (MIME type) of the rendition

formatRestriction

Term	Description
URI:	http://iirds.tekom.de/iirds#formatRestriction
Type of Term:	Property
Label:	Format Restriction
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	Value "A" means that the package uses a restricted set of media formats ("iiRDS/A").
Definition:	Restriction to the media formats used in the package

identifier

Term	Description
URI:	http://iirds.tekom.de/iirds#identifier
Type of Term:	Property
Label:	Identifier
Sub Property Of:	http://purl.org/dc/terms/identifier
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	Recommended best practice is to identify the resource by means of a string conforming to a formal identification system
Definition:	An unambiguous reference to the resource within a given context

iirdsAttribute

Term	Description
URI:	http://iirds.tekom.de/iirds#iirdsAttribute
Type of Term:	Property
Label:	iirdsAttribute
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal

iiRDSVersion

Term	Description
URI:	http://iirds.tekom.de/iirds#iiRDSVersion
Type of Term:	Property
Label:	iiRDS version
Sub Property Of:	iirdsAttribute
Has Domain:	Package
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Definition:	iiRDS version, the iiRDS package is complying to

language

Term	Description
URI:	http://iirds.tekom.de/iirds#language
Type of Term:	Property
Label:	Language
Sub Property Of:	http://purl.org/dc/terms/language
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	Controlled vocabulary according to RFC 4646.
Definition:	A language of the resource.

rights

Term	Description
URI:	http://iirds.tekom.de/iirds#rights
Type of Term:	Property
Label:	Rights
Sub Property Of:	http://purl.org/dc/elements/1.1/rights
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Definition:	Information about rights held in and over the resource

source

Term	Description
URI:	http://iirds.tekom.de/iirds#source
Type of Term:	Property
Label:	Source
Sub Property Of:	iirdsAttribute
Has Domain:	Rendition
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	The path is relative to the root directory of the package, e.g., "content/overview.html"
Definition:	Relative path to the file containing the content of a rendition

synonym

Term	Description
URI:	http://iirds.tekom.de/iirds#synonym
Type of Term:	Property
Label:	Synonym
Sub Property Of:	iirdsAttribute
Has Domain:	iirdsDomainEntitiy
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal

title

Term	Description
URI:	http://iirds.tekom.de/iirds#title
Type of Term:	Property
Label:	Title
Sub Property Of:	http://purl.org/dc/terms/title
Sub Property Of:	iirdsAttribute
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2000/01/rdf-schema#Literal
Description:	Typically, a Title will be a name by which the information unit is formally known
Definition:	A name given to the information unit

4.6.1.3 Relations

applicable-for-document-type

Term	Description
URI:	http://iirds.tekom.de/iirds#applicable-for-document-type
Type of Term:	Property
Label:	applicable for document type
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	DocumentType

has-abstract

Term	Description
URI:	http://iirds.tekom.de/iirds#has-abstract
Type of Term:	Property
Label:	has abstract
Sub Property Of:	http://purl.org/dc/terms/abstract
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationUnit

has-author

Term	Description
URI:	http://iirds.tekom.de/iirds#has-author
Type of Term:	Property
Label:	has author
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2006/vcard/ns#Kind
Definition:	References an author of the informnation unit

has-component

Term	Description
URI:	http://iirds.tekom.de/iirds#has-component
Type of Term:	Property
Label:	has component
Sub Property Of:	iirdsRelationConcept
Has Domain:	Component
Has Range:	Component
Definition:	Relates to a component beloging to an other component

has-contributor

Term	Description
URI:	http://iirds.tekom.de/iirds#has-contributor
Type of Term:	Property
Label:	has contributor
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	http://www.w3.org/2006/vcard/ns#Kind
Description:	Organisations and persons are examples of contributors.
Definition:	References a contributor of an information unit

has-directory-structure-type

Term	Description
URI:	http://iirds.tekom.de/iirds#has-directory-structure-type
Type of Term:	Property
Label:	has directory structure type
Sub Property Of:	iirdsRelationConcept
Has Domain:	DirectoryNode
Has Range:	DirectoryNodeType
Definition:	The nature of the directory

has-document-type

Term	Description
URI:	http://iirds.tekom.de/iirds#has-document-type
Type of Term:	Property
Label:	has document type
Sub Property Of:	has-information-type
Has Domain:	Document
Has Range:	DocumentType
Description:	Documents have one or more document types. Documents without document types are unspecific documents.
Definition:	The type of a document.

has-end-selector

Term	Description
URI:	http://iirds.tekom.de/iirds#has-end-selector
Type of Term:	Property
Label:	has end selector
Sub Property Of:	has-selector
Has Domain:	RangeSelector
Has Range:	FragmentSelector

has-event-code

Term	Description
URI:	http://iirds.tekom.de/iirds#has-event-code
Type of Term:	Property
Label:	has event code
Sub Property Of:	iirdsRelationConcept
Has Domain:	Event

has-event-type

Term	Description
URI:	http://iirds.tekom.de/iirds#has-event-type
Type of Term:	Property
Label:	has event type
Sub Property Of:	iirdsRelationConcept
Has Domain:	Event

has-first-child

Term	Description
URI:	http://iirds.tekom.de/iirds#has-first-child
Type of Term:	Property
Label:	has first child
Sub Property Of:	iirdsRelationConcept
Has Domain:	DirectoryNode
Has Range:	DirectoryNode
Definition:	References the first directory node on the next sub level

has-information-type

Term	Description
URI:	http://iirds.tekom.de/iirds#has-information-type
Type of Term:	Property
Label:	has information type
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationType
Description:	Not intended to be used directly. Use has-document-type for documents and has-topic-type for topics.
Definition:	The nature of an information unit.

has-next-sibling

Term	Description
URI:	http://iirds.tekom.de/iirds#has-next-sibling
Type of Term:	Property
Label:	has next sibling
Sub Property Of:	iirdsRelationConcept
Has Domain:	DirectoryNode
Has Range:	DirectoryNode
Definition:	References the following directory node following at the same hierarchy level in a directory structure

has-rendition

Term	Description
URI:	http://iirds.tekom.de/iirds#has-rendition
Type of Term:	Property
Label:	has rendition
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	Rendition
Definition:	Relates to a rendition of an information unit

has-selector

Term	Description
URI:	http://iirds.tekom.de/iirds#has-selector
Type of Term:	Property
Label:	has selector
Sub Property Of:	iirdsRelationConcept
Has Domain:	Rendition
Has Range:	Selector

has-start-selector

Term	Description
URI:	http://iirds.tekom.de/iirds#has-start-selector
Type of Term:	Property
Label:	has start selector
Sub Property Of:	has-selector
Has Domain:	RangeSelector
Has Range:	FragmentSelector

has-subject

Term	Description
URI:	http://iirds.tekom.de/iirds#has-subject
Type of Term:	Property
Label:	has subject
Sub Property Of:	http://purl.org/dc/terms/subject
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationSubject
Definition:	Reference the subject of an information unit

has-topic-type

Term	Description
URI:	http://iirds.tekom.de/iirds#has-topic-type
Type of Term:	Property
Label:	has topic type
Sub Property Of:	has-information-type
Has Domain:	InformationUnit
Has Range:	TopicType
Description:	Not intended to be used directly. Use has-document-type for documents and has-topic-type for topics.
Definition:	The nature of an information unit.

has-version

Term	Description
URI:	http://iirds.tekom.de/iirds#has-version
Type of Term:	Property
Label:	has version
Sub Property Of:	http://purl.org/dc/terms/hasVersion
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationUnit
Description:	Relates an information unit to another resource. The other resource is another version of the information unit.
Definition:	A related resource that is a version, edition, or adaptation of the described resource.

iirdsRelationConcept

Term	Description
URI:	http://iirds.tekom.de/iirds#iirdsRelationConcept
Type of Term:	Property
Label:	iirdsRelationConcept
Has Domain:	iirdsDomainEntitiy
Has Range:	iirdsDomainEntitiy

is-part-of-package

Term	Description
URI:	http://iirds.tekom.de/iirds#is-part-of-package
Type of Term:	Property
Label:	is part of package
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	Package

is-version-of

Term	Description
URI:	http://iirds.tekom.de/iirds#is-version-of
Type of Term:	Property
Label:	is version of
Sub Property Of:	http://purl.org/dc/terms/isVersionOf
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationUnit
Description:	Relates an information unit to another resource. The information unit is another version of the resource.
Definition:	A related resource of which the described resource is a version, edition, or adaptation.

references-information-unit

Term	Description
URI:	http://iirds.tekom.de/iirds#references-information-unit
Type of Term:	Property
Label:	references information unit
Sub Property Of:	iirdsRelationConcept
Has Domain:	DirectoryNode
Has Range:	InformationUnit

relates-to

Term	Description
URI:	http://iirds.tekom.de/iirds#relates-to
Type of Term:	Property
Label:	relates to
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	DocumentationMetadata
Description:	No intended to be used directly. Use the subclasses instead.
Definition:	Relates an iiRDS entity to another one

relates-to-event

Term	Description
URI:	http://iirds.tekom.de/iirds#relates-to-event
Type of Term:	Property
Label:	relates to event
Sub Property Of:	relates-to
Has Domain:	InformationUnit
Has Range:	Event

relates-to-product-metadata

Term	Description
URI:	http://iirds.tekom.de/iirds#relates-to-product-metadata
Type of Term:	Property
Label:	relates to product metadata
Sub Property Of:	relates-to
Has Domain:	InformationUnit
Has Range:	ProductMetadata

replaces

Term	Description
URI:	http://iirds.tekom.de/iirds#replaces
Type of Term:	Property
Label:	replaces
Sub Property Of:	http://purl.org/dc/terms/replaces
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	InformationUnit

requires

Term	Description
URI:	http://iirds.tekom.de/iirds#requires
Type of Term:	Property
Label:	requires
Sub Property Of:	iirdsRelationConcept
Has Domain:	InformationUnit
Has Range:	FunctionalMetadata

requires-qualification

Term	Description
URI:	http://iirds.tekom.de/iirds#requires-qualification
Type of Term:	Property
Label:	requires qualification
Sub Property Of:	requires
Has Domain:	InformationUnit
Has Range:	Qualification

requires-supply

Term	Description
URI:	http://iirds.tekom.de/iirds#requires-supply
Type of Term:	Property
Label:	requires supply
Sub Property Of:	requires
Has Domain:	InformationUnit
Has Range:	Supply

requires-time

Term	Description
URI:	http://iirds.tekom.de/iirds#requires-time
Type of Term:	Property
Label:	requires time
Sub Property Of:	requires
Has Domain:	InformationUnit
Has Range:	PlanningTime

4.6.1.4 Object Definitions

Acquisition

Term	Description
URI:	http://iirds.tekom.de/iirds#Acquisition
Type of Term:	DesignAndRealization
Label:	Acquisition
Definition:	Life cycle phase of a product during which services, goods, or works are acquired from an external source.

AdministratorGuide

Term	Description
URI:	http://iirds.tekom.de/iirds#AdministratorGuide
Type of Term:	DocumentType
Label:	Administrator guide
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains instructions for the administration of a technical system.

ApplicableStandards

Term	Description
URI:	http://iirds.tekom.de/iirds#ApplicableStandards
Type of Term:	Conformity
Label:	Applicable standard

AssemblyInstructions

Term	Description
URI:	http://iirds.tekom.de/iirds#AssemblyInstructions
Type of Term:	DocumentType
Label:	Assembly instructions
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains instructions enabling the operator to assemble a physical product so that it fulfills its intended use and does not endanger the health and safety of persons.

CEDeclarationOfConformity

Term	Description
URI:	http://iirds.tekom.de/iirds#CEDeclarationOfConformity
Type of Term:	DocumentType
Label:	CE declaration of conformity
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Created as a result of a procedure whereby the manufacture or authorized representative "ensures and declares" that the products concerned satisfy the requirements of the directives that apply to them.

Configuration

Term	Description
URI:	http://iirds.tekom.de/iirds#Configuration
Type of Term:	PuttingToUse
Label:	Configuration
Definition:	Life cycle phase of a product describing activities related to configuring the settings of a technical system before use.

ContactInformation

Term	Description
URI:	http://iirds.tekom.de/iirds#ContactInformation
Type of Term:	Formality
Label:	Contact information

DeclarationOfConformity

Term	Description
URI:	http://iirds.tekom.de/iirds#DeclarationOfConformity
Type of Term:	Conformity
Label:	Declaration of conformity
Description:	please review
Definition:	Information subject. Declaration of conformity.

Decommissioning

Term	Description
URI:	http://iirds.tekom.de/iirds#Decommissioning
Type of Term:	Use
Label:	Decommissioning
Definition:	Life cycle phase of a product describing the shut-down and transfer into a safe state.

Design

Term	Description
URI:	http://iirds.tekom.de/iirds#Design
Type of Term:	DesignAndRealization
Label:	Design

Development

Term	Description
URI:	http://iirds.tekom.de/iirds#Development
Type of Term:	DesignAndRealization
Label:	Development
Definition:	Life cycle phase of a product progressing from detailed design to prototyping through pilot release to full product launch.

Diagnostics

Term	Description
URI:	http://iirds.tekom.de/iirds#Diagnostics
Type of Term:	Use
Label:	Diagnostics
Definition:	Life cycle phase of a product containing procedures for locating errors

Disposal

Term	Description
URI:	http://iirds.tekom.de/iirds#Disposal
Type of Term:	AfterUse
Label:	Disposal
Definition:	Life cycle phase of a product describing the elimination of components, mounted parts and lubricant considering the country-specific current law.

EmergencyOperation

Term	Description
URI:	http://iirds.tekom.de/iirds#EmergencyOperation
Type of Term:	Use
Label:	Emergency operation
Definition:	Product life cycle phase of a technical system in which the system's functionality is reduced to a minimum due to an error or emergency situation.

Fault

Term	Description
URI:	http://iirds.tekom.de/iirds#Fault
Type of Term:	Use
Label:	Fault
Definition:	Product life cycle phase of a technical system in which the intended use and operation of a technical system or software is interrupted due to an error or malfunction.

ForeseeableMisuse

Term	Description
URI:	http://iirds.tekom.de/iirds#ForeseeableMisuse
Type of Term:	Safety
Label:	Foreseeable misuse

GenericAfterUse

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericAfterUse
Type of Term:	AfterUse
Label:	After use

GenericCollection

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericCollection
Type of Term:	Collection
Label:	Collection
Description:	please review
Definition:	Information subject. Collection of unspecific information items, usually gathered from different parts of an information unit.

GenericConcept

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericConcept
Type of Term:	Concept
Label:	Concept
Description:	Conceptual information helps users to map their existing knowledge to tasks and other essential information about a product or system.Shall only be assigned to information units of type "Topic".
Definition:	Topic type that provides background that helps readers understand essential information about a product, interface, or task.

GenericConformity

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericConformity
Type of Term:	Conformity
Label:	Conformity

GenericDesignAndRealization

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericDesignAndRealization
Type of Term:	DesignAndRealization
Label:	Design and realization

GenericDownTime

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericDownTime
Type of Term:	DownTime
Label:	Down time

GenericEvent

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericEvent
Type of Term:	Event
Label:	Event

GenericForm

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericForm
Type of Term:	Form
Label:	Form

GenericFormality

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericFormality
Type of Term:	Formality
Label:	Formality

GenericFunctionality

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericFunctionality
Type of Term:	Functionality
Label:	Functionality

GenericLearning

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericLearning
Type of Term:	Learning
Label:	Learning
Description:	Learning content may comprise learning plans, learning objectives, learning content details, summaries, and assessments.Shall only be assigned to information units of type "Topic".
Definition:	Topic type that provides learning content.

GenericMaintenanceInterval

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericMaintenanceInterval
Type of Term:	MaintenanceInterval
Label:	Maintenance interval

GenericPlanningTime

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericPlanningTime
Type of Term:	PlanningTime
Label:	Planning time

GenericProcess

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericProcess
Type of Term:	Process
Label:	Process

GenericProductFeature

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericProductFeature
Type of Term:	ProductFeature
Label:	Product feature

GenericPuttingToUse

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericPuttingToUse
Type of Term:	PuttingToUse
Label:	Putting to use

GenericReference

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericReference
Type of Term:	Reference
Label:	Reference
Description:	Examples are parameter lists, tables with technical data, UI control overviews, and parts lists. Shall only be assigned to information units of type "Topic".
Definition:	Topic type that contains information that supports users as they perform a task, meaning data that is looked up rather than memorized.

GenericRole

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericRole
Type of Term:	Role
Label:	Role

GenericSafety

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericSafety
Type of Term:	Safety
Label:	Safety

GenericSkillLevel

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericSkillLevel
Type of Term:	SkillLevel
Label:	Skill level

GenericSupply

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericSupply
Type of Term:	Supply
Label:	Generic supply

GenericTask

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericTask
Type of Term:	Task
Label:	Task
Description:	Tasks provide instructions and may contain information on other aspects, such as requirements that must be fulfilled or safety instructions.Shall only be assigned to information units of type "Topic".
Definition:	Topic type that contains procedural information for work activities.

GenericTechnicalData

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericTechnicalData
Type of Term:	TechnicalData
Label:	Technical data

GenericTechnicalOverview

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericTechnicalOverview
Type of Term:	TechnicalOverview
Label:	Technical overview

GenericTroubleshooting

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericTroubleshooting
Type of Term:	Troubleshooting
Label:	Troubleshooting
Definition:	Eliminate a fault by means of appropriate remedial measures

GenericUse

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericUse
Type of Term:	Use
Label:	Use

GenericWorkingTime

Term	Description
URI:	http://iirds.tekom.de/iirds#GenericWorkingTime
Type of Term:	WorkingTime
Label:	Generic working time

Index

Term	Description
URI:	http://iirds.tekom.de/iirds#Index
Type of Term:	DirectoryNodeType
Label:	Index
Definition:	Index directory type

Installation

Term	Description
URI:	http://iirds.tekom.de/iirds#Installation
Type of Term:	PuttingToUse
Label:	Installation
Definition:	Life cycle phase of a product containing procedures for installing and setting up a software or IT system.

InstallationGuide

Term	Description
URI:	http://iirds.tekom.de/iirds#InstallationGuide
Type of Term:	DocumentType
Label:	Installation instructions
Description:	For physical products: instructions enabling the operator to assemble and electrically connect a physical product so that it fulfills its intended use and does not endanger the health and safety of persons. For IT products: Instructions enabling the administrator to set up and potentially configure a program or new version on a computer so that does not endanger data security. Shall only be assigned to information units of type "Document".
Definition:	Type of document. Contains instructions enabling the operator or administrator to assemble or install a physical product or software so that it fulfills its intended use.

IntendedUse

Term	Description
URI:	http://iirds.tekom.de/iirds#IntendedUse
Type of Term:	Safety
Label:	Intended use
Definition:	Information subject: Legal concept outlining the field of application specified in matters of design and construction of the machinery which is described in the operating instructions/technical documentation, including considerations of the reasonable foreseeable use and potential misapplication

LegalInformation

Term	Description
URI:	http://iirds.tekom.de/iirds#LegalInformation
Type of Term:	Formality
Label:	Legal information

LicenceTerm

Term	Description
URI:	http://iirds.tekom.de/iirds#LicenceTerm
Type of Term:	Formality
Label:	License terms

ListOfFigures

Term	Description
URI:	http://iirds.tekom.de/iirds#ListOfFigures
Type of Term:	DirectoryNodeType
Label:	List of figures
Synonym:	LOF
Definition:	List of figures

ListOfListings

Term	Description
URI:	http://iirds.tekom.de/iirds#ListOfListings
Type of Term:	DirectoryNodeType
Label:	List of Listings
Synonym:	LOL
Definition:	Code listing directory type

ListOfTables

Term	Description
URI:	http://iirds.tekom.de/iirds#ListOfTables
Type of Term:	DirectoryNodeType
Label:	List of tables
Synonym:	LOT
Definition:	List of tables

Maintenance

Term	Description
URI:	http://iirds.tekom.de/iirds#Maintenance
Type of Term:	Use
Label:	Maintenance
Definition:	Life cycle phase of a product that describes activities for moving or conveying the product from one place to another.

MaintenanceInstructions

Term	Description
URI:	http://iirds.tekom.de/iirds#MaintenanceInstructions
Type of Term:	DocumentType
Label:	Maintenance instructions
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains instructions for retaining or restoring a piece of equipment, machine, or system to the specified operable condition.

ManufacturerInformation

Term	Description
URI:	http://iirds.tekom.de/iirds#ManufacturerInformation
Type of Term:	Formality
Label:	Manufacturer information

OperatingElement

Term	Description
URI:	http://iirds.tekom.de/iirds#OperatingElement
Type of Term:	TechnicalOverview
Label:	Control element

OperatingInstructions

Term	Description
URI:	http://iirds.tekom.de/iirds#OperatingInstructions
Type of Term:	DocumentType
Label:	Operating instructions
Description:	The instructions in this document type shall enable the user to operate a device, machine, or software considering the reference use as well as the safety and health regulations for the product. Shall only be assigned to information units of type "Document".
Definition:	Type of document. Contains instructions for operation and use of a technical system.

Operation

Term	Description
URI:	http://iirds.tekom.de/iirds#Operation
Type of Term:	Use
Label:	Operation
Definition:	Life cycle phase of a product in which a technical product or system is actively used and operated.

PartsCatalog

Term	Description
URI:	http://iirds.tekom.de/iirds#PartsCatalog
Type of Term:	DocumentType
Label:	Parts catalog
Definition:	Type of document. Contains listings of product names and their part numbers and graphics which are necessary for the aftersales service, but do not include prices or availabilities.

ProductIdentification

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductIdentification
Type of Term:	Formality
Label:	Product identification

Production

Term	Description
URI:	http://iirds.tekom.de/iirds#Production
Type of Term:	DesignAndRealization
Label:	Production

ProductName

Term	Description
URI:	http://iirds.tekom.de/iirds#ProductName
Type of Term:	Formality
Label:	Product name

QuickGuide

Term	Description
URI:	http://iirds.tekom.de/iirds#QuickGuide
Type of Term:	DocumentType
Label:	Quick reference guide
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Describes a short document that contains selected instructions for a specific user group or purpose.

Repair

Term	Description
URI:	http://iirds.tekom.de/iirds#Repair
Type of Term:	Use
Label:	Repair
Definition:	Life cycle phase of a product that describes activities for restoring the product to a working and sound condition after damage or wear and tear.

RepairInstructions

Term	Description
URI:	http://iirds.tekom.de/iirds#RepairInstructions
Type of Term:	DocumentType
Label:	Repair instructions
Description:	The instructions in this document type shall enable the user to repair a device, machine, or system considering the reference use as well as the safety and health regulations for the product. Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains instructions for restoring a product to a working condition.

RequirementsAnalysis

Term	Description
URI:	http://iirds.tekom.de/iirds#RequirementsAnalysis
Type of Term:	DesignAndRealization
Label:	Requirement analysis

RestrictionOnUse

Term	Description
URI:	http://iirds.tekom.de/iirds#RestrictionOnUse
Type of Term:	Safety
Label:	Restriction on use

RiskAssessment

Term	Description
URI:	http://iirds.tekom.de/iirds#RiskAssessment
Type of Term:	Conformity
Label:	Risk assessment
Description:	please review
Definition:	Information subject. Risk assessment.

SafetyInstruction

Term	Description
URI:	http://iirds.tekom.de/iirds#SafetyInstruction
Type of Term:	Safety
Label:	Safety instruction

SalesCatalog

Term	Description
URI:	http://iirds.tekom.de/iirds#SalesCatalog
Type of Term:	DocumentType
Label:	Sales catalog
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains listings of available products of a producing company with consumers as the target group.

ScopeOfDelivery

Term	Description
URI:	http://iirds.tekom.de/iirds#ScopeOfDelivery
Type of Term:	Formality
Label:	Scope of delivery

Specification

Term	Description
URI:	http://iirds.tekom.de/iirds#Specification
Type of Term:	DocumentType
Label:	Specification
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains requirements and/or statements describing properties and qualities of a product to be built or manufactured.

Symbol

Term	Description
URI:	http://iirds.tekom.de/iirds#Symbol
Type of Term:	TechnicalOverview
Label:	Symbol

TableOfContents

Term	Description
URI:	http://iirds.tekom.de/iirds#TableOfContents
Type of Term:	DirectoryNodeType
Label:	Table of Contents
Synonym:	TOC
Definition:	Table of contents

TechnicalReport

Term	Description
URI:	http://iirds.tekom.de/iirds#TechnicalReport
Type of Term:	Conformity
Label:	Technical report
Description:	please review
Definition:	Information subject. Technical report.

TransportInstructions

Term	Description
URI:	http://iirds.tekom.de/iirds#TransportInstructions
Type of Term:	DocumentType
Label:	Transport instructions
Description:	Shall only be assigned to information units of type "Document"
Definition:	Type of document. Contains instructions for transporting the product or its components from one place to another.

WarningNotice

Term	Description
URI:	http://iirds.tekom.de/iirds#WarningNotice
Type of Term:	Safety
Label:	Warning notice

4.6.2 Machinery Domain

4.6.2.1 Class Definitions (Machinery)

ConsumableSupply

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#ConsumableSupply
Type of Term:	Class
Label:	Consumable supply
Sub Class Of:	iirdsMachineryDomainEntity
Sub Class Of:	Supply
Description:	Consumable supplies may be referenced in the description of working tasks in technical documentation.
Definition:	Type of supply: Goods or material that is consumed, meaning dissipated or spent, in the life cycle of a technical system. Examples are batteries, sanding discs, and magnets.

HardwareTool

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#HardwareTool
Type of Term:	Class
Label:	Hardware tool
Sub Class Of:	Supply
Description:	Hardware tools may be referenced in the description of working tasks in technical documentation.
Definition:	Type of supply: A device or implement, used to carry out a particular function or a working task

iirdsMachineryDomainEntity

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#iirdsMachineryDomainEntity
Type of Term:	Class
Label:	iirdsMachineryDomainEntity
Sub Class Of:	iirdsDomainEntitiy

Lubricant

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Lubricant
Type of Term:	Class
Label:	Lubricant
Sub Class Of:	iirdsMachineryDomainEntity
Sub Class Of:	Supply
Description:	Lubricants may be referenced in the description of working tasks in technical documentation.
Definition:	Type of supply: Lubricant, meaning a substance used for lubricating an engine or component, such as oil or grease.

OperatingSupply

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#OperatingSupply
Type of Term:	Class
Label:	Operating supply
Sub Class Of:	iirdsMachineryDomainEntity
Sub Class Of:	Supply
Description:	Operating supplies may be referenced in the description of working tasks in technical documentation.
Definition:	Type of supply: Physical items required for the running of a manufacturing production or service facility.

SetupTime

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#SetupTime
Type of Term:	Class
Label:	Planning time
Sub Class Of:	PlanningTime
Sub Class Of:	iirdsMachineryDomainEntity
Definition:	Type of planning time: Period of time required to prepare a technical system for it to be ready to function or accept a job.

SparePart

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#SparePart
Type of Term:	Class
Label:	Spare part
Sub Class Of:	iirdsMachineryDomainEntity
Sub Class Of:	Supply
Description:	Spare parts may be referenced in the description of working tasks in technical documentation.
Definition:	Type of supply: A spare part is an interchangeable part that is kept in an inventory and used for the repair or replacement of failed units of a technical system.

4.6.2.2 Object Definitions (Machinery)

Assembly

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Assembly
Type of Term:	PuttingToUse
Label:	Assembly
Type:	iirdsMachineryDomainEntity
Definition:	Life cycle phase of a product in which the product or its components are assembled for use.

CircuitDiagram

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#CircuitDiagram
Type of Term:	TechnicalOverview
Label:	Circuit diagram
Type:	iirdsMachineryDomainEntity

Cleaning

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Cleaning
Type of Term:	Use
Label:	Cleaning
Type:	iirdsMachineryDomainEntity
Definition:	Product life cycle phase of a technical system in which unwanted substances, such as dirt, are removed from the system.

CloseDown

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#CloseDown
Type of Term:	AfterUse
Label:	Close down
Type:	iirdsMachineryDomainEntity
Definition:	Life cycle phase of a product in which a plant, technical system, or facility is shut down permanently.

Commissioning

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Commissioning
Type of Term:	Use
Label:	Commissioning
Type:	iirdsMachineryDomainEntity
Definition:	Product life cycle phase containing activities related to transferring a product into active use and instructing personnel on the use. Activities include final inspection tests and handover of documentation, among others (DIN EN 82079-1)

Construction

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Construction
Type of Term:	DesignAndRealization
Label:	Construction
Type:	iirdsMachineryDomainEntity

Disassembly

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Disassembly
Type of Term:	AfterUse
Label:	Disassembly
Type:	iirdsMachineryDomainEntity

FlowDiagram

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#FlowDiagram
Type of Term:	TechnicalOverview
Label:	Flow diagram
Description:	Schaltplan: in der (Elektro)Technik gebräuchliche Art der Darstellung für eine elektrische Schaltung. Stromlaufplan wird wohl auch synonym verwendet.
Type:	iirdsMachineryDomainEntity

GenericConsumableSupply

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericConsumableSupply
Type of Term:	ConsumableSupply
Label:	Consumable supply
Description:	Consumable supplies may be referenced in the description of working tasks in technical documentation.
Type:	iirdsMachineryDomainEntity
Definition:	Type of supply: Goods or material that is consumed, meaning dissipated or spent, in the life cycle of a technical system. Examples are batteries, sanding discs, and magnets.

GenericHardwareTool

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericHardwareTool
Type of Term:	HardwareTool
Label:	Hardware tool
Description:	Hardware tools may be referenced in the description of working tasks in technical documentation.
Type:	iirdsMachineryDomainEntity
Definition:	Type of supply: A device or implement, used to carry out a particular function or a working task

GenericLubricant

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericLubricant
Type of Term:	Lubricant
Label:	Lubricant
Description:	Lubricants may be referenced in the description of working tasks in technical documentation.
Type:	iirdsMachineryDomainEntity
Definition:	A lubricant, meaning a substance used for lubricating an engine or component, such as oil or grease.

GenericOperatingSupply

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericOperatingSupply
Type of Term:	OperatingSupply
Label:	Operating supply
Description:	Operating supplies may be referenced in the description of working tasks in technical documentation.
Type:	iirdsMachineryDomainEntity
Definition:	A physical item required for the running of a manufacturing production or service facility.

GenericSetupTime

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericSetupTime
Type of Term:	SetupTime
Label:	Set-up duration
Type:	iirdsMachineryDomainEntity

GenericSparePart

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#GenericSparePart
Type of Term:	SparePart
Label:	Spare part
Description:	Spare parts may be referenced in the description of working tasks in technical documentation.
Type:	iirdsMachineryDomainEntity
Definition:	A spare part is an interchangeable part that is kept in an inventory and used for the repair or replacement of failed units of a technical system.

InstallationError

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#InstallationError
Type of Term:	Safety
Label:	Installation error
Type:	iirdsMachineryDomainEntity

Layout

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Layout
Type of Term:	TechnicalOverview
Label:	Layout
Type:	iirdsMachineryDomainEntity

ListOfLubricants

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#ListOfLubricants
Type of Term:	Collection
Label:	List of lubricants
Description:	please review
Type:	iirdsMachineryDomainEntity
Definition:	Information subject. Collection of lubricants, usually gathered from different parts of an information unit.

ListOfOperatingSupplies

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#ListOfOperatingSupplies
Type of Term:	Collection
Label:	List of operating supplies
Description:	please review
Type:	iirdsMachineryDomainEntity
Definition:	Collection of operating supplies, usually gathered from different parts of an information unit.

ListOfSpareParts

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#ListOfSpareParts
Type of Term:	Collection
Label:	List of spare parts
Description:	please review
Type:	iirdsMachineryDomainEntity
Definition:	Information subject. Collection of spare parts.

ListOfTools

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#ListOfTools
Type of Term:	Collection
Label:	List of tools
Description:	please review
Type:	iirdsMachineryDomainEntity
Definition:	Information subject. Collection of tools.

LubricationPlan

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#LubricationPlan
Type of Term:	Collection
Label:	Lubrication plan
Description:	Please review
Type:	iirdsMachineryDomainEntity
Definition:	Information subject. Lubrication plan.

MaintenancePlan

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#MaintenancePlan
Type of Term:	Collection
Label:	Maintenance plan
Type:	iirdsMachineryDomainEntity
Definition:	Maintenance plan

Modification

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Modification
Type of Term:	Use
Label:	Modification
Type:	iirdsMachineryDomainEntity

PartsList

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#PartsList
Type of Term:	Collection
Label:	List of parts
Definition:	Information subject. Collection of parts.

Reuse

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Reuse
Type of Term:	AfterUse
Label:	Recycling
Description:	Means re-use of materials, not of information --> recycling instead of reuse
Type:	iirdsMachineryDomainEntity

SafetyEquipment

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#SafetyEquipment
Type of Term:	Safety
Label:	Safety equipment
Type:	iirdsMachineryDomainEntity

SafetyMeasure

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#SafetyMeasure
Type of Term:	Safety
Label:	Safety measure
Type:	iirdsMachineryDomainEntity

Storage

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Storage
Type of Term:	AfterUse
Label:	Storage
Type:	iirdsMachineryDomainEntity
Definition:	Life cycle phase of a product that describes the process of keeping physical products available or in an adequate environment in order to tide over the time between arrival and use.

Transport

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/machinery#Transport
Type of Term:	PuttingToUse
Label:	Transport
Type:	iirdsMachineryDomainEntity
Definition:	Life cycle phase of a product containing activities for transporting a technical system or its components from one location to the other.

4.6.3 Software Domain

4.6.3.1 Class Definitions (Software)

iirdsSoftwareDomainEntity

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#iirdsSoftwareDomainEntity
Type of Term:	Class
Label:	iirdsSoftwareDomainEntity
Sub Class Of:	iirdsDomainEntitiy
Definition:	Entity of the software domain

4.6.3.2 Object Definitions (Software)

Administration

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Administration
Type of Term:	Use
Label:	Administration
Type:	iirdsSoftwareDomainEntity
Definition:	Life cycle phase of a product containing activities related to managing, updating, and configuring software products and IT systems.

Architecture

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Architecture
Type of Term:	TechnicalOverview
Label:	Architecture
Type:	iirdsSoftwareDomainEntity
Definition:	Conceptional structure of a product or component

Customization

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Customization
Type of Term:	Use
Label:	Customization
Type:	iirdsSoftwareDomainEntity
Definition:	Life cycle phase of a product containing activities relating to reworking a standard product (device or even software) to the special requirements of individual customers.

Deinstallation

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Deinstallation
Type of Term:	AfterUse
Label:	Deinstallation
Type:	iirdsSoftwareDomainEntity

Deployment

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Deployment
Type of Term:	PuttingToUse
Label:	Deployment
Type:	iirdsSoftwareDomainEntity
Definition:	Life cycle phase of a product describing activities related to making a software system available for use.

Integration

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Integration
Type of Term:	PuttingToUse
Label:	Integration
Type:	iirdsSoftwareDomainEntity
Definition:	Life cycle phase of a product containing procedures for integrating a software or IT system with other software products or systems.

Interface

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Interface
Type of Term:	TechnicalOverview
Label:	Interface
Type:	iirdsSoftwareDomainEntity

SystemRequirement

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#SystemRequirement
Type of Term:	TechnicalData
Label:	System requirement
Type:	iirdsSoftwareDomainEntity

Update

Term	Description
URI:	http://iirds.tekom.de/iirds/domain/software#Update
Type of Term:	Use
Label:	Update
Type:	iirdsSoftwareDomainEntity

Element	Attribute
area	alt
area	coords
area	href
area	shape
audio, img, video	autoplay (not img)
audio, img, video	alt (only img)
audio, img, video	controls (not img)
audio, img, video	height (not audio)
audio, img, video	loop (not img)
audio, img, video	mediagroup (not img)
audio, img, video	muted(not img)
audio, img, video	poster (only video)
audio, img, video	preload (not img)
audio, img, video	src (img), src (audio,video)
audio, img, video	usemap (only img)
audio, img, video	width (not audio)
map	name
source	src
track	default
track	kind
track	label
track	src
track	srclang

Element	Attribute
col	span
colgroup	span
table	border
td,th	colspan
td,th	headers
td,th	rowspan
th	scope
th	abbr

`data-role` Value(s)	Element	Usage
`caution`, `warning`, `danger`, `notice`	`div`	Tags a div element to contain a hazard statement with the severity identified by the integer value.
`signalword-panel`	`div`	Tags a signal word panel of a hazard statement.
`safety-alert-symbol`	`img`	Tags a safety alert symbol of a hazard statement. The `img` element shall be a child of the signal word panel. Only one safety alert symbol shall be provided.
`signalword`	`p`	Tags the signal word in the signal word panel of a hazard statement.
`symbol-panel`	`div`	Tags a panel that contains additional hazard symbols.
`message-panel`	`img`	Tags the message panel within a hazard statement.

Abstract

Status of This Document

1. Introduction

1.1 About iiRDS

1.1.1 Dynamic documentation requires topics and metadata

1.1.2 Standardized package format

1.1.3 No authoring standard

1.1.4 Advantages

1.2 Who makes iiRDS?

1.2.1 Contributors

1.2.2 External Contributors

1.3 Target group

2. iiRDS Package

2.1 Metadata

2.2 Content

3. iiRDS Container Format

3.1 iiRDS Container

3.1.1 Naming files and directories

3.1.2 Metadata location

3.1.3 Content location

3.2 iiRDS Zip Archive

3.2.1 Mimetype of iiRDS

3.2.2 Content encoding

4. The iiRDS Metadata Model in the RDF Schema

4.1 Glossary

4.2 Scope of the RDF Schema

4.3 Main Classes of the iiRDS Metadata

4.3.1 InformationUnits and Information Types

4.3.1.1 Subclasses of InformationUnit

4.3.1.2 Types of Documents and Topics

4.3.1.3 InformationUnit Identifier

4.3.1.4 Content References of Information Units

4.3.1.4.1 Reference to File

4.3.1.4.2 Reference by Selector

4.3.1.4.2.1 Reference by FragmentSelector

4.3.1.4.2.2 Reference by RangeSelector

4.3.1.4.3 Multiple File References

4.3.1.5 Information Subjects

4.3.1.6 Relations of InformationUnits

4.3.1.7 Media Files in iiRDS

4.4 Documentation Metadata

4.4.1 Functional Metadata

4.4.2 Product Metadata

4.5 Products and Components in iiRDS

4.5.1 Component Trees in the Package

4.5.2 External Product Ontology

4.5.3 Product Variants

4.5.4 Navigation

4.5.4.1 Directory nodes

4.5.4.2 Hierachical navigation

4.5.5 iiRDS Domains and Proprietary Extensions

4.5.5.1 iiRDS Domain Extensions

4.5.5.1.1 Combination of iiRDS Core and Domain Vocabulary

4.5.5.2 Proprietary iiRDS Extensions

4.5.5.2.1 Adding a Proprietary Instance

4.5.5.2.2 Adding a Proprietary Class

4.5.5.2.3 Adding a Proprietary Property

4.6 iiRDS RDF Schema Reference

4.6.1 Core

4.6.1.1 Class Definitions

4.6.1.2 Property Definitions

4.6.1.3 Relations

4.6.1.4 Object Definitions

4.6.2 Machinery Domain

4.6.2.1 Class Definitions (Machinery)

4.6.2.2 Object Definitions (Machinery)

4.6.3 Software Domain

4.6.3.1 Class Definitions (Software)

4.6.3.2 Object Definitions (Software)

5. Content formats in iiRDS

5.1 Content in iiRDS

5.2 Unrestricted iiRDS vs. iiRDS/A

5.3 Self-contained iiRDS/A-packages

6. iiRDS/A Media Formats

6.1 Text formats

6.2 Graphics formats

6.2.1 Raster formats

6.2.2 Vector formats

6.3 Video formats

6.4 Audio formats