CORE-LD v0.1.0

The foundational LD profile of the URS universal representation model — defining the universal semantic building blocks for all DAG-*-LD specifications.

Status: Draft Constitutional dependencies: URS v0.1.0 (specs.initialcore.net/urs.html) Spec family: Foundational Profile (see CCA Framework §3 — Profile Composition) Dimension registry prefix: CORE-LD Canonical @context: https://specs.initialcore.net/ns/core-ld.jsonld

1. Preamble

CORE-LD is the foundational profile from which all other DAG-*-LD specifications derive. It does not specify encoding (JSON, CBOR), addressing mode (DAG, flat), or functional role (INPUT, MEMORY, POLICY). It defines the universal semantic building blocks that every extension inherits.

What CORE-LD is:

The LD profile of the URS data model (Entity, Property, Identifier, Link, Group)
The identity, provenance, and relationship invariants from URS §4, §6, §8
The composition boundary — any specification that claims CORE-LD conformance must satisfy all CORE-LD invariants

What CORE-LD is not:

Not an encoding format (those are JSON-CORE-LD, CBOR-CORE-LD, etc.)
Not a content-addressing scheme (that is DAG addressing, composable with any profile)
Not a functional profile (INPUT-LD, MEMORY-LD, POLICY-LD each add their own on top of CORE-LD)

1.1 Relationship to the dimensional architecture

Reality → USC → URS → CORE-LD → [functional profiles] → [encoding bindings] → CodeLabs → CoreFab → studio
                                  Foundational          Role-specific         Syntax-specific

URS defines what must be representable (the constitutional contract). CORE-LD defines how it is structurally expressed as a graph of typed, identified entities with provenance. Every functional profile (INPUT-LD, MEMORY-LD, POLICY-LD, TRUST-LD) is an extension of CORE-LD. Every encoding binding (JSON-CORE-LD, CBOR-CORE-LD) is a serialization of CORE-LD.

2. Representations

CORE-LD inherits the five primitive representation kinds from URS v0.1.0 §2, with the LD-specific term mappings and structural rules defined here.

2.1 Entity

{"@id": "_:e1", "@type": "Entity"}

Every distinct represented thing is an Entity. An Entity has:

A unique identifier (`@id` in LD, expressed as IRI or blank node)
A kind (the `@type`, drawn from the URS kind set or a profile-extension)
Zero or more Properties
Zero or more Identifiers (at least one implicit or explicit per URS I2)
Zero or more Links to other Entities
Zero or one Provenance block

Canonical form (CORE-LD frame):

{
  "@context": "https://specs.initialcore.net/ns/core-ld.jsonld",
  "@id": "_:entity-id",
  "@type": "Entity",
  "name": "...",
  "identifier": { "@type": "Identifier", "@id": "_:id", "scope": "local" },
  "provenance": {
    "Representer": "did:...",
    "Timestamp": "2030-01-01T00:00:00Z",
    "Authority": { "authorityType": "inherent" },
    "RepresentationContext": "urn:..."
  }
}

2.2 Property

A named value attached to an Entity. A Property has:

A name (restricted to the set of allowable predicate terms via @context)
A value (literal: string, number, boolean, null; or entity reference: IRI mapping to another Entity)
Zero or one Provenance block (overrides inherited provenance — constitutional entities only)

Properties appear as JSON-LD key-value pairs within the Entity object. Property references to other Entities use the target's @id.

2.3 Identifier

A handle by which an Entity is known. An Identifier has:

A value (`@id` of the Identifier node)
A scope (`local`, `constitutional`, or an explicit IRI scope)
A constitutional flag (`isConstitutional: boolean`)
An optional canonical hash (`canonicalHash`) for constitutional identifiers

An Entity must have at least one Identifier (URS I2). The first identifier may be implicit from the Entity's own @id if no explicit identifier field is provided.

2.4 Link

A directed relationship between two Entities. A Link has:

A unique `@id`
A source Entity (`source`)
A target Entity (`target`)
A link type (`linkType`) drawn from a registered vocabulary
Optional constitutional metadata (`mayDelegate`, `delegationDepth`, `authority`)

2.5 Group

A collection of Entities treated as a unit. A Group has:

A unique `@id`
A group variant (`groupVariant`: `Set`, `Sequence`, or `Map`)
A membership container (`members` array for Set/Sequence, `entries` object for Map)

Groups may not contain themselves (directly or transitively — URS I10).

