Content Models

Use

Individual SAP applications create meta-data models for the various types of documents that they use that have relationships to each other. These models are called content models.

A content model describes on an abstract level the characteristics of the individual content entities in the Knowledge Provider. The documents in the content model are classified according to content type. Examples of content type are end-user documentation and scanned documents.

KPro Content Model

The Knowledge Provider content model is called a three-level content model, as it contains three levels for administration data:

  • Components administrate content

  • Physical documents administrate documents

  • Logical documents administrate collections of documents

A number of physical documents is assigned to a logical document. A physical document represents an individual document, while a logical document represents a collection of documents.

A document can consist of different files, that is, every physical document can have one or more components. Every component, for its part, is associated with one content entity.

KPro Content Model

Application-Specific Content Model

Applications can use the Knowledge Provider's document infrastructure to develop their own content models. At runtime, the Knowledge Provider accesses these application-specific content models and uses the meta-information they contain to execute the required services. This allows applications to define their own attributes or particular types of versioning, for example.

First, the application decides whether it will use a two-level or a three-level model. If it is likely that the documents will be subject to changes or a versioning procedure, the three-level model should be used. Possible changes could be changes to the content, language, and format. The two-level model is only suitable for documents to which no changes will be made and which will not be subject to a versioning procedure.

The three-level model is also recommended in situations where a number of context-dependent instances of a particular physical document coexist.

Once the application decides on the two-level or three-level model, the content model can itself be modeled in the following steps:

  • Define application-specific attributes

  • Define classes for physical documents

  • Define classes for logical documents

  • Define relationship classes

  • Define allowed relationships

The last step sets rules for creating relationships of particular classes between instances of logical and physical documents. During runtime, the Knowledge Provider accesses this information in the application-specific content model to find out whether a particular activity is allowed. You can use these rules to ensure that only allowed relationships between content versions of physical documents occur.