October 2016
By Wolfgang Ziegler

Image: © Oleg Kozhan/123rf.com

Prof. Dr. Wolfgang Ziegler is a physicist and has been teaching in the course of Communication and Media Management at the University of Applied Sciences in Karlsruhe, Germany since 2003. He is also leading the Institute for Information and Content Management (I4ICM) of the Steinbeis Transferzentren GmbH at the university.


wolfgang.ziegler[at]i4icm.de
www.i4icm.de

Content management systems tested: Introducing the PI-Fan

How can we measure the functionality of a content management system? The best solution is a neutral standard that can be integrated in any system and that can explain how information is handled. One model that is suitable as a reference is the "PI-Fan".

Modern content management systems (CMS) have a number of standard functions that support system-based documentation processes. But what exactly differentiates these systems technically and methodically? This question has become easier to answer with the help of PI-Fan, a collection of content modules that can be implemented in any system and used as a free demonstration and reference model for the respective CMS functions. The modularization and variant management become clear in theory and practice with the help of the underlying PI classification.

The tekom study on special CMS, which first appeared in 2005 and is currently available in its third edition, forms the organizational basis for many selection processes for content management systems in the German speaking region. This study contains market relevant data regarding the prevalence of the systems and their implementation. Moreover, it also includes a ten-step process model for introducing a system.

Model delivers text and images

The reference model described here delivers a set of modular textual and graphic contents, using a standardized demonstration of basic and special functions with a universal example. A similar process also exists for the S1000D-integrated content management systems.

The documentation sector specializing in military and aviation is subject to comprehensive European specifications in the form of a standardized XML information model, an elaborate metadata model and detailed rules for contents and processes. It specifies the "bike" as a standard example for clarifying the function of the systems. The model explains how a "bike documentation" is created, managed and published in the respective systems by collecting modular information about a fictitious bicycle.

A reference model has been missing so far

As compared to the regimented aviation sector, there are no comparable comprehensive or special specifications in "general" content management. A majority uses XML as the data format, though not exclusively. There are various (XML-) information models that are specific to the system for the most part, but which can also correspond to public or standardized structures. Although content-related standardization methods such as function design according to Robert Schäflein-Armbruster and Jürgen Muthig are used frequently, they are not regulated in general or for the sector. Similar is the case with methods of modularization.

Modules are classified

In recent years, the method of "PI classification" has proven its worth and grown steadily as a solution independent of systems, especially for modularization. It is a method for providing metadata for modular information, also known as topics or topic-based information. Moreover, it provides clear and unambiguous specifications for the module contents. The method has been presented in literature since 2010 [6, 1. edition], but has been in public use since the presentation of the XML information model "PI-Mod" in 2009. The PI classification is used in PI-Mod, but is independent of it. Nevertheless, it is sometimes mistaken for the information model or mixed with it. While special services have been protected under the name "PI class" since 2015, the method itself can be applied and used freely.

Intrinsic and extrinsic classes

To explain the PI classification in brief: The name "PI" is derived from the dual perspective of modular content or the documents to be created. "P" stands for product and "I" for information. Each module is assigned a unique P and I classification.

In technical jargon we speak of "intrinsic classification", since it is, so to say, an internal feature of the module. Every modular content must therefore refer to exactly one of the product components ("Engine", "Heating", "Complete device", …) and may only contain ONE of the information classes ("Maintenance", "Repair", "Function description") defined earlier by the organization. The information classes often include the stages of the product life cycle in substantial parts, but can be defined more comprehensively depending on the information concept of an organization.

In combination, the intrinsic classifications precisely characterize the type and scope of information in the module. They are like coordinates in the information space of an organization. [6, P. 326]. This also fulfills the usual demand for insularity of modular information. The actual or potential possibilities for using the modules for end products are assigned to the variants of the respective products and the different documents types to be generated. This is performed through "extrinsic" metadata. The metadata is important later, e.g. for automation and variant management.

Complexity influences metadata

The metadata regarding the lifecycle of the content, e.g. versioning, and the language dimensions of contents, is not dealt with in depth here. Other parameters of variants will also be handled later, but are part of the PI classification. They find extensive application in general machine and plant engineering, automobile engineering, power and medical technology, as well as in software documentation of products with a component-based structure and modular software functions. The latter also specifies the metadata values of the intrinsic P classification.