3. Identity and Naming

3.1 Entity identity

An Entity is identified by its @id. CORE-LD defines three identity levels, inherited from URS §4.1:

Level	Name	Property	Example
L1	Structural identity	Byte-for-byte canonical form	Same canonical JSON → same L1
L2	Identity identity	Hash of all identifiers + properties, excluding provenance	Same "what" independent of "who said it"
L3	Constitutional identity	Full entity including provenance	Same L2 + same constitutional context

3.2 Identifier scopes

Scope	Pattern	Purpose
`local`	`_:...`	Blank node, scoped to containing document
`constitutional`	`did:...`	Stable across documents, binds to provenance
Explicit IRI	Full IRI	Registered namespace, domain-specific

3.3 Constitutional identifiers

An identifier marked isConstitutional: true MUST satisfy:

Its `@id` is a DID or registered IRI scheme (UR $ I12)
Its Entity carries a `provenance` block (URS I13, I15)
Its Entity's provenance includes `Authority`, `Representer`, `Timestamp`, and `RepresentationContext` (URS I16)
If `canonicalHash` is present, it MUST be a valid multihash of the entity's L2 canonical form (URS I12)

4. Provenance Model

CORE-LD inherits the URS constitutional provenance model (§6) as a mandatory attachment for constitutional entities and optional for local entities.

4.1 Provenance block structure

"provenance": {
  "Representer": "did:icore:admin",
  "Timestamp": "2026-07-30T00:00:00Z",
  "Authority": { "authorityType": "inherent" },
  "RepresentationContext": "urn:icore:context:main"
}

Required fields (for constitutional entities — URS I16):

`Representer`: DID or IRI identifying who/what asserted this representation
`Timestamp`: ISO 8601 UTC instant
`Authority`: Object with `authorityType` — one of `inherent`, `granted`, `derived`
`RepresentationContext`: IRI or URN declaring the context under which this representation is valid

Optional fields (for all entities):

`PriorState`: Reference to a previous representation of the same entity
`Witness`: Additional DID that countersigns this representation
`Evidence`: Link to supporting proof material

4.2 Authority types

Type	Meaning	Delegation permitted?
`inherent`	Authority flows from nature of entity itself	No
`granted`	Authority explicitly delegated	Yes, with MayDelegate flag
`derived`	Authority inferred through constitutional deduction	No direct delegation

4.3 Provenance inheritance

An Entity without an explicit provenance block inherits provenance from its containing document's document-level provenance (if declared). Constitutional identifiers always require explicit provenance on their Entity.

5. Relationship Model

5.1 Direct properties

Named values attached directly to an Entity object in JSON-LD. Property names MUST be defined terms in the active @context. Property values may be:

