The LIST Specification#

Figure made with TikZ

The LIST Universe alongwith the 4 tiers of Referencing

Core Axioms#

  1. Linked Immutably: References between units of knowledge must be based on immutable IDs, ensuring they remain valid regardless of renaming or relocation.

  2. Static and Strong Typing: Each object is associated with an explicit, schema-bound metadata object, separating intrinsic document properties (\(\mathcal{M}_{\text{doc}}\)) from extrinsic user interaction metadata (\(\mathcal{M}_{\text{user}}\)).

Structural Model#

  • Atoms (\(\mathcal{A}\)): The smallest indivisible units of knowledge. Each atom has a unique, immutable \(\text{id}(a)\).

  • LIST Universe (\(\mathcal{U}\)): A set of Atoms and the directed edges (links) between them.

  • Recursive Composition: An Atom can itself be a Universe containing sub-atoms.

Tiers of Referencing#

LIST enables four levels of granularity:

  1. Whole-to-Whole: Document A \(\to\) Document B.

  2. Inside-to-Whole: Paragraph in Doc A \(\to\) Document B.

  3. Whole-to-Inside: Document A \(\to\) Paragraph in Doc B.

  4. Inside-to-Inside: Paragraph in Doc A \(\to\) Paragraph in Doc B.

Metadata as Types#

LIST abstracts the notion of metadata as a type system. In programming, a type provides a contract about the nature of the data; in LIST, metadata provides a contract about the nature of the knowledge unit.

  • Static Typing (Explicit Intention): While conventional filesystems use implicit or volatile metadata, LIST treats metadata as a first-class, explicit property of the Atom. This is analogous to moving from dynamic typing (where types are inferred or mutable) to static typing (where the nature of the data is explicitly declared).

  • Strong Typing (Preservation of Identity): In standard filesystems, metadata is often lost or altered during relocation. LIST implements “strong typing” by ensuring that metadata is schema-bound and persistent, providing the structural stability required for Impeccable Referencing.

This abstraction/analogy/comparison between Programming and LIST Type System is depicted in the following table:

Paradigm

Programming

LIST Filesystem

Dynamic / Loose

a = 45 (Type is inferred/mutable)

f.txt $\to$ content (Metadata is minimal/volatile)

Static / Strong

float a = 45 (Type is explicit/fixed)

M_a f.txt $\to$ content (Metadata is explicit/preserved)

Haskell Formalization#

The LIST specification is being formalized in Haskell to rigorously define the relationship between Atoms, Metadata, and the Universe.

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

-- | 
-- Module      : LISTFormal
-- Description : Formalization of the LIST (Linked Immutably, Static & Strong Typing) specification.
-- 
-- LIST Axioms:
-- 1. Linked Immutably: References are based on immutable IDs, decoupling identity from name/path.
-- 2. Static & Strong Typing: Each atom has an explicit, schema-bound metadata object.

module LISTFormal where

import Data.Map (Map)
import qualified Data.Map as Map
import Data.Set (Set)
import qualified Data.Set as Set
import Data.Text (Text)
import Data.Time (UTCTime)

-- | The unique, immutable identity of an Atom. 
-- Decoupled from the mutable filename or path.
newtype AtomId = AtomId Text
  deriving (Eq, Ord, Show)

-- | Intrinsic properties of the document (M_doc).
data DocMeta = DocMeta
  { creationDate :: UTCTime
  , originalFormat :: Text
  , sourceProvenance :: Text
  } deriving (Eq, Show)

-- | Extrinsic interaction metadata (M_user).
data UserMeta = UserMeta
  { tags      :: Set Text
  , annotations :: [Text]
  , customAttributes :: Map Text Text
  } deriving (Eq, Show)

-- | The metadata object providing the "Strong Typing" for the Atom.
data Metadata = Metadata
  { docMeta  :: DocMeta
  , userMeta :: UserMeta
  } deriving (Eq, Show)

-- | An Atom is the smallest indivisible unit of knowledge.
-- It supports recursive composition: an Atom can be a leaf or a nested Universe.
data Atom = Atom
  { atomId   :: AtomId
  , metadata :: Metadata
  , content  :: AtomContent
  } deriving (Eq, Show)

-- | Recursive composition enabling "Impeccable Referencing" (Inside-to-Inside).
data AtomContent
  = Leaf Text             -- ^ Simple data (e.g., a file's text)
  | SubUniverse Universe   -- ^ The Atom itself acts as a LIST Universe
  deriving (Eq, Show)

-- | A directed edge between two atoms based on their immutable identities.
data Link = Link
  { from :: AtomId
  , to   :: AtomId
  } deriving (Eq, Ord, Show)

-- | A LIST Universe (U) is a set of Atoms and the immutable links between them.
data Universe = Universe
  { atoms :: Map AtomId Atom
  , links :: Set Link
  } deriving (Eq, Show)

--------------------------------------------------------------------------------
-- API / Properties
--------------------------------------------------------------------------------

-- | Resolve a reference within a universe.
-- Because it uses AtomId, this is immutable regardless of renaming.
resolve :: AtomId -> Universe -> Maybe Atom
resolve aid u = Map.lookup aid (atoms u)

-- | Example of a "Whole-to-Whole" link creation.
linkAtoms :: AtomId -> AtomId -> Universe -> Universe
linkAtoms a b u = u { links = Set.insert (Link a b) (links u) }

-- | The "Static Typing" property: 
-- Ensuring every atom has a valid metadata contract.
verifyType :: Atom -> Bool
verifyType a = not . null . tags . userMeta . metadata $ a 
-- (Simplified check: an atom is 'validly typed' if it has at least one tag)

This formalization ensures that:

  • Immutability is guaranteed by using AtomId as the primary key in the Universe map.

  • Strong Typing is enforced via the Metadata record.

  • Recursive Granularity (Inside-to-Inside) is achieved through the AtomContent sum type.