Skip to main content

PAMoLa technical overview

PAMoLa (Poly-Aligned Modelling Language) is a graph-based modelling substrate for representing model content, modelling vocabulary, rules, profiles, derived artefacts, and external projections in a common graph-based form. Its basic content items are called ordia (singular ordium). Ordia are arranged by a distinguished custodian relation into clades, while other references express typing, declared typing, participation, values, annotations, rules, artefacts, and projections.

The central idea is that the substrate is self-describing: the protected core vocabulary is itself represented as PAMoLa content. This means that the metamodel categories, their core properties, predefined datatypes and values, rule predicates, marker idioms, and well-formedness rules can be loaded by a kernel implementation and referred to by stable names. Profiles such as UML, MLT, OntoUML, RDF/RDFS/OWL, SQL, or notation styles can then be expressed as ordinary clades that refer to the same core.

This page gives a compact technical overview of the PAMoLa version 1.0.0. It includes the core metamodel view, the bootstrap fixed point of Ordium, the split between the classification-neutral core and the classification profiles that interpret it, an LML family-history example, and selected reference listings of the core vocabulary, the LML profile rules, and a PAMoLa family-history model.

Key terms​

  • ordium (plural ordia) — the basic content item of the substrate. Every model element, value, rule, annotation, and item of the core vocabulary is an ordium.
  • custodian / ward — an ordium's custodian is its parent under the distinguished containment relation; its wards are its children. Considered on their own, the custodian references form a tree-like locality and naming spine.
  • clade — an ordium together with the transitive closure of its wards. A clade is the unit over which names are qualified and over which storage, projection, access control, and execution are scoped.
  • clabject — an ordium that can be classified, classify other ordia, or both; entities and relationships are clabjects. Clabjects carry a hasPotency value and an optional hasDeclaredType reference, which the Core stores as uninterpreted slots (see Classification is supplied by profiles).
  • linguistic type — the fixed core category an ordium directly instantiates (hasLinguisticType), for example Entity, Relationship, or Attribute. It records what kind of PAMoLa item an ordium is.
  • declared type — the ontological classifier of a clabject (hasDeclaredType), recording how domain ordia classify one another. Declared typing is unbounded in depth and orthogonal to the fixed linguistic typing.
  • potency — a non-negative integer slot (hasPotency) carried by clabjects. The Core stores it uninterpreted; a classification profile gives it meaning. Under the LML profile it is read as an ordium's remaining depth of instantiation, so that a clabject of potency n classifies direct instances of potency n-1.
  • HUTN — Human-Usable Textual Notation: PAMoLa's family of textual renderings of clades.
  • FHAS — a HUTN profile: Full, Hierarchical, Abridged, with SUN references.
  • SUN — shortest-unique-name: a compact symbolic reference that resolves to an ordium within a given parse or rendering context.
  • LML — Level-agnostic Modelling Language: a UML-like notation extended with multi-level constructs such as potency and declared type, realised as the classification profile Ordium.Profile.LML.
  • MLT — Multi-Level Theory: a multi-level modelling theory, referenced here as a profile (for example for powertype relations).

Core metamodel view​

The following figure shows the protected core vocabulary as a metamodel. It identifies the major ordium categories and the property names associated with each category. The diagram is a view of the core clade, not a separate source of truth: the corresponding core vocabulary can also be represented as PAMoLa content and serialised in a PAMoLa HUTN (Human-Usable Textual Notation).

PAMoLa core metamodel view

At the root is Ordium. The main subclasses divide content into immanent, transcendent, and behavioural ordia. Immanent ordia include clabjects, entities, relationships, mediations, participations, intercalations, categorisations, moments, methods, and attributes. Transcendent ordia include datatypes, data values, literals, artefacts, and markers. Behavioural ordia include parameters, arguments, atoms, operations, invocations, and actions.

Several defaults shown in the diagram are virtual defaults. If a property has its defined default value, no edge to that default value needs to be stored. This keeps PAMoLa graphs sparse. For example, an absent data-valued property may mean that its default value applies, while an absent Ordium-valued property normally means that no target is asserted. Explicit undefined and unknown values are represented by predefined special values rather than by absence.

Bootstrap fixed point​

