@valos/kernel domain includes all core infrastructure components of ValOS - the Valaa Open System.

These components are hosted at the npmjs repository within @valos namespace.

These components are developed at the valos git repository.

This document is part of the vault workspace @valos/kernel (of domain @valos/kernel) which has the description: `ValOS common infrastructure tools and libraries monorepo`.

§ "Greetings, I am Valma, the ValOS Mediator. Who are you?"

ValOS ecosystem revolves around various roles. This document is a reference document of the ValOS fabric systems and structures and is directed for technicians. Check out the brief description and introductions of the other roles as well.

Valma itself is a collection of tools for interacting with the ValOS ecosystem, most notable of which is vlm the command line script invoker.

Your role: Your answer...
technician"I am a ValOS technician, I want to enable valonauts and expand valospace"
Introduction:

As a technician you develop and operate the ValOS fabric, the globally distributed web-like infrastructure of servers, services and components which underlies the Valospace.

You use vlm and employ your existing, likely professional knowledge of JavaScript, Node.js, DevOps, backend, library and other software development skills.

You create new open source and/or proprietary node packages. These permanently create new fabric functionalities and expand the Valospace by integrating it to old world systems.

Aliases:contributor developer administrator devops hacker etc
valonaut"I am a valonaut, I want to create and share interactive content"
Introduction:

As a valonaut you create, share and deploy web content and interactive applications fully from inside Valospace.

You use a web editor called Zero and with it employ traditional web technologies; HTML5, CSS and the Javascript dialect valoscript

The skills you learn to do this are like cycling or writing - they are used to support your other interests. While you don't need to become a professional you certainly can!

Aliases:everyone personal student prototypist etc
voyager"I am a ValOS voyager, I want to discover ValOS and enlighten others"
Introduction:

As a voyager you have stakes that matter. Whether you were to invest on a ValOS collaborator as a financier, to adopt ValOS as technology as an executive or just to commit your personal time and energy on a ValOS project you need to see forward.

To make sound decisions and to position yourself proactively you need to understand the big picture and philosophy of the ValOS ecosystem. Only then you can enlighten others.

You use tailored but real-world ValOS demo setups to illustrate how ValOS a solution could be configured to meet the needs at hand. Your audience can be your customer, your team or even just yourself.

Aliases:enthusiast entrepreneur evangelist investor business_owner sales_rep etc

§ Documentation

This domain provides the following primary documents:

§ Introduction documents

Name Package Version Tags
raem@valos/raem0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Resources And Events Model (ValOS-RAEM) API, schema and ontology
Introduction:

This library provides the definitions and reference implementations for the fundamental

ValOS Resources
and
ValOS Events
systems.

A ValOS Resource

resource
represents a well-defined part of the world. It has a well-defined state at each particular moment in time.

A ValOS Event

event
represents a dynamic change to a resource by describing the change from previous to subsequent resource states at a particular time.

The interplay of these distinct yet interwoven systems forms the foundation of the Valaa Open System.

script@valos/script0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Script API, schema
Introduction:

Valoscript extends ECMAScript 5 object model transparently for manipulating valospace resources. The valoscript interpreter creates events from all valospace resource modification side-effects and groups all such side effects into transactions. Valoscript retains ECMAScript 5 syntax and semantics.

sourcerer@valos/sourcerer0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Sourcerer API, schema
Introduction:

§ API reference documents

Name Package Version Tags

§ Ontology documents

Name Package Version Tags
kernel@valos/kernel0.35.0-rc.18PRIMARY DOMAIN ONTOLOGY TECHNICIAN
Title:@valos/kernel domain content reference
Ontology abstract:

@valos/kernel ontology provides vocabulary and definitions of the ValOS core concepts.

raem@valos/raem0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Resources And Events Model (ValOS-RAEM) API, schema and ontology
Ontology abstract:

@valos/raem ontology specifies the Valospace core types and properties directly to the @valos/kernel namespace.

