Page Comparison

...

Drafts Schema ( TBD: have to JSONify)

1. APIs  import/export for creating, modifying, deleting, listing parts or whole of one or more Views, and their management 
2. upload/download  for creating, modifying, deleting, listing parts or whole of one or more Views

Summary

1. Every referable entity in the Sunbird ecosystem is a Term in the Knowledge Graph (KG)
2. A Framework itself is described in the KG w.r.t what types of Terms can appear, what relationships are supported, and the compatible bindings between entities.
3. Any domain to be modeled such as a Vocabulary or Spine is simply a subgraph (a projection) of the KG. In other words, by applying a set of appropriate filters, we get the desired domain
4. Vocabulary has collection of all Terms appearing in any and all Frameworks and it  inherits the common world knowledge about them (such as synonyms, examples, translations etc..from WordNet)
5. Keywords is again a set of Terms in the KG for a Term in a Framework. So, Keywords is also a certain projection of the KG.
6. Every domain is governed by a set of rules and policies. A policy is a composite predicate. A composite predicted consists of one or more predicates joined by relational operators such as AND and OR and NOT. A predicate evaluates to Truth or False. A predicate takes a function of a result set (of a query on a Graph), and applies a comparator operator to a given policy value, which itself could be a result set. Any policy is a template consisting of the result set (of a graph projection), a comparator and reference value set (truth) that can also be a result set.
7. Any graph operation can be validated w.r.t the policies to be enforced in that domain
8. Policies lend themselves to test cases – thereby this design implicitly enforces TDD approach to building software
   1. export graph (actual upload csv schema might be different than this. upload is actually a UI component)
      1. Nodes tab
         1. <NodeName, additional fields> 
      2. Relations Tab
         1. <leftNode, rightNode, relationType, additional relationFields>
   2. import graph (same as above)
   3. edit graph (actual upload csv schema might be different than this. upload is actually a UI component)
      1. Add Nodes tab (most likely not needed)
         1. <NodeName, additional fields, PolicyName/ID> 
      2. Delete Nodes tab
         1. <NodeName, PolicyName/ID>
      3. Rename Nodes tab
         1. <OldNodeName, NewNodeName, PolicyName/ID>
      4. Split Nodes tab
         1. <OldNodeName, ListOfNewNodeName, PolicyName/ID>
      5. Merge Nodes tab
         1. <List of OldNodeNames, NewNode, PolicyName/ID>
      6. Add Links tab (most likely not needed)
         1. <leftNodeName, rightNode, linkType, PolicyName/ID> 
      7. Delete Links tab (most likely not needed)
         1. <leftNodeName, rightNode, linkType, PolicyName/ID>
9. APIs  for creating, modifying, deleting, listing parts or whole of one or more Views, and their management
   1. can parallel the import/export/edit syntax

Comments

1. For better performance, making Framework, Vocabulary, etc as first entities may be necessary. Handling sets via set membership could result in verbose queries and higher latency
2. Node and Relationship (properties) are listed out here
3. Policies can also have RBAC-based behavior.

Summary

1. Every referable entity in the Sunbird ecosystem is a Term in the Knowledge Graph (KG)
2. A Framework itself is described in the KG w.r.t what types of Terms can appear, what relationships are supported, and the compatible bindings between entities.
3. Any domain to be modeled such as a Vocabulary or Spine is simply a subgraph (a projection) of the KG. In other words, by applying a set of appropriate filters, we get the desired domain
4. Vocabulary has collection of all Terms appearing in any and all Frameworks and it  inherits the common world knowledge about them (such as synonyms, examples, translations etc..from WordNet)
5. Keywords is again a set of Terms in the KG for a Term in a Framework. So, Keywords is also a certain projection of the KG.
6. Every domain is governed by a set of rules and policies. A policy is a composite predicate. A composite predicted consists of one or more predicates joined by relational operators such as AND and OR and NOT. A predicate evaluates to Truth or False. A predicate takes a function of a result set (of a query on a Graph), and applies a comparator operator to a given policy value, which itself could be a result set. Any policy is a template consisting of the result set (of a graph projection), a comparator and reference value set (truth) that can also be a result set.
7. Any graph operation can be validated w.r.t the policies to be enforced in that domain
8. Policies lend themselves to test cases – thereby this design implicitly enforces TDD approach to building software
9. Upload and Download APIs should be treated as UI components. They should not dictate the import and export schema. Upload is an interface to import, and Download is an interface to Export. (So, Export and Import should be quite general enough). Export can be Download but not vice versa. For example, the current Upload API for ToC in Textbook creation implicitly assumes a PARENT_OF relationship, and support upto a depth of 5. This is not generalizable for arbitrary graphs. Instead, the export schema provided can always be reshaped to support a specific/ restricted API.
10. Since majority of the code (for basic operations, and validation) is outsourced to the underneath graph engined, the developer can focus on business logic and less on low-level Graph management operations. Less code, less bugs

...