The root Ordium is a distinguished bootstrap fixed point. It is its own custodian, follows itself, and has itself as its linguistic type. (The follows property is a general-purpose sequencing pointer, independent of the custodian relation; it does not impose an ordering on the wards of an ordium.) This fixed point provides the root of the Ordium clade and of the protected core vocabulary.

Ordium bootstrap fixed point

The bootstrap does not remove the need for a minimal loader convention. Rather, it confines bootstrapping to the root fixed point. Once the root is established, the protected core clade can define the rest of the kernel vocabulary as ordinary PAMoLa content.

Classification is supplied by profiles​

The Core fixes only the linguistic classification of ordia: the fixed category each ordium instantiates through hasLinguisticType (Entity, Relationship, Attribute, and so on). It provides hasPotency and hasDeclaredType as clabject slots, but treats them as uninterpreted representation. The Core records that a clabject has a potency value, or is declared to be of some ontological type, without imposing any discipline that relates the two.

That discipline is supplied by a classification profile. The Level-agnostic Modelling Language profile, Ordium.Profile.LML, is the reference example: it reads hasPotency as remaining instantiation depth, requires each ontological classification step to decrease potency by one (the potency-step rule), admits a single ontological classifier per clabject, reads an absent potency as zero, and models an abstract classifier as a potency-0 clabject that has only indirect instances. Because these commitments live in the profile rather than the Core, other multi-level disciplines — MLT-style powertypes, or profiles that admit several ontological classification dimensions at once — can interpret the same neutral slots with their own rules without altering the protected Core. The LML profile rules are listed in Appendix A.

Family-history model example​

The immanent ordia of PAMoLa are designed to support multi-level, UML-style diagrams. The following figure shows a UML-style LML representation of the family-history model used in the OWL overlay documentation, with three ontological classification levels, a complete/disjoint gender partition, and parent/father/mother relationship patterns.

Familyhistory LML projection

Under the LML profile, each clabject carries a potency: the number of further levels over which it can have direct instances, shown as a superscript in the figure. A direct instance of a clabject is classified by that clabject itself, whereas an indirect instance is a direct instance of one of its subclasses. Thus PersonType (potency 2) has the direct instances MalePerson and FemalePerson (potency 1), which in turn have the direct individual instances GrantPlinth and MrPlinth (potency 0). An abstract clabject has a potency of 0 because it has no direct instances, even though it may have many indirect ones — Person is potency 0 here because every individual is a direct instance of MalePerson or FemalePerson, and therefore only an indirect instance of Person. Each hasDeclaredType reference records one such direct classification step, which is orthogonal to the fixed linguistic typing supplied by the core.

Appendix B gives an FHAS/HUTN representation of the model in the full, hierarchical, abridged variant, using shortest-unique-name references. Profile references such as Ordium.Profile.MLT.PowertypeRelation.partitions are written as canonical protected FQNs, while internal model references use SUNs.

Appendix A - Reference core clade​

The following compact tree gives a simple view of the reference core clade. It lists the main core vocabulary, including rule-head atoms, but omits the internal parameter/argument/body structure of rules so that the custodian structure remains readable.

