Content Modeling

A content model consists of definitions which describe your project's content types, properties, graph associations, and the aspect-oriented features that Cloud CMS uses to ensure data consistency, integrity and validity when content is created, updated or deleted.

In Cloud CMS, all content modeling is done using JSON and more specifically, JSON Schema. JSON Schema provides an elegant and well-adopted model for describing the types for content objects, properties and other nested elements that make up your data.

Content models are powerful but you can use Cloud CMS without delving into them. Cloud CMS comes pre-loaded with a fully-built content model for most of the things you'd like to do. By default, Cloud CMS will allow a flexible schema so that you can create an JSON documents you like and things will simply work.

Dynamic Dictionary

For every branch you create within Cloud CMS, the product will maintain a compiled, runtime dynamic dictionary of all of your definitions. The compilation step occurs whenever you change one or more definitions. Compilation runs within the transaction and can fail if one or more of your definitions doesn't adhere to the rules. In this case, the dictionary safely falls back to the last known good state (in accordance with being transactional).

The Dictionary contains Definitions. Definitions come in several flavors, the main ones being:

A Definition is very similar to the definition of a word in the dictionary. The definition has a name (the word) and what it means (a description). In this case, the description is a JSON Schema-derived object which describes the valid properties, constraints and rules around your data. And the name is a QName.

A QName is a qualified-name. Simply put, it's a unique name that no other definitions in your branch are allowed to have. A QName consists of a namespace and a name and is expressed like this namespace:name.

You can use any namespace you like. And two different namespaces can share the same name. For example, you might define an article as a homepage:article. You could then define a second article type with a different namespace, such as landingpage:article.

The Content Graph

At the heart of Cloud CMS is a content graph consists of Nodes and Associations.

[object Object]

A Node is what you typically think of as a piece of content. A Node has JSON properties and zero or more binary attachments. Nodes can be anything you'd like. For example, they can be Articles that you display on your web site.

An Association is a relationship between two Nodes. An Association is a JSON document as well and you can use them to store any data you'd like, though it's typically data about the quality or characteristics of the relationship. Associations connect Nodes in the graph and maintain knowledge about the direction of the association (outgoing, incoming or mutual) and it's containment behavior (owned, linked, or child).

Whenever you put content into Cloud CMS, you're automatically populating the graph. For example, you might put a document into a folder within the user interface. Under the hood, this relationship looks like this:

- Folder (n:node) -> Has Child Association (a:child) -> Document (n:node)

The association maintains pointers back to the Folder (it's source) and the Document (it's target). The two nodes are both of type n:node and the association is of type a:child. These are the QNames for the Type Definition and Association Definition, respectively, that back each of these objects.

Further Reading