revdoc@valos/revdoc0.35.0-rc.18PRIMARY ONTOLOGY
Title:ReVDoc - ReSpec document VDoc extension
Ontology abstract:

ReVDoc ontology provides vocabulary and definitions which are tailored for emitting ReSpec html output documents.

sbomdoc@valos/sbomdoc0.35.0-rc.18PRIMARY ONTOLOGY
Title:SBoMDoc - Software Bill of Materials VDoc extension
Ontology abstract:

SBoMDoc ontology provides vocabulary and definitions which are tailored for representing CycloneDX SBoM analysis semantic content.

script@valos/script0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Script API, schema
Ontology abstract:

@valos/script ontology specifies the Valospace core types and properties directly to the @valos/kernel namespace.

sourcerer@valos/sourcerer0.35.0-rc.18PRIMARY INTRODUCTORY ONTOLOGY LIBRARY
Title:ValOS Sourcerer API, schema
Ontology abstract:

@valos/sourcerer ontology specifies the Valospace core types and properties directly to the @valos/kernel namespace.

twindoc@valos/twindoc0.35.0-rc.18PRIMARY ONTOLOGY
Title:TwinDoc - Valospace Hypertwin VDoc extension
Ontology abstract:

TwinDoc ontology provides vocabulary for defining hypertwin mappings and configurations; actual hypertwin content is represented using the valos core ontologies and possible extension content ontologies.

vdoc@valos/vdoc0.35.0-rc.18PRIMARY ONTOLOGY
Title:VDoc - ValOS document interchange specification
Ontology abstract:

VDoc core ontology specifies the vocabulary for the human facing document structure by means of primitives which are sufficiently common and meaningful across all types of documents. These primitives include constructs such as chapters, titles, lists, tables, cross-references, etc.

VDoc core ontology explicitly does not specify any semantic meanings outside the document structure itself.

@valos/kernel-vault@valos/kernel-vault0.35.0-rc.17PRIMARY INTRODUCTION ONTOLOGY VALONAUT
Title:Valospace reference
Ontology abstract:

Valospace ontology provides vocabulary and definitions of the primary ValOS resources.

§ Other primary documents

Name Package Version Tags
sbom@valos/kernel-vault0.35.0-rc.17PRIMARY SBOM
Title:@valos/kernel-vault@0.35.0-rc.17 Software Bill of Materials
Abstract:

This document is an autogenerated CycloneDX SBoM document

type-vault/AssortedTutorials@valos/type-vault0.35.0-rc.18PRIMARY HOW_TO
Title:Assorted tutorials
Abstract:
This document is a collection of tutorials and possibly other notes created by Jaradacl based on the tasks given. (During first few days at least)

§ Workspaces

This domain introduces the following workspaces and workspace infrastructure components.

§ Workspace types, 10 new

This domain introduces the following workspace types.