OM Ordium
|-- EN Core
|  |-- OM hasName
|  |-- OM hasFQN
|  |-- OM hasPID
|  |-- OM hasNote
|  |-- OM hasCustodian
|  |-- OM follows
|  |-- OM hasLinguisticType
|  |-- EN rule
|  |  |-- AO new
|  |  |-- AO ghost
|  |  |-- AO wellFormed
|  |  |-- AO violation
|  |  `-- AO isA
|  |-- OM ImmanentOrdium
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM TranscendentOrdium
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM BehaviouralOrdium
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Clabject
|  |  |-- OM hasPotency
|  |  |-- OM hasDeclaredType
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Entity
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Relationship
|  |  |-- OM hasAssociationName
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Mediation
|  |  |-- OM hasRelatum
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Participation
|  |  |-- OM hasRoleName
|  |  |-- OM hasLowerBound
|  |  |-- OM hasUpperBound
|  |  |-- OM isOrdered
|  |  |-- OM isUnique
|  |  |-- OM isNavigableTo
|  |  `-- EN rule
|  |     |-- AO isA
|  |     |-- AO lowerBoundAtMostUpperBound
|  |     `-- AO participationMayInduceAccessPath
|  |-- OM Intercalation
|  |  |-- OM isGeneralisation
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Categorisation
|  |  |-- OM isComplete
|  |  |-- OM isDisjoint
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Moment
|  |  |-- OM hasDurability
|  |  |-- OM hasMutability
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Method
|  |  |-- OM isRealisedBy
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Attribute
|  |  |-- OM hasDataType
|  |  |-- OM hasValue
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Literal
|  |  |-- OM hasLexeme
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM DataValue
|  |  |-- OM ofDataType
|  |  `-- EN rule
|  |     |-- AO isA
|  |     |-- AO datatypeByCustodian
|  |     |-- AO datatypeByProperty
|  |     |-- AO dataValueDatatypeSourceBothViolation
|  |     `-- AO dataValueDatatypeSourceMissingViolation
|  |-- OM DataType
|  |  |-- EN rule
|  |  |  `-- AO isA
|  |  |-- DT String
|  |  |  `-- DV EmptyString
|  |  |     `-- LI emptyLexeme
|  |  |-- DT Character
|  |  |-- DT Boolean
|  |  |  |-- DV False
|  |  |  `-- DV True
|  |  |-- DT Integer
|  |  |  |-- DV Zero
|  |  |  `-- DV One
|  |  |-- DT NonNegativeInteger
|  |  |  |-- DV Zero
|  |  |  `-- DV One
|  |  |-- DT Decimal
|  |  |  |-- DV Zero
|  |  |  `-- DV One
|  |  |-- DT Float32
|  |  |  |-- DV Zero
|  |  |  `-- DV One
|  |  |-- DT Float64
|  |  |  |-- DV Zero
|  |  |  `-- DV One
|  |  |-- DT Byte
|  |  |  `-- DV Zero
|  |  |-- DT Binary
|  |  |  `-- DV EmptyBinary
|  |  |     `-- LI emptyBinaryLexeme
|  |  |-- DT Date
|  |  |-- DT Time
|  |  |-- DT DateTime
|  |  |-- DT Duration
|  |  |-- DT Multiplicity
|  |  |  |-- DV Zero
|  |  |  |-- DV One
|  |  |  `-- DV Unlimited
|  |  |     `-- LI starLexeme
|  |  |-- DT Name
|  |  |-- DT FQN
|  |  |-- DT PID
|  |  |-- DT IRI
|  |  |-- DT SpecialValue
|  |  |  |-- DV undefined
|  |  |  |  `-- LI sectionSignLexeme
|  |  |  `-- DV unknown
|  |  |     `-- LI questionMarkLexeme
|  |  `-- DT WardRole
|  |     `-- DV auxiliary
|  |-- OM Artifact
|  |  |-- OM hasLocator
|  |  |-- OM hasChecksum
|  |  |-- OM hasByteSize
|  |  |-- OM describes
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Marker
|  |  |-- OM hasTag
|  |  |-- OM refersTo
|  |  `-- EN rule
|  |     |-- AO isA
|  |     |-- AO marked
|  |     |-- AO markedRef
|  |     |-- AO auxiliaryWard
|  |     `-- AO auxiliaryFor
|  |-- OM Parameter
|  |  |-- OM isExistential
|  |  |-- OM hasType
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Argument
|  |  |-- OM bindsTo
|  |  |-- OM fills
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Atom
|  |  |-- OM isNegated
|  |  |-- OM isExplicit
|  |  |-- OM hasPredicate
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Operation
|  |  |-- OM hasReturnType
|  |  `-- EN rule
|  |     `-- AO isA
|  |-- OM Invocation
|  |  |-- OM calls
|  |  `-- EN rule
|  |     `-- AO isA
|  `-- OM Action
|     |-- OM hasTimeStamp
|     |-- OM hasTarget
|     |-- OM requestedBy
|     |-- OM invokes
|     |-- OM hasResult
|     `-- EN rule
|        `-- AO isA
|-- EN Profile
|  `-- EN LML
|     `-- EN rule
|        |-- AO effectivePotency
|        |-- AO potencyStep
|        `-- AO declaredTypeSingleValued
|-- EN Style
|-- EN Library
|-- EN Domain
|-- EN Open
`-- EN Workspace

Selected core rules in Datalog-style form​

The following Datalog-style rendering shows selected well-formedness rules represented as core content. Such rules are represented using Atom, Parameter, and Argument ordia. The rendering below is intended to make the rule meaning easier to read.

% Category rules over the core vocabulary (selected examples)
Ordium(X) :- hasLinguisticType(X, Ordium).
Ordium(X) :- ImmanentOrdium(X).
Ordium(X) :- TranscendentOrdium(X).
Ordium(X) :- BehaviouralOrdium(X).

ImmanentOrdium(X) :- Clabject(X).
ImmanentOrdium(X) :- Mediation(X).
ImmanentOrdium(X) :- Categorisation(X).
ImmanentOrdium(X) :- Moment(X).

TranscendentOrdium(X) :- Literal(X).
TranscendentOrdium(X) :- DataValue(X).
TranscendentOrdium(X) :- DataType(X).
TranscendentOrdium(X) :- Artifact(X).
TranscendentOrdium(X) :- Marker(X).

BehaviouralOrdium(X) :- Parameter(X).
BehaviouralOrdium(X) :- Argument(X).
BehaviouralOrdium(X) :- Atom(X).
BehaviouralOrdium(X) :- Operation(X).
BehaviouralOrdium(X) :- Invocation(X).
BehaviouralOrdium(X) :- Action(X).

Clabject(X) :- Entity(X).
Clabject(X) :- Relationship(X).
Mediation(X) :- Participation(X).
Mediation(X) :- Intercalation(X).
Moment(X) :- Method(X).
Moment(X) :- Attribute(X).
Entity(X) :- hasLinguisticType(X, Entity).
Relationship(X) :- hasLinguisticType(X, Relationship).
Participation(X) :- hasLinguisticType(X, Participation).
Categorisation(X) :- hasLinguisticType(X, Categorisation).
Intercalation(X) :- hasLinguisticType(X, Intercalation).
Attribute(X) :- hasLinguisticType(X, Attribute).
Marker(X) :- hasLinguisticType(X, Marker).

% Custodian locality-spine well-formedness (selected examples)
ancestor(X, A) :- hasCustodian(X, A).
ancestor(X, A) :- hasCustodian(X, M), ancestor(M, A).

violation(X, singleCustodian) :-
    hasCustodian(X, C1), hasCustodian(X, C2), C1 != C2.

violation(X, custodianCycle) :-
    ancestor(X, X), X != Ordium.

% Participation and datatype well-formedness examples
violation(P, lowerBoundAtMostUpperBound) :-
    Participation(P), hasLowerBound(P, L), hasUpperBound(P, U),
    U != Unlimited, L > U.

wellFormed(P, participationMayInduceAccessPath) :-
    Participation(P), isNavigableTo(P, True).

datatypeByCustodian(V, T) :-
    DataValue(V), hasCustodian(V, T), DataType(T).

datatypeByProperty(V, T) :-
    DataValue(V), ofDataType(V, T).

violation(V, dataValueDatatypeSourceBothViolation) :-
    datatypeByCustodian(V, T1), datatypeByProperty(V, T2).

violation(V, dataValueDatatypeSourceMissingViolation) :-
    DataValue(V), hasCustodian(V, C), not DataType(C), not ofDataType(V, _).

% Marker and auxiliary-ward idioms
marked(X, Tag) :-
    Marker(M), hasCustodian(M, X), hasTag(M, Tag).

markedRef(X, Tag, Target) :-
    Marker(M), hasCustodian(M, X), hasTag(M, Tag), refersTo(M, Target).

auxiliaryWard(X, A) :-
    Marker(A), hasCustodian(A, X), hasTag(A, WardRole.auxiliary).

auxiliaryFor(A, X) :-
    Marker(M), hasCustodian(M, A), hasTag(M, WardRole.auxiliary), refersTo(M, X).

LML profile rules in Datalog-style form​

The classification discipline that earlier drafts folded into the core is expressed here as content of the Ordium.Profile.LML clade. The core supplies hasPotency and hasDeclaredType as uninterpreted slots; the following rules give them their multi-level meaning and apply only where the LML profile is in force. The potency-step rule ranges over an effectivePotency helper so that the absent potency is read as zero convention is enforced rather than merely assumed.

% LML profile: interpretation of the potency and declared-type slots

% An absent potency is read as 0
effectivePotency(X, P) :- Clabject(X), hasPotency(X, P).
effectivePotency(X, 0) :- Clabject(X), not hasPotency(X, _).

% Each ontological classification step decreases potency by one
violation(X, potencyStep) :-
    hasDeclaredType(X, T),
    effectivePotency(X, P), effectivePotency(T, Q),
    P != Q - 1.

% LML admits a single ontological classifier per clabject
violation(X, declaredTypeSingleValued) :-
    hasDeclaredType(X, T1), hasDeclaredType(X, T2), T1 != T2.

Under the LML profile an abstract classifier is modelled as a potency-0 clabject: it has no direct instances and takes part in classification only through its subclasses. A profile adopting a different discipline — for example one admitting several ontological classification dimensions — interprets the same core slots with its own rules.

Appendix B - Family-history model in FHAS​

The following HUTN represents the family-history model shown visually in the LML figure. The same content may be projected into RDF/RDFS/OWL overlays, LML diagrams, relational forms, or other representations.

// PAMoLa / Ordium reference family-history model
// Family-history knowledge-base model in FHAS: Full, Hierarchical, Abridged, SUN references.
// String-valued properties are quoted. Ordium references are unquoted.
// Profile references are shown as canonical protected FQNs. Internal model references use SUNs.
// This version follows the current PAMoLa metamodel: Clabject, Relationship.hasAssociationName,
// Mediation.hasRelatum, Participation.hasRoleName, and no Attribute.hasDeclaredType.
// The hasPotency and hasDeclaredType values below are interpreted under the LML profile (Ordium.Profile.LML).

EN {hasName "FamilyModel",

    EN {hasName "O0",

        EN {hasName "PersonType", hasPotency 2},
    },

    EN {hasName "O1",

        EN {hasName "Person"},

        EN {hasName "MalePerson", hasPotency 1, hasDeclaredType PersonType},

        EN {hasName "FemalePerson", hasPotency 1, hasDeclaredType PersonType},

        CA {hasName "GenderPartition", isComplete true, isDisjoint true,
            MK {hasName "partitions", hasTag Ordium.Profile.MLT.PowertypeRelation.partitions, refersTo PersonType},
            IC {hasName "general", isGeneralisation true, hasRelatum Person},
            IC {hasName "male", hasRelatum MalePerson},
            IC {hasName "female", hasRelatum FemalePerson}
        },

        RE {hasName "parenthood", hasPotency 1,
            PA {hasName "parent", hasRoleName "hasParent", hasUpperBound 2, hasRelatum Person},
            PA {hasName "child", hasRoleName "hasChild", hasRelatum Person}
        },

        RE {hasName "fatherhood", hasPotency 1,
            PA {hasName "father", hasRoleName "hasFather", hasUpperBound 1, hasRelatum MalePerson,
                MK {hasName "subset", hasTag Ordium.Profile.UML.AssociationEndConstraint.subsetOf, refersTo parenthood.parent}
            },
            PA {hasName "child", hasRelatum Person}
        },

        RE {hasName "motherhood", hasPotency 1,
            PA {hasName "mother", hasRoleName "hasMother", hasUpperBound 1, hasRelatum FemalePerson,
                MK {hasName "subset", hasTag Ordium.Profile.UML.AssociationEndConstraint.subsetOf, refersTo parenthood.parent}
            },
            PA {hasName "child", hasRelatum Person}
        }
    },

    EN {hasName "O2",

        EN {hasName "GrantPlinth", hasDeclaredType MalePerson},

        EN {hasName "MrPlinth", hasDeclaredType MalePerson},

        RE {hasName "grantPlinthFatherhood", hasDeclaredType fatherhood,
            PA {hasName "father", hasRoleName "hasFather", hasRelatum MrPlinth},
            PA {hasName "child", hasRelatum GrantPlinth}
        }

    }
}