# Towards Cognitive Recommender Systems
## 3 A General Framework for Cognitive Recommender Systems
### Cognition-Driven: Personality2 Vec  
One of the main shortcomings of existing RSs is that they are not able to identify similar users based on their cognitive thinking and activities. For example, in retail or finance sector, if a RS would be able to find similarity between a new user and an existing user, then there would be opportunities to predict the user needs from product sales and upgrade point of views. Examples include identifying similar--students in education domain, patients in health domain, or similar customers in a finance sector. In this context, it would be important to understand the various dimensions for the student, patient, or the customer. Let us focus on customers' dimensions in a banking scenario. In this scenario, the similarity between two customers can be discovered from various dimensions such as demography, health, social activities, and/or engagements, as illustrated in Figure 6.  
Figure 5: Leveraging crowdsourcing to deal with biases and the cold-start problem. To enable identifying similar customers, we leverage our previous works, Personality2 Vec [17] and Graph-based OLAP analytics [103, 104] to automatically identify and match similar users (e.g., based on various dimensions illustrated in Figure 6). We introduce a graph-based data model. The nodes in the graph represent customers (and their domain-specific dimensions illustrated in Figure 6) as well as the products. We use mathematical embedding from a space with a dimension per feature to a continuous vector space which can be mapped to classes of cognitive activities in a specific domains such as retail, finance, health, and education. For example, in the finance industry scenario, the classes would be banks (e.g., Central, Retail, Commercial, Shadow, Investment, and Cooperative organizations), customers (e.g., Individuals, Partnership Firms, Limited Liability Companies, or Trusts), services (e.g., Loans, Overdraft, and Consultancy), products (e.g., Current/Savings/Credit accounts, Debit/Credit cards, Checks), and/or insights (fraud detection, money laundering). The edges in the graph will be relationships among the nodes as well as the above-mentioned classes. Following we present some examples of such relationships:  
Figure 6: Recommender Systems: users’ dimensions in a banking scenario. * \(customer[id]\xrightarrow{(\textit{applied-for [timesamp:T1]})}loan[type:car]\): which specifies that a customer applied for a car loan on a specific date T1 (YY/MM/DD). * \(customer[id]\xrightarrow{(\textit{Walth-assets [timesamp:T1]})}healthy\): which specifies that at timestamp T1 the customers wealth and assets analysis shows a healthy sign. This can be done through an automatic trigger for Wealth-assets analysis (see the demography category in Figure 6) when the customer applies for a loan. * \(customer[id]\xrightarrow{(\textit{Health-Insumac [timesamp:T1]})}valid\): which specifies that at timestamp T1 the customer has a valid health insurance. This can be done through an automatic trigger for health analysis (see the category health in Figure 6) when the customer applies for a loan. * \(customer[id]\xrightarrow{(\textit{Credit-Check [timesamp:T1]})}valid\): which specifies that at timestamp T1 the customer has a valid credit card with no background issue (e.g., late payments, fraudulent card applications, or skimming). This can be done through an automatic trigger for a credit check process (see the ontology in Figure 6) when the customer applies for a loan. * \(customer[id]\xrightarrow{(\textit{Transactions-Check [timesamp:T1]})}valid\): which specifies that at timestamp T1 the customers' transactions involved no risks or frauds such as suspicious transactions to blacklisted partners/countries. This can be done through an automatic trigger for a transaction check process (see the ontology in Figure 6) when the customer applies for a loan.