This is the documentation for Hypar 1.0.
Hypar 2.0 documentation can be found at docs.hypar.io. Hypar 2.0 can be found at hypar.io.
logo
🚧 Note: This concept is still under construction, and is subject to change as we continue to refine it. This document will be updated to reflect any modifications.

What are Relationships?

$hyparRelationships are annotations used in Hypar schema to define relationships between two types, allowing the platform to better understand and visualize how these types are connected. This concept is still under development, and as such, may not be extensively documented. However, the following sections provide a general overview of how $hyparRelationships work and their purpose within the platform.

Basic Principles

The primary purpose of $hyparRelationships is to establish consistent relationships between two types in Hypar. For example, a relationship may indicate that one type is a child of another, or that one type adds more information to another. To define a relationship between two types, you need to add a property to one of the types involved. This is usually a string property that holds the ID of an instance of the other type, though it can also be an array of strings for multiple elements.
These relationships are purely annotations and do not affect the C# code. The primary use case for $hyparRelationships is to influence the UI and provide a more streamlined user experience. When a user selects an element with a relationship, the UI displays relevant settings for related elements, allowing users to see how elements are connected and interact with them accordingly.

Types of Relationships

Relationships come in reciprocal pairs. Only one of the two schemas needs to annotate a relationship β€” the other schema will be inferred to have the reciprocal relationship. For example, if a type Foo specifies an child-of relationship to type Bar, then type Bar automatically acts as though it has an parent-of relationship to type Foo.
  • extends: The object specifying the relationship can be thought of as "extending" the object it points to. For instance, a "Unit Layout" might extend a "Level" that has that layout.
  • extended-by: The reciprocal of Extends. This relationship type is usually not specified explicitly by a function author and can often be thought of as "Has A."
  • child-of: The object specifying the relationship is a β€œchild” of the object it points to. For example, a "Space Boundary" might be a child of a "Level Volume," and a "Level Volume" might be a child of a "Conceptual Mass."
  • parent-of: The reciprocal of ChildOf. This relationship type is usually not specified explicitly by a function author.
  • view-of: This element is a view specifically related to some other element, like a plan view for a level.
  • has-view: This element has a view specifically for it.