Literals (string, number, boolean, null)
Entity references (IRI string matching another Entity's `@id`)
Arrays of the above

5.2 Explicit links

Directed, typed edges between Entities, represented as Link objects in the Entity's links array. A Link:

MUST have a source and target (URS I6)
MUST have a linkType (URS I7)
The linkType MUST be a registered predicate

5.3 Groups

An Entity of @type: Group provides a collective structure over member Entities:

Set: Unordered, unique members (`members` array with distinct `@id` values)
Sequence: Ordered, possibly duplicate members (`members` array preserved in framing order)
Map: Key-value association (`entries` object with string keys mapping to Entities)

6. Composition Rules

CORE-LD is the foundational profile. Functional profiles extend it. Encoding profiles bind it.

6.1 Adding a functional profile

A functional profile (e.g., INPUT-LD, MEMORY-LD) MUST: 1. Declare extends: CORE-LD in its preamble 2. Inherit all CORE-LD invariants as its own 3. Add only new invariants — never relax existing ones 4. Define its own @context extension terms as a superset of the CORE-LD @context 5. State its composition rule: CORE-LD + [profile]

6.2 Adding an encoding binding

An encoding profile (e.g., JSON-CORE-LD, CBOR-CORE-LD) MUST: 1. Declare encodes: CORE-LD (or encodes: CORE-LD + [profile] for multi-profile bindings) 2. Preserve all CORE-LD invariants in the encoding 3. Define a deterministic lossless mapping between the LD abstract representation and the byte representation 4. State its encoding rule: [profile] + [encoding]

6.3 Addressing mode

Addressing modes (content-addressed via DAG, location-addressed, etc.) are orthogonal to CORE-LD. A specification that uses content-addressing (e.g., DAG-CORE-LD) adds:

Canonical hash computation rules per URS Canonicalization
CID binding rules
Content-address invariants (C1–C5 from URS Canonicalization)

6.4 Profile naming convention

[CORE-LD]                              → Foundational
[Profile-LD]                           → Functional extension
[Encoding]-[Profile-LD]                → Encoded profile
[Addr]-[Encoding]-[Profile-LD]         → Addressed, encoded profile
Example: DAG-CBOR-MEMORY-LD
         Addr=DAG, Encoding=CBOR, Profile=MEMORY-LD (extends CORE-LD)

7. Invariants

CORE-LD inherits all 23 URS invariants (I1–I23) as its conformance criteria. These are restated here in LD-specific terms.

7.1 Structural invariants (I1–I11)

ID	Invariant	CORE-LD check
I1	Every entity has a valid kind	`@type` ∈ {Entity, Property, Identifier, Link, Group} or registered extension
I2	Every entity has at least one identifier	`@id` present, or explicit `identifier` field, or both
I3	No two entities share an identifier	All `@id` values + all explicit identifier values are unique across the graph
I4	Every property references only entities in the graph	Property values that are IRI strings resolve to an entity `@id` in the graph
I5	Every entity is self-referencing	Entity's own `@id` implicitly references itself
I6	Every link has a source and target in the graph	`source` and `target` IRIs resolve to entities in the graph, target non-empty
I7	Every link has a type	`linkType` present and non-empty
I8	Set members are unique	In a Set group, no two `members` entries have the same `@id`
I9	Map keys are unique	In a Map group, all keys in `entries` are distinct
I10	No group contains itself	Recursive containment check against group hierarchy
I11	Exactly one root entity	A single Entity not referenced as a property/link/member of another Entity

7.2 Identity invariants (I12–I15)

ID	Invariant	CORE-LD check
I12	Constitutional identifiers use valid hash format	`canonicalHash` is a valid multihash starting with known function code
I13	Constitutional identifiers require provenance attestation	Every Entity with `isConstitutional: true` identifier has a `provenance` block
I14	Local identifiers use blank nodes	Local-scope identifiers use `_:` prefix
I15	Constitutional provenance is chained	Provenance of a constitutional entity traces to a known authority

7.3 Provenance invariants (I16–I19)

ID	Invariant	CORE-LD check
I16	Provenance block has required fields	Must include Representer, Timestamp, Authority, RepresentationContext
I17	Authority type is valid	`authorityType` ∈ {inherent, granted, derived}
I18	Delegation links have permission flags	`mayDelegate: true` on granted-authority delegation links
I19	Delegation depth is bounded	`delegationDepth` ≤ configurable maximum (default 5)

7.4 Context invariant (I20)

ID	Invariant	CORE-LD check
I20	Constitutional representation declares context	`provenance.RepresentationContext` is present for any entity with constitutional identifiers

7.5 Canonicalization invariants (I21–I23)

ID	Invariant	CORE-LD check
I21	Canonical form is deterministic	Same entity graph produces identical canonical output
I22	Canonical form encodes structural identity only	Identifier relabeling preserves structural identity
I23	Canonical form is acyclic	No entity transitively contains itself

8. Core @context

The standard CORE-LD @context resolves to:

{
  "@context": {
    "Entity": "https://specs.initialcore.net/ns/urs#Entity",
    "Property": "https://specs.initialcore.net/ns/urs#Property",
    "Identifier": "https://specs.initialcore.net/ns/urs#Identifier",
    "Link": "https://specs.initialcore.net/ns/urs#Link",
    "Group": "https://specs.initialcore.net/ns/urs#Group",
    "Set": "https://specs.initialcore.net/ns/urs#Set",
    "Sequence": "https://specs.initialcore.net/ns/urs#Sequence",
    "Map": "https://specs.initialcore.net/ns/urs#Map",

    "kind": "https://specs.initialcore.net/ns/urs#kind",
    "name": "https://schema.org/name",
    "description": "https://schema.org/description",
    "identifier": {
      "@id": "https://specs.initialcore.net/ns/urs#identifier",
      "@type": "@id"
    },
    "provenance": {
      "@id": "https://specs.initialcore.net/ns/urs#provenance",
      "@type": "@id"
    },
    "links": {
      "@id": "https://specs.initialcore.net/ns/urs#links",
      "@container": "@set"
    },
    "members": {
      "@id": "https://specs.initialcore.net/ns/urs#members",
      "@container": "@set"
    },
    "entries": "https://specs.initialcore.net/ns/urs#entries",
    "groupVariant": "https://specs.initialcore.net/ns/urs#groupVariant",

    "source": "https://specs.initialcore.net/ns/urs#source",
    "target": "https://specs.initialcore.net/ns/urs#target",
    "linkType": "https://specs.initialcore.net/ns/urs#linkType",
    "isConstitutional": "https://specs.initialcore.net/ns/urs#isConstitutional",
    "scope": "https://specs.initialcore.net/ns/urs#scope",
    "canonicalHash": "https://specs.initialcore.net/ns/urs#canonicalHash",

    "Representer": "https://specs.initialcore.net/ns/urs#Representer",
    "Timestamp": {"@id": "https://specs.initialcore.net/ns/urs#Timestamp", "@type": "xsd:dateTime"},
    "Authority": "https://specs.initialcore.net/ns/urs#Authority",
    "authorityType": "https://specs.initialcore.net/ns/urs#authorityType",
    "RepresentationContext": "https://specs.initialcore.net/ns/urs#RepresentationContext",
    "PriorState": "https://specs.initialcore.net/ns/urs#PriorState",
    "mayDelegate": "https://specs.initialcore.net/ns/urs#mayDelegate",
    "delegationDepth": "https://specs.initialcore.net/ns/urs#delegationDepth",

    "inherent": "https://specs.initialcore.net/ns/urs#inherent",
    "granted": "https://specs.initialcore.net/ns/urs#granted",
    "derived": "https://specs.initialcore.net/ns/urs#derived",
    "local": "https://specs.initialcore.net/ns/urs#local"
  }
}

9. Conformance

9.1 Implementation requirements

A conforming CORE-LD implementation MUST:

1. Parse CORE-LD documents using the URS frame (§2.1 canonical form) 2. Validate all 23 URS invariants (I1–I23) against any claimed CORE-LD document 3. Produce canonical CORE-LD output (deterministic key-sorted JSON-LD with the CORE-LD frame applied) 4. Reject documents that violate any invariant, with a diagnostic identifying which invariant(s) failed and which entity(ies) caused the failure 5. Resolve the CORE-LD @context (§8) to its published URI

9.2 Conformance levels

Level	Requirements
L1 Structural	I1–I11 pass; document parses and frames correctly
L2 Identity	L1 + I12–I15 pass; constitutional identifiers valid
L3 Constitutional	L2 + I16–I23 pass; full provenance + canonicalization

9.3 Conformance suite

The URS Conformance Suite (urs_conformance.py) serves as the CORE-LD conformance suite. It validates all 23 invariants on any CORE-LD document. To claim CORE-LD L3 conformance, an implementation MUST pass the full suite on a standard corpus of test documents.

The Profile Conformance Extensions (profile_conformance.py) extend the suite to the functional profiles: each profile run validates the 23 inherited invariants plus the profile's own invariants (I-INPUT-1..12, I-MEM-1..18, I-POL-1..19, I-TRUST-1..20). It is the conformance suite for the JSON-CORE-LD encoding binding (§6.2 composition rule) and its multi-profile bindings (JSON-INPUT-LD, JSON-MEMORY-LD, JSON-POLICY-LD, JSON-TRUST-LD).

10. CORE-LD Profile Composition Summary

CORE-LD (foundational)
├── extends with: functional role
│   ├── + INPUT-LD    →  CORE-LD + input semantics
│   ├── + MEMORY-LD   →  CORE-LD + persistent knowledge
│   ├── + POLICY-LD   →  CORE-LD + constraint/reasoning
│   ├── + TRUST-LD    →  CORE-LD + attestation/verification
│   └── + DOMAIN-*    →  CORE-LD + domain vocabulary
├── binds to: encoding
│   ├── + JSON        →  JSON-CORE-LD
│   ├── + CBOR        →  CBOR-CORE-LD
│   └── + ...         →  other encoding bindings
└── addresses via: addressing mode
    ├── + DAG         →  DAG-*-CORE-LD
    └── + ...         →  other addressing modes

All combinations inherit CORE-LD invariants. All combinations are interoperable at the profile level. No combination may weaken or omit a CORE-LD invariant.

CORE-LD v0.1.0 — July 30, 2026. Draft. Extends URS v0.1.0. Defines the foundational profile of the DAG--LD specification family.*