For all products in general, metadata values usually show a tree-shaped structure due to their complexity and size. Since every module and topic may contain exactly one intrinsic P and I value only, we speak of a taxonomy of this metadata. It is again reduced to simple list values for simple products.

Extrinsic metadata can also be organized as a tree. To enable the multiple use of content, it is recommended to use hierarchical metadata with the possibility of selecting various values multiple times. This brief introduction to the PI classification method will now be used to explain the idea of the reference model.

Collection of modules

The PI Fan is a collection of modules and graphics freely available on pi-fan.de and with credit to the source. A total of 18 fictitious fans are described in the current version. About 30 modules are given in this version with reuse and mechanisms of variant management.

Classes for the modules

The classifications to be used in a system are described in separate tables: All intrinsic (Fig. 1) and extrinsic values (Fig. 2) are present in the table for actual PI classification, listed in different depths.

The fan types are organized in different series and models. Parameters such as design, regulation, heating and interface display are "concealed" or integrated in the related type denotations. Special forms of variant management can then be considered later. The four possible and real document types to be created per device can also be linked to a target group parameter accordingly.

Figure 1: Extract from the three-level intrinsic classification of the fan components (product classes) and information classes. Values in red have not yet been filled in the taxonomies in version 1.1.

Source: www.pi-fan.de/Wolfgang Ziegler


Figure 2: Extract from the extrinsic classifications: Series, Models and fictitious device types as well as document types.

Source: www.pi-fan.de/Wolfgang Ziegler

 

Module is assigned classifications

Now, how are the modules assigned to the classifications and how do the 4 (document types) x 18 (fan types) = 72 documents emerge from it? A planning matrix in Figure 3 answers the first part of the question. The matrix assigns a combination of (intrinsic) PI classifications to each module. Each module gets a unique number in the PI Fan example.

This process helps while planning the necessary modular content in practice, and thus also enables effort estimation for the content or even document creation. The same is also common in S1000D projects for example, and it is becoming evident that future functionalities of project management within or outside the known CMS will be based on similar mechanisms.

Figure 3: Intrinsic planning matrix. Assignment of module numbers to intrinsic product classifications and information classes. Red rows/columns do not have modules yet, white rows already have Module/Topics scheduled and assigned in version 1.1 of the PI-Fans.

Source: www.pi-fan.de/Wolfgang Ziegler

 

Combination of modules and variants

One more specification is now required for the documents, related to how the modules are to be merged. In PI-Fan, this is performed independent of the system in a document matrix (Fig. 4). Different models or module variants are combined for this purpose depending on the fan type. Different modules that are in one row have the same classification intrinsically and are thus respective variants of each other. Here, it is possible that these are completely separate models or that they are related according to the methods of the submodular variant management.

Figure 4: Overview of the product or document variants and the modules used in them. Module numbers with alphabets denote the module variants existing for an intrinsic classification.

Source: www.pi-fan.de/Wolfgang Ziegler


Figure 5 illustrates two cases of "submodule variants". They contain graphics or even textual parts belonging to different product variants. The respective variant identification is highlighted through color and in the text through the associated extrinsic fan type. As already mentioned, a feature based distinction can be performed alternatively or in parallel, e.g. with/without heating function. The PI Fan module package also contains a module and a tabular list of respective specific technical data of the 18 fans. Such contents can then be mapped for instance, with the variable mechanisms present in the CMS. Provided the systems possess such mechanisms.

Figure 5: Module as a variant collection with colored denotation of the respective extrinsic product validity of individual images or even texts; the contents have been slightly cut.

Source: www.pi-fan.de/Wolfgang Ziegler


To complete the picture, it should also be possible to generate different document types from the existing modules. Figure 6 shows the associated module or document matrix. Even though emergence of complete service manuals as a subset of the operating manual occurs only to some extent in reality like in the PI Fan, the example goes to show the basic logical possibilities: Modules can be assigned a document type explicitly in advance, thereby enabling filter processes to filter out modules or module parts that do not apply to a document type respectively from the master or collective documents. Moreover, the intrinsic classifications assigned logically row-wise can be used to configure the appearance of the module in a document type, and control or automate it in the system.

Figure 6: Matrix for assigning modules to various document types. Corresponds to the extrinsic information classification of modules in a row.

Source: Wolfgang Ziegler