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. Graph-theory terms appear only where the text explains the formal topology or the physical graph mapping (see Topological Verbs & Sentence Patterns), never in an API contract.
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:

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.

Relation instance \(\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).