Since Momentum so heavily relates to schema.org which is build on graph model, we also used graph DataBase (ArangoDB) to ensure needed flexibility for advanced schema markups ( deep nesting ).
Collections
Collections in Momentum correspond with specific schema.org classes, so when a collection is to be created, the user selects class from up to date list of schema.org classes. (pending schema classes are omitted).
Template for items in the collection will have available all fields for specific schema.org class.
Each collection can be further configured, what fields (iteprops) collection items will have. Custom fields can be created too.
For cases when custom or non semantic collection is needed, flow is to create Thing schema.org class, and create custom fields that suit your need.
Items & Relations
Every collection can have items. Items being content are created from the CMS interface. There are a few ways where collection items may relate to each other. Items from different collections may also have relations between each other, and most website models revolve around relations.
In the example, a Person item is in relation with a Company item, and that relation is named WorksFor. When we render that model into html and some extra styling, it could look something like on the next diagram.
On the left is an example of a Company item rendered as a field of a Person item.
On the right we have a representation of collections that we have created for this model. Those collections are in all aspects not related to each other, except in the render that we have chosen to see.
!! Editing Direction (DIMS related)
Explain why it matters where something is edited, and how it relates to renders. Explain that it can’t be edited in both ways.
Inbound & Outbound Relations
There are two ways we can see this specific model.
Since Person schema.org class has worksFor itemprop (field) we can expect a relation to be displayed this way. This is an outbound relation.
Person > worksFor > Company
In this render Person item is information of greater importance. However there is a case where a Company item may be of greater importance, and then a relation would look something like this. This is an inbound relation.
Company < worksFor < Person
When this is a case there are two ways momentum resolves this kind of relation.
If Schema class used as primary has an inverted property example: employee, that would be used.
Company > Employee > Person
If a specific schema model doesn't have a specific inverted prop, no schema markup will be used for relation. This will result in separate models Company and Person.
Company
Person
Deep Nesting (context schema)
Deep nesting is a term for cases when we have something like this:
LocalBusiness
OfferCatalog
SubOfferCatalog
Offer
ItemOffered
Service
Offer
ItemOffered
Service
Offer
ItemOffered
Service
SubOfferCatalog
Offer
ItemOffered
Service
Offer
ItemOffered
Service
Offer
ItemOffered
ServiceThis is an example for a services catalog for a local business. The catalog has two sections, and there are three offers in each catalog section. Each offer refers to a specific item that is offered.
Regardless of being structured in a hierarchical model, items in created collections are saved in separated collections, example at the next image right.
Example on the left is a presentation of the same model as above.
Some Limits Of Current Engine
taxonomies explained, tags, categories, possible workarounds, more info ...