Skip to content

Phantasm

Constantine edited this page Nov 16, 2016 · 20 revisions

This page describes the Phantasm data and behavior modeling system provided by the Ultrastructure platform.

Phantasm - Ultrastructure as a Platform

Phantasm is a simple, elegant way to model complex, multi faceted systems in Ultrastructure. The Phantasm model is based on a graph data and query model that provides an aspect oriented view of complex systems.

Phantasm solves a particular problem in the Ultrastructure ecosphere, namely how to present the underlying Ultrastructure model as a usable data model API. Phantasm is largely concerned with graph relationships and controlling their complexity, however a natural interpretation of the Phantasm model is isomorphic to mainstream object oriented models. The Phantasm data model combined with animating code (in any language) provides a quite compelling programming model. This model is simple and maps quite easily to how people intuitively model the systems they're interested in.

As such, Phantasm provides the primary data API interface model into the Ultrastructure Platform.

Phantasm Data Model

From the 10K level, Phantasm provides the ability to add aspect defined state to an existential ruleform instance - e.g. a Product, Agency, etc. row. This aspect defined state is represented in the workspace by the Facet declarations. In the workspace dsl each of the existential ruleform types can define facets. These facets provide the data and relationship constraints that correspond to a Type in object oriented languages.

Facets and Classifications

Ultrastructure provides a rich set of ruleforms that describe authorized relationships between other ruleforms. In the Ultrastructure model, we use NetworkRuleforms to define homogenous graphs within an existential type. We can also use Attribute ruleforms to attach AttributeValues to these existential types to store primitive values (String, Number, JSON, etc). However, now we have a tangled mess of slinkies and piles of primitive state that's a bit hard to wrap your head around even with moderate complexity.

To solve this, Ultrastructure provides a classification structure that operates much like a Java class or interface. In the simple form, we can use the "Is-A" relationship to simulate type definition. The {relationship, child} tuple defines the "type" of something. For example, if I have "Sly Stone" as an Agency, I can say "Sly Stone" "Is-A" "Customer". This 3 tuple defines the NetworkRuleform that represents this edge in the graph. We can take the classifier - i.e. the relationship - and the classification and create a Facet - in the example above {"Is-A", "Customer"}.

Classifications provide an intuitive "view" into a complex entity. Although a given product may in fact be a computer, it may also be classified as a depreciable asset. When viewed through the classification of a computer, the attributes may well be disjoint from the attributes viewed through the classification as a depreciable asset. Classifications are thus state facets of a larger whole.

Attributes and Primitive State

Ultrastructure distinguishes between pure primitive state, such as Strings, booleans, Numbers and Timestamps and relationships between existential entities. Primitive state is represented by Attributes and AttributeValues.

Using the Facet classification, we can authorize (or define) what attribute state belongs to this classification. So in the example of {"Is-A", "Customer"}, we could add attribute state to this facet such as "Customer Name", "Title of Courtesy", etc.

Relationships Between Entities

We can also use the Facet model to provide a way to authorize (or define) what relationships are allowed between entities, and what their cardinality should be. To continue with our example, {"Is-A", "Customer"} may define a relationship called "Contact" to another existential entity {"Is-A", "Employee"}. This allows us to create the equivalent of a typed object pointer in the sea of links that may or may not be there.

Making Sense Of Graphs

What the Phantasm model provides is a simple way of intrinsically classifying state and relationships. This is captured in the form of a classification of entities using the graph of entities itself. What this means is that the metadata for the system is almost entirely captured by the data representation itself. The act of classification - i.e. creating an edge from one entity to another through a relationship - creates Phantasms.

Phantasm APIs

The Ultrastructure platform provides two kinds of APIs for the Phantasm model:

  • Phantasm.Java
  • Phantasm.GraphQL

Phantasm.Java

Phantasm.Java is an annotation based framework for binding Java object into the Phantasm facet model. For each Phantasm facet, a Java interface may be generated that can by used at runtime to provide a fully functional Java API for interacting with Phantasms as if they were Java Objects. While these interfaces can be hand crafted, these are invariably generated from either the workspace dsl or the facet data itself. These interfaces can then be used by any JVM compatible language to interact with Phantasm model.

Phantasm.GraphQL

Phantasm.GraphQL provides a workspace oriented GraphQL API. The GraphQL types are dynamically generated (and cached, naturally) from the Phantasm facets defined in Ultrastructure Workspaces. Each workspace becomes a namespace that provides a much needed organizational spaaaaaace over the GraphQL types.

Phantasm.GraphQL provides a single endpoint into the Ultrastructure platform and presents both the metadata describing the system as well as single round trip graph queries that can gather all the information you need in one round trip.

The Phantasm.GraphQL API also provides a plugin model for Phantasms, providing the equivalent of methods, and constructors (after insert triggers, for example) that can be seamlessly managed by the same Phantasm.GraphQL endpoint.

Clone this wiki locally