Knowledge Space

QName: f:knowledge-space

Used to indicate that a node should behave as a Knowledge Space. A Knowledge Space has zero or more knowledge properties. A knowledge property is a regular old property on your JSON object that is special in that its value may propagate to other nodes automatically.

A Knowledge Space is holds the "master value" for those knowledge properties. When those properties change, their new values are pushed to any other nodes that are sharing the knowledge from the Knowledge Space.

Nodes that receive one or more knowledge properties from a Knowledge Space are called Knowledge Recipients.

It looks a little like this:

Knowledge Space     ->  (Association With)      -> Knowledge Recipient
f:knowledge-space       f:knowledge-sharing        f:knowledge-recipient

Any kind of node can become a Knowledge Space by simply applying the f:knowledge-space feature. By doing so, the Cloud CMS user interface will provide some additional dashlets and things to let you know that you're looking at a Knowledge Space. It will also indicate JSON properties that are Knowledge Properties.

A Knowledge Space can indicate zero or more properties that are to be regarded as Knowledge Properties. To do so, you set the f:knowledge-space feature's properties array to include the dot-delimited names of the properties on your JSON that should propagate. These properties will propagate exactly as they are with no mapping conventions to recipients.

For example, support you're setting up a catalog of books. Each book is sorted by genre. Let's suppose we create a Genre folder and set it up something like this:

For example, support you have a node like this:

{
    "_type": "catalog:genre",
    "title": "Science Fiction",
    "genre": "scifi"
}

You make it a knowledge space by giving it the Knowledge Space feature:

{
    "_type": "catalog:genre",
    "title": "Science Fiction",
    "genre": "scifi",
    "_features": {
        "f:knowledge-space": {
            "enabled": true
        }
    }
}

And now we upgrade the genre property to a knowledge property:

{
    "_type": "catalog:genre",
    "title": "Science Fiction",
    "genre": "scifi",
    "_features": {
        "f:knowledge-space": {
            "enabled": true,
            "properties": [
                "genre"
            ]
        }
    }
}

That's it. Our "genre" folder is now a knowledge space that will propagate the value of the genre property down any associations that seek it. Which associations are those?

By default, the a:child association will propagate knowledge properties. But, in fact, it can be any directed association that points from this Knowledge Space to any other node. All you need to do is make sure that the association or the association type has the f:knowledge-sharing feature on it.

Suppose we now create a sub-folder for a book. Let's call it "Ender's Game". We create the folder and establish it as a child of our "Science Fiction" folder. Upon saving the folder, it might look like this:

{
    "_type": "catalog:book",
    "title": "Ender's Game",
    "genre": "scifi",
    "_features": {
        "f:knowledge-recipient": {
            "enabled": true,
            "properties": [
                "genre"
            ]
        }
    }
}

The genre property is copied down into our book. In addition, our book is marked automatically as a f:knowledge-recipient. Cloud CMS automatically handles property propagation as well as marking downstream nodes properly so that changes to knowledge space properties can be updated onto recipient nodes quickly.

If we created any further sub-folders within this book folder, they will also receive the genre property provided that those sub-folders are connected via an association that shares knowledge (i.e. has the f:knowledge-sharing feature, such as a:child).

Once we have our hierarchy set up, we can truly take advantage of it. Suppose you wanted to change the value of genre from scifi to sci-fi. All you have to do is edit your "Science Fiction" folder and make the change.

Cloud CMS automatically propagates property changes to recipient nodes for you. This happens out-of-transaction so that your applications won't get hung up waiting for undetermined number of additional nodes to update. Rather, Cloud CMS maintains a background queue of updates that it walks through and pushes changes as soon as it can.

The background updates are very quick but will lag your transactional committed data. Give it time to catch up.

Note - In the future, we may add transactional support for Knowledge Space properties. Let us know if this is something you'd like to have for your projects and we can prioritize our roadmap.

Configuration