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 af: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 thef: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 ofgenre
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
<thead>
<tr>
<th>Property</th>
<th>Type</th>
<th>Default</th>
<th nowrap>Read-Only</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>properties</td>
<td>array (string)</td>
<td></td>
<td></td>
<td>
The names of the properties that are knowledge space properties.
</td>
</tr>
</tbody>