Content Models 
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
Note
With the Knowledge Provider, you can model two-layer content models. In this case, an application using the Knowledge Provider does not need any logical documents, as only physical documents and components are used.
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.
Note
You can create your own content model using the Document Modeling Workbench (transaction DMWB). For information on the DMWB, see Document Modeling Workbench.