| Information | Content Model Introduction |
|---|---|
| Support Status | Full Support |
| Architecture Information | Platform Architecture |
| Description |
One of the main differences between a network drive and a Content Management System (CMS) is that the latter provides extra classification features. If you look at a CMS behind the scenes, you can see that everything in the repository is typically a node (a node is also sometimes referred to as an object). Properties are then set on the nodes so they become folders, files, categories, rules, forums, web pages, e-mails, people, groups, and so on. Classifying nodes makes performing operations on them more precise, so it is easier to search for them, so they can be displayed in the user interface correctly, and node-specific operations can be carried out. The properties that can be used to classify nodes (content), cannot be selected at random, as then the system would not know what each one of these properties represents. Because of this a content management system usually comes preconfigured with properties that can be used to classify content in the repository. These properties are usually organized into two groups called Types and Aspects. The main difference between types and aspects is that a node can only have one type applied but it can have multiple aspects applied. Nodes are not isolated within the repository. They are related to one another in different ways. How the nodes are related to each other is defined using Associations. A typical association that comes out-of-the-box with SkyVault Content Services is the one between a folder node and its child nodes, this type of association is a child-association. So when you start using SkyVault Content Services you can immediately organize folders and files into a hierarchy, like with a file system. The Types, Aspects, Properties, and Associations are in turn organized into models that we call Content Models. SkyVault Content Services comes with a number of Content Models out of the box for different things like general folder and file content, workflow-related content, records content, web content, and so on. It is also useful to be able to create content models related to specific domains such as Finance or Marketing. As the type of content that may be stored in the repository can vary, generic standard content models are provided that provide a basis on which to build custom content models for domain-specific purposes. New types and aspects are defined forming new custom content models. But how do you know how to specify a type and a property with, for example, a data type integer? SkyVault Content Services also comes with a Meta Model. The Meta model defines what syntax you can use when defining your content models. It will, for example, define the syntax for how a type or an integer property should be defined. The following diagram gives a simplified overview of the relationship between meta model, content models, and custom content models:
In the image, you can see two nodes in the repository: one folder node and one ACME Contract document node. The Contract type extends the ACME Generic Document type, or base type if you like, which in turn extends the generic Content type. The Contract document node also has versioning turned on by having the Versionable aspect applied. Both the custom content model and the SkyVault Content Services content model is defined by the Data Dictionary Schema, which is the same as the Meta Model. Content models, types, aspects, and properties are similar to object-oriented concepts in programming. If you are familiar with object-oriented modelling, then the concepts of content modelling should feel familiar. The meta model contains the constructs or syntax that can be used to define content models, which are defined in XML. Important: It is possible to create custom content models from the SkyVault Share UI without the
need to use XML. These models can then be exported as XML and included in a
build project. See the Content modeling with Model Manager
for further information.
For detailed instructions on how to implement content models, see the define and deploy section. When you have defined and deployed a content model you would want to be able to work with it from the Share UI, see the configure UI section for more information around this. |
| Deployment - App Server |
|
|
|
| More Information |
|
| Sample Code | |
| Tutorials |
|
| Developer Blogs |
|
You are here
Content Model
Defining a custom content model for the repository is a fundamental task in almost every
content management project. It will allow you to build a robust system with content that
can be classified, searched, structured, and processed in many different ways.
© 2017 TBS-LLC. All Rights Reserved. Follow @twitter