For full text search please use the '?' prefix. e.g. ? Onboarding

Concept Summary

Semantic Mesh — LLM-Oriented Concept Summary

This document is the canonical, compact context for AIs/LLMs. It summarizes all documentation/concepts.* notes and cross-links to authoritative pages.

0) Twin Purposes

  • Mint URLs (IRIs) for referring to things on the Semantic Web.
  • Hold semantic datasets and supporting resources that use those URLs.

1) Definition A semantic mesh is a dereferenceable, folder-structured, possibly-versioned corpus of semantic resources where every URL resolves to meaningful content. A mesh maps directly from a Git repository’s folder hierarchy to a published static site so that:

  • Every resource is addressable by a stable URL.
  • Folder resources are dereferenceable via generated index.html resource pages.
  • RDF datasets live as distributions on versioned flow snapshots.
  • The weave process maintains coherence and keeps the repo publish-ready.

See:

2) Design Principles

3) Core Abstractions

3.1 Mesh Resources (Nodes and Components)

3.2 Facets (Folder, File, Dataset)

4) Addressing and Identity

4.1 Namespace and Relative Identifiers

  • Folder names become namespace segments; the path is the node’s relative identifier (and URL path when published).
  • Relative identifiers are used within distributions for transposability; resolve relative to distribution location. See:
  • Namespace: overview
  • Namespace Segment: segment definition
  • system segments: reserved segments
  • intramesh identifier: relative IDs

4.2 URL Semantics

  • Concept URLs (slash-terminated) identify nodes, flows (abstract), snapshots (conceptual), and handle.
  • Content URLs (with filenames) identify retrievable files: distributions, HTML pages, READMEs, assets.
  • Follow document-vs-thing hygiene to avoid ambiguity. See:
  • identifier: URL types and mapping
  • Reference Iri Choices: trade-offs
  • IRI: terminology; prefer “URLs” when referring to mesh-local IRIs

4.3 Handle Rationale

  • A node’s URL refers to its referent (namespace, real-world entity, or dataset concept).
  • The handle component provides a URL to refer to the node itself “as a mesh resource” (for config, provenance, lifecycle). See:
  • node handle
  • handle resource page

5) Physical Structure and Reserved Folders

Reserved folder names (underscore-prefixed; canonical set):

  • _node-handle/
  • Flow containers (abstract datasets):
    • _meta-flow/, _data-flow/
    • _config-operational-flow/, _config-inheritable-flow/ (see §9)
  • Snapshots inside a flow:
    • _current/, _next/, _vN/ (e.g., _v1/, _v2/, …)
  • Assets:
    • _assets/ (static files)

Folder-note pages for these reserved names live under concept.mesh.resource.folder.*.md (where defined):

6) Data and Versioning Model

  • Only flows are versioned (flows are DatasetSeries). Nodes are not versioned.
  • Flow snapshots:
    • _current/: latest stable realization; after weave it equals the content of the latest _vN/.
    • _next/: mutable working area.
    • _vN/: immutable history for precise citation and provenance.
  • Working distribution: _next/ typically contains a single editable source; weave can fan-out serializations.
  • Sibling distribution: patterns and constraints for multi-file realizations. See:
  • Versioning
  • Working Distribution
  • Sibling Distribution

7) Lifecycle and Weave Process Weave maintains structural coherence and publication readiness:

  • Ensures required system components exist.
  • If versioning is enabled, creates a new _vN/ from _next/.
  • Promotes _next/ contents to _current/.
  • Updates meta/provenance; regenerates resource pages.
  • Resolves internal links to maintain transposability.
  • Integrates with the scanner where applicable. See:
  • Weave Process
  • static site generation
  • Scanner
  • Provenance

8) Publishing and Sites

  • Repos are static-site-ready; pushing to GitHub Pages or any static host publishes the mesh (folder paths → URL paths).
  • Transposition (domain/project move) is safe with relative IDs. See:
  • mesh repo
  • Semantic Site
  • Publication

