EntityScript™

EntityScript™ file specification

EntityScript™ compliant files can be created manually or by using the automated .entity generator. New Entity Operations Inc. designs and maintains a variety of EntityScript™-specific tools to help create, manage, index, and retrieve mass-quantities of these structures for automation purposes.

Example EntityScript™ (.entity) file

## DS0000001.ds - Created by: K3PNQHB721EM

KEY::: entity_id

## Entity Snapshot
datascript_id = ['entity_id']
title = ['EntityScript™ Generic Structure']

## Package Snapshot
package_type = ['indexer'] # can be indexer, contact, or game
package_id = ['NHHGE35IOP32NH']

## Directory=> List-file
DLIST = ['DS0000001.ds']

## Index-List
INDEX = [
    "entity_id", "entity_category", entity_path", "entity_meta",
    "description", "entity_manifest_id"
]

## Identifier Overview
identifier_type = [
    ('entity_id', INT), ('entity_category', TEXT),
    ('entity_path', VARCHAR), ('entity_meta', CHAR),
    ('description', TEXT), ('entity_manifest_id', VARCHAR)
]

## Datascript Module Context
datascript_module = [
    ('entity_category', 'ENTITY CATEGORY',
        'What category best describes the Entity?'),
    ('entity_path', 'ENTITY PATH',
        'What is the path of the Entity?'),
    ('entity_meta', 'ENTITY META ACTION',
        'What meta-action is this folder permitted to perform?'),
    ('description', 'ENTITY DESCRIPTION',
        'How can you best describe this Entity?'),
    ('entity_manifest_id', 'ENTITY MANIFEST ID',
        'What is the Entity Manifest ID?')
]

## INCLUDE - Additional modules that were included
include_module = [
    ENTITY_PARSE_COMPLEX.py
]

About .ds to .entity pairings

Compliant EntityScript™ files have each of the following sections, but .entity files also may be extended to the index information provided in a seperate file of any structure (.csv, .json, etc.) as long as the keys in INDEX match. ↓

EntityScript™ .entity meta-component specifications

These are the .entity file meta-components of an EntityScript™ file. Each of these represent a machine-significant string that is intended to be parsed at or prior to runtime.

Header information:

The header contains information about the dlist and creator. The creator key is valid if it is a 14-digit VCNKEY™ or a resolve-ready url is provided with information about the creator. This information is considered meta-data for the file.

KEY:

The default entity-key (as in id field name) representing a local-region identifier. Local-region identifiers are not globally unique, making them secondary to fully-resolved primary indexs provided by sites like core.host™.

datascript_id:

A datascript_id linker is used to associate linked indexes locally or purposely segmented sub-component structures into index-groups. These ids are usually the same as the 'KEY' but occasionally it will be broken apart into separate 'meta-KEY' sections to create contexual scope when enough entities are linked together. datascript_id can also be masked through obfuscation masking the primary-id index of a structure for privacy reasons.

title:

The human and machine readable title of the the .entity construct. The title holds no value outside of programmer or operator dependent context as all EntityScript™ information is parsed according to INDEX values and meta hierarchy of collective system scoping. However, a title can used for locally-unique, intranet-unique, or global-unique constructs for a given associated datascript file.

package_type:

The defined package_type that conforms to the OpenPackager™ distribution standard. The main and default package_type is an 'indexer' which will provide for basic key-value lookup options between .entity and .ds files. Because real-world humans are considered protected classes within EntityScript™, any real person is considered a "contact". Additionally, anything that is neither "real" or "data" is considered a "game". Think "game theory" not sports. Games are complex and unique in nature.

package_id:

This is the 14 digit hash chosen for the storage of the entity. Although 14 digits is standard it can be extended or reduced according to the needs of the user. When a .entity is bound to a system such as core.host™ the package_id is the posted public identifier, not the title. These "slugs" are where packages sit when being vetted and exchanged amongst peers.

DLIST:

The D-index List file or 'DLIST' is the 7-30 digit id number of the .entity template file that's created designed to store a datastructure of a provided type (.csv, .json, .xml, etc.). All 'DLIST' values are prepended by the reserved-key DS and will end with the default extension for a standard datascript-linked entity file, i.e. '.ds'.

INDEX:

A list of all available lookup-keys. These are able to be used in any programming language that parses key/value pairings.

identifier_type:

This is the list of tuples that provides human-readable or machine-context to your linked DLIST INDEX structure. The tuples each have two positions, the first being the lookup location and the second being the enforced policy of that location as a key. These enforcements take on standard data-scopes such as INTEGER, CHARACTER, VARIABLE CHARACTER making them compatible with databases of all types. identifier_type helps make .entity/.ds available for various traditional data-storage systems when needed or able to be used as an enforcer of data-type before commiting data to permanent storage. There are only strings and integer types in .entity and .ds files, but through using identifier_type, you can enforce more types before commiting that data to a database transaction.

datascript_module:

This is the list of tuples that provides human-readable or machine-context to each identifier_type other than the primary ID key. These list-items are meant to be readable by an LLM and able to be activated by local-first agent tasks as a result. Each tuple has 3 positions only. The first is the lookup-key, followed by the lookup-key label (displayed in a graphical interface), and the third is a help question (LLM-contextual provider) to allow a quick overview/understanding of the lookup key datastructure. The stronger and more concise your datascript module descriptions, the better an LLM will be able to make use of the structure for automation tasks.

include_module:

Here you're able to associate multiple other datascript_id sections or linked program runtimes to the file. Include modules present secondary branches and are considered descendants of the package_id. You're able to add a variety of programmer defined extensions.

EntityScript™ Escape Codes

Each `protected` EntityScript™ string can be swapped at the character level in the file itself using the following convention as a manual or program-driven override