Name Package Version
tool@valos/kernel0.35.0-rc.18
Introduction:'tool' workspace type is deprecated. Tools are a toolset implementation detail. A tool is similar to a toolset in that it can have its own workspace specific configurations. A tool differs from a toolset in that it cannot be standalone; it doesn't appear in listings, its always part of one or more toolsets and its toolsets.json config stanzas are placed under its parent toolset stanzas. The main case for tools and toolsets separation came from the release deployment system of opspaces, where the modularity and granular semantic versioning of tool packages allows for more efficient and robust deployments. Tool workspaces allows splitting complex toolsets into separate tools with different deployment logic. Infrastructure code which changes rarily can be placed under tool packages with naive deployment logic which relies on the tool package version number only. Frequently changing configs can be managed by the toolset workspace itself but even it can then use tool workspaces to source in commands and other resources to help with the deployment management. Additionally because the tool configuration is always inside its parent toolset config this allows the same tool be used by several different toolsets in a single workspace. Because of this all tool commands must have an option for '--toolset=<@scope/toolsetname>' which uses yargs.vlm.toolset as its default value.
toolset@valos/kernel0.35.0-rc.18
Introduction:Construct a collection of valma tools that other workspaces can select and use. A toolset is a package that can be selected by any valos workspace during 'vlm init'. More precisely: 1. given that the toolset is registered to a domain, and 2. the workspace is set up to use this domain (f.ex. during 'vlm init'), then 2. the 'vlm configure' presents the toolset as a selectable option, and if selected, 3. the toolset is added as a devDependency to the workspace, and also 4. a toolset configuration section with "inUse: true" is added to the workspace 'toolsets.json' using the toolset name as the key, and finally 5. the toolset configuration valma command is called by 'vlm configure' This makes all valma commands and other primitives of the toolset available for the workspace and also allows these commands to manage their workspace-specific configurations.
domain@valos/kernel0.35.0-rc.18
Introduction:Curate a valos discovery domain of packages. A domain package provides a set of valma commands for defining and managing a ValOS domain. Specific domain workspaces then: 1. shall provide domain package (de)registration via .configure/./{,de}register-package 2. can provide new workspace types via .select/.type/* 3. can provide new toolsets via .select/.toolsets/{,.domain//}{,.type//}{,.package/}/**/* Notably the package (de)registration should provide means for any new domain toolset packages to request the addition of their toolset configure command to the domain domain. Idiomatic way to implement this is a domain command which issues a PR against the source control repository of the domain package.
type@valos/kernel0.35.0-rc.18
Introduction:Declare a new valos type. A valos type is a name that can be chosen as a package.json:valos.type value during workspace init. Each type serves a particular purpose which is described in the type introduction. Each type is optionally associated with a specific type toolset which provides tools and code to implement and support the purpose of the type. When a type with a type toolset is chosen for a workspace the type toolsets is automatically configured to be always in use. As an example the type 'worker' adds the toolset @valos/type-worker which provides template files and shared code for managing perspire gateway execution environments. As a bit more self-referential example the type 'toolset' adds the toolset @valos/type-toolset which provides commands and shared code for managing the valos toolset functionality itself. Finally, the type of these type toolsets themselves is 'type'. And conversely initializing a fresh workspace with type 'type' makes the workspace to be a type toolset, with template files and provisions on how to implement and make the newly created type available to others. [NOTE(iridian, 2020-06): These provisions are very provisional, as in they don't exist yet.]
opspace@valos/kernel0.35.0-rc.18
Introduction:Dev a singular but repeated Ops 'build-release' / 'deploy-release' task. An opspaces workspace is used to for configuring, deploying, updating, monitoring and diagnosing all types of live infrastructure resources. Opspaces rely heavily on various toolsets to get their job done. Opspaces rarily are published and packages and typically reside in "opspaces/*" vault workspace directory
library@valos/kernel0.35.0-rc.18
Introduction:Develop a publishable software components package. A library workspace contains arbitrary ES5 source code and exposes a API via package.json .main stanza (usually index.js). A library can provide convenience valma commands but unlike toolsets a library cannot have workspace local configurations. Library workspaces are almost always published as a packages and typically reside in "packages/*" vault workspace directory.
spindle@valos/kernel0.35.0-rc.18
Introduction:Develop a valos gateway plugin. A gateway spindle extends inspire and perspire gateways with various functionalities. Core spindles provide new resource schemas, media decoders, protocol schemes, external APIs, valosheath APIs, etc. Custom spindles can be plugged into workers for arbitrary code but are only available on inspire if they are explicitly bundled with it. Spindles load their configuration from the gateway revelation. When a particular spindle is configured for a perspire worker its configuration is typically placed as a tool the toolset.
worker@valos/kernel0.35.0-rc.18
Introduction:Execute perspire gateway as a Node.js process. A worker workspace is used to launch and manage a particular service process. The workspace files contain configuration and data used by the process. This data can include even dynamic runtime data. A worker workspace is fully agnostic to version control solutions: - script-generated workers, where worker is locally spawned by scripts - clone-and-forget workers, where worker is cloned from a versioned upstream repository, has its configuration locally customized and local content potentially overridden. No further download sync is expected nor will workers push updates back upstream. Each clone represents its own computation. - synchronized workers, where the versioned repository itself represents the worker process. Worker workspace shards (there can be many if the computation is parallelizable) are still cloned from the versioned upstream. Unlike with clone-and-forget workers the synchronized worker workspaces keep themselves in sync with upstream configuration and data changes and adjust their computation accordingly. Sync workers shards can even push results back to the versioned repository if appropriate.
vdoc-extension@valos/kernel0.35.0-rc.18
Introduction:Extend valos document spec with domain specific vocabulary and functionality. A vdoc-extension workspace contains the extension specification and supporting libraries for a VDoc extension. It inherits library workspace characteristics but has a specific structure and initial templates which is useful for VDoc extensions in specific.
vault@valos/kernel0.35.0-rc.18
Introduction:Maintain many workspaces in a single version controlled mono-repository. A vault is a *monorepository* which contains multiple sub-workspaces of various types. Vaults are used to group packages with high cohesion together so that development, testing, review and deployment workflows can be done within a single repository when feasible. Vault is primarily an organizational unit and is hosted in a single version control repository. All sub-workspaces have identical access rights for all contributors. All sub-workspaces must have similar licences. Exceptions to this must be clearly noted both in the exceptional workspace root document as well as in the vault root document. A vault can have different types of workspaces in it; some of these (such as libraries, toolsets) may be published to repositories as *packages* so that they can be used as dependencies for other workspaces. Others are only local and used for other purposes; *opspaces* contain configurations and tools for managing infrastructure configurations and *workers* contain files for spawning local processes. No matter what the valos type of the domain all share important qualities: they can have package dependencies, are versioned and are managed by valma. A vault often also manages a *domain* for the packages it publishes via a *domain package*. Domain is a discovery construct. When a domain package is added as a devDependency to some external package then valma will be able to list and configure any applicable toolsets and other workspaces for this package.

§ Workspace toolsets, 3 new

This domain introduces the following workspace toolsets:

Name Package Version
@valos/type-toolset@valos/kernel0.35.0-rc.18
Introduction:Make current workspace selectable as a toolset for other workspaces. A toolset is a package that can be selected by any valos workspace during 'vlm init'. More precisely: 1. given that the toolset is registered to a domain, and 2. the workspace is set up to use this domain (f.ex. during 'vlm init'), then 2. the 'vlm configure' presents the toolset as a selectable option, and if selected, 3. the toolset is added as a devDependency to the workspace, and also 4. a toolset configuration section with "inUse: true" is added to the workspace 'toolsets.json' using the toolset name as the key, and finally 5. the toolset configuration valma command is called by 'vlm configure' This makes all valma commands and other primitives of the toolset available for the workspace and also allows these commands to manage their workspace-specific configurations.
@valos/web-spindle@valos/kernel0.35.0-rc.18
Introduction:Project http/s requests to valospace-fabric via a gateway plugin. Selects web-spindle as a worker toolset.
@valos/toolset-revealer@valos/kernel0.35.0-rc.18
Introduction:Run 'vlm rouse-revealer' to serve local inspire sites with webpack-dev-server. This toolset enables valma command 'rouse-revealer' for deploying a local dev environment for inspire gateway revelations. Sets up the webpack entry and output config as webpack.config.js in the workspace root, which combines shared revealer config from @valos/toolset-revealer/shared/webpack.config.js, local toolset config and any customizations in the root webpack.config.js itself.

§ Workspace tools, 4 new

This domain introduces the following workspace tools:

Name Package Version
copy-template-files@valos/kernel0.35.0-rc.18
Introduction:Copy toolset template files to the workspace. Copy toolset template files to the workspace. When selected for a toolset this tool will copy all template files from the toolset package templates/ sub-directory to the current workspace.
docs@valos/type-vault0.35.0-rc.18
Introduction:Generate /docs html files from all vault revdocs files. This type-vault tool provides commands for (re)generating the /docs folder from document sources present in the local workspaces, notably all revdoc documents matching glob '*.revdoc{,.test}.js'. Additionally this tool can be configured to regenerate all docs on (pre)release time.
domain@valos/type-vault0.35.0-rc.18
Introduction:Setup a type-domain package for curating the domain of this vault. This type-vault tool enables the domain management and (re)generation of docs/index.html domain summary revdoc document.
enable-babel@valos/type-vault0.35.0-rc.18
Introduction:Transpile all library files using the vault babel.config.js. This tool enables babel transpilation for a library workspace when 'vlm assemble-packages' is executed in the surrounding vault workspace.

§ Valma commands, 19 new

This domain introduces the following top-level valma commands:

Name
compose-revelation
Description:Compose revealer bundles based on the revealer toolset config
Introduction:Compose revealer bundles based on the revealer toolset config.
rouse-revealer
Description:Launch a webpack-dev-server at localhost serving a local revelation
Introduction:Launch a webpack-dev-server at localhost serving a local revelation. The revelation consists of two parts: webpack output and static files. Webpack output is configured by the project root webpack.config.js and the static files are served from --content-base. If this --content-base doesn't exist it is created by copying all files from the directory(s) provided by --content-source.
build-release
Description:Build a new release of this opspace
Introduction:Build a new release of this opspace. This command prepares, builds and tests a new opspace release locally without making external changes. This forms the first part of the opspace deployment process. The second half is `deploy-release` which performs the actual deployment process. This command resolves a local 'releasePath' for the build and then invokes all release-build sub-commands as follows: vlm .release-build/${toolsetGlob || "**/*"} --target=${releasePath} ${rest} These sub-commands (which can be local opspace commands or commands provided by opspace toolset dependencies) then (re)build the actual build artifacts under the target path.
deploy-release
Description:Deploy previously built releases to their deployment targets
Introduction:Deploy previously built releases to their deployment targets. This command is second part of the two-part deployment with build-release building the release.
assemble-packages
Description:Assemble all current modified vault packages (preparing for publish)
Introduction:Assemble all current modified vault packages (preparing for publish). Uses lerna to handle the monorepo sub-packages update detection, versioning, and git interactions. Configuration for lerna is in lerna.json: notably the version increase semantics is configured there. Lerna is not used for constructing the actual packages. This is done by a flat recursive cp to the target at the moment. Invokes babel for all projects with babel.config.js in their root. If the vault has a shared babel.config.js for all packages, a symlink from this root to each project should be created. When assembling lerna will automatically update the shared version for all packages and their cross-dependencies and make a git commit and git tag for the new version. This behaviour can be omitted with --no-versioning. Iterative development with yalc and publish-packages: Once a set of packages has been been built to the target, run: 'vlm publish-packages --publisher=yalc' This will make the package assemblies available in a local yalc 'registry'; see https://github.com/whitecolor/yalc for more details on how to use such packages by other depending packages. Reassembling and pushing those changes through yalc to dependents can be done with: 'vlm assemble-packages --reassemble --post-execute="cd $ASSEMBLY_TARGET && yalc push --no-sig"' This allows packages to be developed iteratively locally while having other packages depend and be tested against them.
clean-vault
Description:Clean various more or less transient vault files and subdirectories
Introduction:Clean various more or less transient vault files and subdirectories. By default the three elements installed by 'yarn install' are cleaned: 1. workspace packages by 'lerna clean --yes' 2. yalc local dependencies by 'yalc remove --all' 3. vault root node_modules by 'rm -rf' In addition, dist/ can be removed with --dist in preparation for a clean slate publish/deploy ops. Be mindful that all of dist/ will be removed. yarn.lock can be removed with --yarn in preparation for persisted dependency updates.
generate-domain-summary
Description:Generate the domain components summary file for the domain root revdoc
Introduction:Generate the domain components summary file for the domain root revdoc.
release-vault
Description:Prepare, commit and potentially publish a new release of vault packages
Introduction:Prepare, commit and potentially publish a new release of vault packages. Create a new release/prerelease branch or extend an existing one based on given options and current environment. Prepares the release by first running sanity checks, then cleaning and reinstalling intermediate files like node_modules, yarn workspaces, yarn.lock and dist/ and finally requires all test suites and lint to pass without errors. Once preparation is done creates a new release commit and tag using 'lerna version'. If --publish is not explicitly given then the final publish step must be manually performed. In this case a pre-publish phase is done which prepares the manual publish command instructions in the results output. Will invoke valma command hooks between stages as per: 1. 'vlm .release-vault/.prepared-hooks/{**/,}* --summary=' after successful preparation 2. 'vlm .release-vault/.committed-hooks/{**/,}* --summary=' after successful commit 3. 'vlm .release-vault/.pre-published-hooks/{**/,}* --summary=' after successful pre-publish 4. 'vlm .release-vault/.published-hooks/{**/,}* --summary=' after successful publish
publish-packages
Description:Publish package assemblies to their registries
Introduction:Publish package assemblies to their registries.
regenerate-docs
Description:Regenerate all configured /docs content
Introduction:Regenerate all configured /docs content.
write-revdoc
Description:Write a new revdoc source code file
Introduction:Write a new revdoc source code file.
bundle-revelation
Description:Bundles chronicles and other preloadable content into a revela.json
Introduction:Bundles chronicles and other preloadable content into a revela.json. Lists the chronicles listed in the revelation-path prologue. Preloads their event logs and media contents using vlm export-chronicle. Bundles these back into revelation files and adds them into prologue chronicleVLogs, chronicleMediaInfos, bvobInfos and bvobBuffers sections.
export-chronicle
Description:Exports given chronicle as file hierarchy under target directory
Introduction:Exports given chronicle as file hierarchy under target directory. Uses perspire.
perspire
Description:Launch a headless worker gateway for virtual DOM ValOS computation jobs
Introduction:Launch a headless worker gateway for virtual DOM ValOS computation jobs.
configure
Description:Configure the current ValOS workspace type, domain and all configurables
Introduction:Configure the current ValOS workspace type, domain and all configurables. Configures type and domain, selects and stows toolsets, tools and other configurables and finally configures them.
status
Description:Display the status of the current valos workspace
Introduction:Display the status of the current valos workspace. If toolsetGlob is specified the status is limited to status scripts matching '.status/*{toolsetGlob}*/**/*', otherwise all status scripts by '.status/**/*' are used.
draft-command
Description:Draft and possibly export a new valma command script
Introduction:Draft and possibly export a new valma command script. The new command is drafted as a local valma.bin/ command with the source file in valma/, making it the highest priority command and immediately available. With --import a existing exported script is copied for local editing and development.
@
Description:Execute a package bin command within valma context interactively
Introduction:Execute a package bin command within valma context interactively. Execute a package bin command within valma context interactively. This is the command line shim to valma script vlm.interact. Like 'npx -c' it executes a regular command exported by some package dependency to the node_modules/.bin/ folder. Unlike 'npx' which only searches the current directory and the global cache '@' prepends all available valma pools to env.PATH, innermost pool first.
init
Description:Initialize the current directory as a ValOS workspace from scratch
Introduction:Initialize the current directory as a ValOS workspace from scratch. This command will interactively create and configure a new valma workspace in the current working directory from scratch. Valma init has following interactive phases: 1. Initialization of package.json via 'yarn init' 2. Configuration of workspace valos.type and .domain via 'vlm .configure/.valos-stanza' 3. Addition of new known domains via 'yarn add --dev (-W)' 4. Selection of in-use toolsets from available toolsets via 'vlm select-toolsets' 5. Configuration of in-use toolsets and tools via 'vlm configure'

§ Type 'toolset' workspaces, 2 new

Construct a collection of valma tools that other workspaces can select and use.

A toolset is a package that can be selected by any valos workspace during 'vlm init'. More precisely: 1. given that the toolset is registered to a domain, and 2. the workspace is set up to use this domain (f.ex. during 'vlm init'), then 2. the 'vlm configure' presents the toolset as a selectable option, and if selected, 3. the toolset is added as a devDependency to the workspace, and also 4. a toolset configuration section with "inUse: true" is added to the workspace 'toolsets.json' using the toolset name as the key, and finally 5. the toolset configuration valma command is called by 'vlm configure'

This makes all valma commands and other primitives of the toolset available for the workspace and also allows these commands to manage their workspace-specific configurations.

toolset workspaces.

Name Version License
valma0.35.0-rc.17MIT
Description:A ValOS CLI tool for discovering and executing context-dependent command scripts
Introduction:
@valos/toolset-revealer0.35.0-rc.17MIT
Description:Tools for building revelations both for development and deployment purposes
Introduction:

§ Type 'library' workspaces, 8 new

Develop a publishable software components package.

A library workspace contains arbitrary ES5 source code and exposes a API via package.json .main stanza (usually index.js).

A library can provide convenience valma commands but unlike toolsets a library cannot have workspace local configurations.

Library workspaces are almost always published as a packages and typically reside in "packages/*" vault workspace directory. library workspaces.

Name Version License
@valos/engine0.35.0-rc.17MIT
Description:ValOS Engine API and Schema
Introduction:
@valos/gateway-api0.35.0-rc.17MIT
Description:Minimal footprint ValOS Gateway API local forwards
Introduction:
@valos/hypertwin0.35.0-rc.17MIT
Description:ValOS Hypertwin Specifications and Tools Library
Introduction:
@valos/inspire0.35.0-rc.17MIT
Description:ValOS Inspire application gateway
Introduction:
@valos/raem0.35.0-rc.17MIT
Description:ValOS Resources And Events Model (ValOS-RAEM) API, schema and ontology
Introduction:
@valos/script0.35.0-rc.17MIT
Description:ValOS Script API, schema
Introduction:
@valos/sourcerer0.35.0-rc.17MIT
Description:ValOS Sourcerer API, schema
Introduction:
@valos/tools0.35.0-rc.17MIT
Description:ValOS Tools API
Introduction:

§ Type 'domain' workspaces, 1 new

Curate a valos discovery domain of packages.

A domain package provides a set of valma commands for defining and managing a ValOS domain. Specific domain workspaces then: 1. shall provide domain package (de)registration via .configure/.<domain>/{,de}register-package 2. can provide new workspace types via .select/.type/* 3. can provide new toolsets via .select/.toolsets/{,.domain/<domain>/}{,.type/<type>/}{,.package/<name>}/**/*

Notably the package (de)registration should provide means for any new domain toolset packages to request the addition of their toolset configure command to the domain domain. Idiomatic way to implement this is a domain command which issues a PR against the source control repository of the domain package. domain workspaces.

Name Version License
@valos/kernel0.35.0-rc.17MIT
Description:@valos/kernel domain
Introduction:

§ Type 'vdoc-extension' workspaces, 4 new

Extend valos document spec with domain specific vocabulary and functionality.

A vdoc-extension workspace contains the extension specification and supporting libraries for a VDoc extension. It inherits library workspace characteristics but has a specific structure and initial templates which is useful for VDoc extensions in specific.

vdoc-extension workspaces.

Name Version License
@valos/revdoc0.35.0-rc.17MIT
Description:ReVDoc - ReSpec document VDoc extension
Introduction:
@valos/sbomdoc0.35.0-rc.17MIT
Description:SBoMDoc - Software Bill of Materials VDoc extension
Introduction:
@valos/twindoc0.35.0-rc.17MIT
Description:TwinDoc - Valospace Hypertwin VDoc extension
Introduction:
@valos/vdoc0.35.0-rc.17MIT
Description:VDoc - ValOS document interchange specification
Introduction:

§ Type 'spindle' workspaces, 1 new

Develop a valos gateway plugin.

A gateway spindle extends inspire and perspire gateways with various functionalities.

Core spindles provide new resource schemas, media decoders, protocol schemes, external APIs, valosheath APIs, etc.

Custom spindles can be plugged into workers for arbitrary code but are only available on inspire if they are explicitly bundled with it.

Spindles load their configuration from the gateway revelation. When a particular spindle is configured for a perspire worker its configuration is typically placed as a tool the toolset.

spindle workspaces.

Name Version License
@valos/web-spindle0.35.0-rc.17MIT
Description:A spindle for structured ValOS Web APIs
Introduction:

§ Type 'type' workspaces, 5 new

Declare a new valos type.

A valos type is a name that can be chosen as a package.json:valos.type value during workspace init. Each type serves a particular purpose which is described in the type introduction.

Each type is optionally associated with a specific type toolset which provides tools and code to implement and support the purpose of the type. When a type with a type toolset is chosen for a workspace the type toolsets is automatically configured to be always in use.

As an example the type 'worker' adds the toolset @valos/type-worker which provides template files and shared code for managing perspire gateway execution environments. As a bit more self-referential example the type 'toolset' adds the toolset @valos/type-toolset which provides commands and shared code for managing the valos toolset functionality itself.

Finally, the type of these type toolsets themselves is 'type'. And conversely initializing a fresh workspace with type 'type' makes the workspace to be a type toolset, with template files and provisions on how to implement and make the newly created type available to others. [NOTE(iridian, 2020-06): These provisions are very provisional, as in they don't exist yet.] type workspaces.

Name Version License
@valos/type-spindle0.35.0-rc.17MIT
Description:The ValOS 'spindle' workspace type toolset
Introduction:
@valos/type-opspace0.35.0-rc.17MIT
Description:The ValOS 'opspace' workspace type toolset
Introduction:
@valos/type-vault0.35.0-rc.17MIT
Description:The ValOS 'vault' workspace type toolset
Introduction:
@valos/type-worker0.35.0-rc.17MIT
Description:The ValOS 'worker' workspace type toolset
Introduction:
@valos/type-domain0.35.0-rc.17MIT
Description:The ValOS domain workspace type toolset
Introduction:

§ @valos/kernel domain root ontology

All labels have implicit prefix IRI "https://valospace.org/kernel#" (typically abbreviated as prefix "valos_kernel:")

@valos/kernel ontology provides vocabulary and definitions of the ValOS core concepts.

§ valos_kernel IRI prefixes

Prefix IRI
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfshttp://www.w3.org/2000/01/rdf-schema#
xsdhttp://www.w3.org/2001/XMLSchema#
owlhttp://www.w3.org/2002/07/owl#
dchttp://purl.org/dc/elements/1.1/
valos_kernelhttps://valospace.org/kernel#

§ valos_kernel valos_kernel:Class vocabulary

rdfs:label rdfs:subClassOf
Classrdfs:Class
rdfs:commentThe class of classes which are defined by the ValOS kernel domain ontologies.
Propertyrdf:Property
rdfs:commentThe class of properties which are defined by the ValOS kernel domain ontologies.

§ valos_kernel valos_kernel:Property vocabulary

rdfs:label rdfs:subPropertyOf rdfs:domain rdfs:range

§ valos_kernel valos_raem:Type vocabulary

rdfs:label revdoc:brief rdfs:subClassOf

§ valos_kernel valos_raem:Field vocabulary

rdfs:label rdfs:domain rdfs:range rdf:type rdfs:subPropertyOf valos_raem:coupledField

§ valos_kernel valos_raem:Resolver vocabulary

rdfs:label rdf:type Comment

§ valos_kernel remaining vocabulary

rdfs:label rdf:type rdfs:subClassOf
@context
rdfs:comment

§ JSON-LD context term definitions

Term Definition @id @type @container

§ Component hierarchy

This section will contain hierarchical presentation of all above components (and more).