# <span style="color:purple"/>Brain Knowledge Repository 1.2
### <span style="color:purple"/>**You shall know an Entity by the company it keeps in the Knowledge Graph!**

## Scope
Brain Knowledge Repository 1.2 will offer inhertiance support as the key offering a long with amazing enahancments on top of 1.1

1. Inhertiance Support
1.1 Parent and Child Class Level Support
1.2 Taxonomy representation
2. Feature enhancement
2.1 Aggregation : MIN, MAX, STANDARD_DEVIATION, Mean, Median
2.2 GroupBy : Resultset optimization

### Inhertiance Support

GetChildrenResponse GetChildren(GetChildrenRequest) 
 
message BrainId { 
  string key   = 1; 
  oneof id_is_one_of { 
    uint32 u32 = 2; 
    uint64 u64 = 3; 
  } 
} 
 
message GetChildrenRequest { 
       BrainId brain_id = 1; 
       unit32 degree = 2;// incase if we want to control what level to go. Default is 1 degree hence immedidate childern 
} 
 
message GetChildrenResponse { 
      one_of { 
	       repeated BrainId brain_ids =1; 
           BrainTokenTree token_tree = 2; 
     } 
}

## Task for Product Manager

* Praveen to do the study of what StarDog supports
* Also list the kind of questions which can be solved using the inheritnace support
* Queries possible on MIN, MAX, STANDARD_DEVIATION

# <span style="color:purple"/>Brain Knowledge Repository 1.3
### <span style="color:purple"/>**You shall know an Entity by the company it keeps in the Knowledge Graph!**

### Detail plan for UKG setup for multiple clients
During the creation of a domain should automatically create a **"domain/thing"**.
Right now when we initialise a New database it automatically creates a root-node called “Thing”. The "Thing" node is universally the root node in the database so if we want to get the full ontology the "GetOntology" API by default uses "Thing" as its root but there is no way To get the full ontology, which includes entity-types from all domains. To get domain-specific ontology and data we can have a **"domain/thing"** which gets created during "CreateDomain" request and is the default parent to all future entities created in the domain with no specified-parent.

Now, there can be special entities who have relationships across domain. These are inferred as "common".

The entire schema already exists in a master-database and when we create a new one for a domain specific client, we identify all entities which are in anyway connected to the "domain/thing".

Now, doing that we can figure out all paths from these entities to "Thing".
retail/thing **--is_a-->** Thing
retail/customer **--is_a-->** retail/thing **--is_a-->** Thing
retail/customer **--lives_in-->** telecom/geo-location **--is_a-->** telecom/thing **--is_a-->** Thing


The above operation gives the list of all collections and metadata documents that have to be imported in the client database

#### Removing Common Domain

Right now their is a concept of **common domain** for entities which are accessed by multiple domains. From now on the common domain will not be explicitly and will be infered based on entity/predicates characteristics.

We will have concept of cross domain entities which would be treated as belonging to multiple domains or as "common" across these domains. "GetOntology" API with a "retail" or "agriculture" would both include fertilzer.

retail/fertilizer **--is_a-->** retail/thing
retail/fertilizer **--is_a-->** agriculture/thing

The are relationships/predicates with subject and object belonging to different domains will be treated as belonging to domain of both subject and object.The subject and object of this predicates would be infered as belonging to both this domains.

retail/product **--is_a-->** retail/thing **--is_a-->** Thing
agriculture/crop **--is_a-->** agriculture/thing **--is_a-->** Thing
agriculture/processed **--is_a-->** agriculture/thing **--is_a-->** Thing
agriculture/processed **--is_a-->** retail/thing **--is_a-->** Thing
retail/product **--is_a-->** agriculture/thing **--is_a-->** Thing
agriculture/crop **--is_a-->** retail/thing **--is_a-->** Thing