# Normative Terminology & Typographic Conventions

To ensure absolute clarity across the Information System documentation and prevent confusion with generic IT and graph-theory concepts, the following normative conventions are strictly enforced.

## How to Refer to the Information System Model

When referring to this model in documentation, scientific papers, and technical specifications, use the term **dynamic, hierarchical graph data model**.

It must **never** be referred to as an *ontology*: while it shares similarities with ontologies in several aspects (e.g., a rich type taxonomy, single/multiple inheritance, and facet-based composition), it differs fundamentally in others (e.g., it does not rely on Description Logics, OWL/RDF formalisms, or automated deductive reasoners, operating instead through a strongly consistent, schema-typed, database-backed dynamic catalog).

## Typographic & Foundational Conventions

- **`HTTP resource`**: The generic REST endpoint target (e.g., a URL responding to GET/PUT/PATCH/DELETE). Bold backticks are used exclusively for this phrase to clearly separate it from the IS-Model **Resource**.
- **Contexts**: Capitalized word to denote the formal operational environment partition (Context).
- **Graph Element Types**: PascalCase and **Bold** (e.g., **Entity**, **Resource**, **Facet**, **Relation**, **IsRelatedTo**, **ConsistsOf**).
- **Graph Element Instances**: The term "instance" strictly and exclusively refers to concrete graph elements possessing a global ID (i.e., **Resource**, **Facet**, **IsRelatedTo**, and **ConsistsOf** instances). The format "**Type** instance" (or plural "**Type** instances") is *always* used instead of generic graph-theory terms like "vertex", "node", "directed arrow", or "edge". No shorthand terms or lowercase variations are allowed.
- **Field Types**: Types defining the data structure of a field (which do not possess an ID). Built-in primitive types are written in standard PascalCase (e.g., String, Integer), whereas custom complex schemas are additionally enclosed in bold backticks (e.g., **`Metadata`**, **`PropagationConstraint`**, or **`Property`**).
- **Field Values**: The concrete data populating a field. To refer to these values, we use the format "[Type] field value" (e.g., **`Metadata`** field value, String field value).
- **System Field Keys**: When referring to built-in system keys (like `id`, `metadata`, `creationTime`), we write them in camelCase, enclosed in simple backticks. *(Note: This camelCase convention applies to system fields; user-defined custom property keys are structurally allowed to contain underscores and hyphens as defined by the Property Naming Constraints).*
- **Embedded Property Value**: Values that adhere to a **`Property`** schema (like **`Event`** or custom complex structures) do not possess a global ID and are not addressable independently. They must be referred to as "embedded property values", and strictly **never** as "property instances", to avoid semantic collision with true Graph Element Instances.

## Manifestation vs Projection (Data vs Topology)

To avoid ambiguity when discussing how data is modeled and how instances appear across different Contexts, the documentation explicitly separates the concept of *Contextual Projection* from *Manifestation*:

- **Contextual Projection (or Contextual View):** Used to describe how a single, globally unique instance "appears" when read from a specific Context.
- **Manifestation:** Used strictly to describe how a primitive type field or a **`Property`** field takes shape (manifests) within an instance. The term *manifestation* must never be used to describe the graph instances themselves.

## Topological Verbs & Sentence Patterns (Entity vs Graph Edge Abstraction)

The foundational schemas enforce two strict top-level rules for relations, represented using the notation **Source Resource Type** -- **Relation Type** --> **Target Entity Type**:
- **Resource** -- **ConsistsOf** --> **Facet**
- **Resource** -- **IsRelatedTo** --> **Resource**

To distinguish between the semantic connection of two entities and the physical edge direction, the following verbs and sentence patterns are strictly applied to avoid grammatical and conceptual ambiguity:

### 1. Patterns for "attached" (Composition: **Resource** -- **ConsistsOf** --> **Facet**)
Used **strictly and exclusively** to describe **ConsistsOf** semantics. It indicates the compositional dependency between a **Resource** and a **Facet**. The physical edge (`ConsistsOf`) acts as the vehicle (`via`).

- **Facet Perspective (Passive):**
  > "A **Facet** instance is attached to a **Resource** instance [ *via a* **ConsistsOf** instance ]."
- **Resource Perspective (Ownership):**
  > "A **Resource** instance has an attached **Facet** instance [ *via a* **ConsistsOf** instance ]."
- **Vehicle Focus (The Edge):**
  > "The **Facet** instance is attached via a **ConsistsOf** instance."

### 2. Patterns for "linked" (Association: **Resource** -- **IsRelatedTo** --> **Resource**)
Used **strictly and exclusively** to describe **IsRelatedTo** semantics. It indicates an association between two **Resource** instances with independent lifecycles.

- **Directional Perspective:**
  > "A **Resource** instance is linked to another **Resource** instance [ *via an* **IsRelatedTo** instance ]."
- **Mutual/Neutral Perspective:**
  > "Two **Resource** instances are linked [ *via an* **IsRelatedTo** instance ]."
- **Vehicle Focus (The Edge):**
  > "The **Resource** instance is linked via an **IsRelatedTo** instance."

### 3. Patterns for "pointing to" (Topological Edge Direction)
Used abstractly and purely topologically **only when the subject of the sentence is the Relation instance itself** (whether a **ConsistsOf** or an **IsRelatedTo** instance), indicating its directionality from `source` to `target`. It is never used as a verb between two entities.

```eval_rst
- **Relation instance** :math:`\rightarrow` **Entity instance:**
  > "A **ConsistsOf** instance is pointing to a **Facet** instance."
  > "An **IsRelatedTo** instance is pointing to a **Resource** instance."
```

### Architectural Rationale

This specific terminology successfully differentiates two fundamental levels of abstraction:
- **Entity Level (Abstract/Semantic):** When discussing interactions between nodes, we use `attached to` and `linked to`. This is best suited for **Business Logic** (easy to read, semantically rich).
- **Edge Level (Physical/Topological):** When the subject of the sentence is explicitly the Relation (the physical graph edge in the DB), we use `pointing to` towards the target. This is best suited for **Query/Database Logic** (precise and unambiguous regarding edge traversal direction).
