Exercise 3.6. Design a property graph schema for a causal graph for investing. Your design should take into account the following domain knowledge. In investing, headwind and tailwind are metaphors used to describe the factors that could cause a difference to the performance of a stock. A headwind is any specific company, market or economic factor that could causally hinder a company's growth, or reduce its profitability, in the near future. These could include things like increased competition, regulatory changes, unfavorable economic conditions, or any other causal factor that makes it more difficult for the company to succeed. If a stock is facing headwinds, it means it is encountering challenges that could potentially lower its value in the near future. On the other hand, a tailwind refers to any such factor that could causally boost the company's growth or increase its profitability. These could include things like favorable economic conditions, beneficial regulatory changes, or a successful new product launch. A stock with tailwinds is benefiting from positive conditions or events that are causally responsible for an increase in its value in the near future.
Headwinds and tailwinds should be unitary in nature, i.e., not decomposable into more specific assertions. For example, Company is facing increasing competition, and is having difficulty hiring critical talent should be decomposed into two distinct headwinds. The factors that do not causally affect company performance cannot be headwinds or tailwinds. Examples of factors that are not headwinds or tailwinds:
A headwind / tailwind should have four well-defined attributes:
Sample SolutionWe begin by identifying nodes, labels and properties. Obvious candidate nodes are Company and Causal Factor A Company node would have properties has_name and has_ticker_symbol. For now, we will restrict ourselves to publicly traded companies. A Causal Factor would have only one property: description. We next identify the relations in our schema. Relations in our schema our :HEADWIND and :TAILWIND. Each of these relationships would have the properties materiality, duration, externality and obviousness. We choose to associate the properties with the relation because these can change from quarter to quarter. Two additional useful properties of each of these relations are reported in quarter to indicate in which quarter this particular relationship was reported, and provenance to record the source from where the relationship was obtained. We use two relationship types rather than one relationship (e.g., :CAUSAL_IMPACT, and give it a direction proeprty with two values: headwind, and tailwind) for the following reasons. The terms headwind/tailwind constitute a fixed, mutually exclusive vocabulary in this domain (like LIKES/DISLIKES), and having it as the relationship type - rather than a property - lets us write direct, indexable queries such as MATCH (f:Factor)-[:HEADWIND]->(c:Company) without a filter clause. Even though not required in the specification, we can introduce a causes relationship between two causal factors to denote the causal relationship between them. This relationship can model multi-step causal chains rather than only direct effects on companies. It is meant to capture time-independnt causal influences. Similarly, we introduce a competes relationship between two companies to indicate that they are competitors. Even though additional properties of these relationship (for example, two companies may compete in one geographical but not in another), but for now, we begin with this simplest design.
|