1) Configuration and Inheritance (Two Config Flows)

  • Operational Config Flow: final, resolved settings for a node (consumer). Overrides apply here.
  • Inheritable Config Flow: settings a node offers to descendants (provider). Property-level merge; order: parent → … → service → platform; propagation can be firewalled.
  • Resolution: a single inheritance mechanism resolves operational config from inheritable configs plus service/platform defaults. Explicit operational entries override inherited ones. See:
  • meshnode config flows: overview
  • operational config flow
  • inheritable config flow
  • Node Config Defaults: defaults as inheritable values

1) Aggregated Views

  • Aggregated distribution: optional roll-up of child data nodes’ current datasets at a parent node for convenience. See:
  • Aggregated Distribution

1) Minimal File Tree Example

/repo-root/
├── _assets/                         # optional site-wide assets
├── my-node/                         # a mesh node (folder)
│   ├── _node-handle/                # handle component (resource.node-component.node-handle)
│   ├── _meta-flow/                  # metadata flow (system)
│   │   ├── _current/
│   │   └── _v1/
│   ├── _data-flow/                  # data flow (for data nodes)
│   │   ├── _current/
│   │   ├── _next/
│   │   └── _v1/
│   ├── _config-inheritable-flow/    # provider config (optional)
│   ├── _config-operational-flow/    # resolved config (optional; may be system-written)
│   ├── index.html                   # resource page
│   ├── README.md
│   └── CHANGELOG.md
└── docs/ or public host mapping     # publication target

12) Visual Overview

graph TD A[Mesh Node] --> B[Handle] A --> C[Meta flow] A --> E[Data flow] A --> G[Asset tree] A --> H[Resource pages] C --> C1[_current] C --> C2[_vN] E --> E1[_current] E --> E2[_next] E --> E3[_vN]

13) Glossary

  • semantic mesh: the set of addressable resources in a repository, published as a site
  • Node: an extensible folder resource containing nodes/components: mesh node
  • Node component: terminal resource that supports node behavior/structure: node component
  • Flow: DatasetSeries representing an abstract dataset (meta/data/config): node flow
  • flow snapshot: concrete Dataset realization of a flow (_current/, _next/, _vN/)
  • snapshot distribution: a concrete serialization file (TriG, JSON-LD, etc.):
  • Handle: indirection to refer to the node “as a mesh resource”: node handle
  • Resource Page: dereferenceable index.html for folders: mesh resource page
  • Aggregated Distribution: parent-level roll-up of children’s current data: Aggregated Distribution
  • Weave: lifecycle operation to version/promote/regenerate/repair: Weave Process
  • Evidence:
  • Recommendation: Make TriG and JSON-LD first-class supported formats; document status for TTL, N-Quads, RDF/XML.

K. Config defaults doc should include explicit property names/shapes

  • Evidence:
  • Recommendation: Provide explicit terms/shapes aligned with config-flow vocabulary and the inheritance resolution doc.

L. Relative identifier examples mention _config-flow

M. Confirm embedded mesh doc and folder-note coverage

  • Evidence:
    • Embedded Mesh exists; ensure it’s linked where appropriate (namespace/base docs).
  • Recommendation: Link embedded mesh doc from base/namespace docs.

1) Minimal “Core Context” to feed an LLM If context must be small, include:

  • Definition (§1) and Principles (§2).
  • Node vs Component; Flows vs Snapshots (§3).
  • URL semantics and relative identifiers (§4).
  • Reserved folders and example tree (§5, §11).
  • Lifecycle and weave (§7).
  • Config flows model (§9).
  • Aggregated views (§10).

1) LLM Usage Notes

  • Use the folder names and URL semantics exactly as standardized here.
  • When encountering contradictions, prefer the standards in §14 recommendations.
  • When linking within the mesh, prefer relative identifiers to maintain transposability.
  • Avoid “IRI/URI” unless drawing a distinction; for mesh-local identifiers, use “URLs”.