EntityScript™ compliant files can be designed manually or by using the automated .entity generated provided by core_creator. These are the required meta-components of the New Entity™ file specification. These files are case-sensitive and there are protected words in certain defined situations.
Default EntityScript™ .entity meta-component index
These are the .entity file meta-components: Each of these represent a machine-significant string inside of the core_gather CORE.HOST™ system.
KEY : The default entity-key that should represent a regional identifier, made secondary to the primary index-key.
datascript_id : The default datascript_id-key used to associate linked or purposely segmented items into index-groups. This is usually the same as the 'KEY' but occasionally it will be broken apart into separate 'meta-KEY' sections.
title : The human and machine readable title. The title holds no value outside of programmer or operator dependent context. These can be locally-unique, intranet-unique, or global-unique 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.
package_id : This is the 14 digit hash chosen for the storage of the entity, and if it's posted publicly, the "slug" where the package will sit within CORE.HOST
DLIST : The D-index List file or 'DLIST' is the 7-30 digit id number of the .entity template file that's created. All 'DLIST' values are prepended by the reserved-key DS and will end with the default for a standard datascript-linked entity '.ds'.
INDEX : A list of all available lookup-keys.
identifier_type : This is the list of tuples that provides human-readable or machine-context to your linked DLIST structure. The tuples each have two positions, the first being the lookup location and the second being enforced policy of that location as a format, such as INTEGER, CHARACTER, VARIABLE CHARACTER. This section helps make .entity/.ds available for various other traditional databases when needed. There are only strings and integer types in .entity and .ds files.
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. 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 to allow a quick overview/understanding of the lookup key with the originally intended context.
include_module : Here you're able to associate multiple other datascript_id based files to datasheet information. You're able to add a variety of programmer defined extensions to your New Entity™ using allowed or correctly linked modules.
Default 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 override
|escape letter||from phrase||escape sequence|
ABOUT DS: .ds file type
Overview: datasheet is not datascript. datascript is the identifying prepender of a .entity/.ds file relationship represented as DS. 'datasheet' is the extension to a file that is referenced by this prepending DS key. DS is a discoverable key inside of EntityScript™. 'datasheet' only means a file containing information. Usage: Store the .entity/.ds relationship to safeguard data relationship by enforcing valid syntax.
Includes: .entity FILES, .ds FILES, AUTOMATED PROCESS GROUPS (APGs), STAGING DOCUMENTS, FIGMENTS, and various additional personal data media formats
Examples of STANDARDIZED parts: .entity/.ds are special formats, while wide-spread formats are considered standardized (.json/.csv/.txt)
Symbolic representation and licensing thoughts
Together, the .entity/.ds relationship represents a "DIGITAL ENTITY ASSET (DEA)". These files hold asset-oriented relationship descriptions, structures, and models that can be run in C.ORE™.
You can set them up manually or complete the setup of a .entity/.ds in the predefined program and asset bundler (PAB) provided in the core_creator module.
Some of the entities run on non-clean licenses that are for personal use only or are protected for various other reasons. Others are original content that's been licensed appropriately for reuse and sharing. Other entities will be created by you and not shared, containing your own information. Even with this being the case, some information structure types may still be unable to be shared or will be restricted by from sharing on CORE.HOST
These take down decisions are up to the operator and up to New Entity Operations Inc. When you create and share these files you'll have to make your own decisions as to any warranty about service and the data itself.
EntityScript™ also won't be able to allow certain licenses that require us to act in any specific way. If one of these licenses is linked or bundled in, depending on the situation it may need to be removed. As a rule of thumb, these systems and creative tools are best to work on an operator to operator basis without much restrictions outside of those general ground rules.
Don't allow any direct links to certain license types if you're trying to keep anything shared public. Various Public Domain Type licenses are also not allowed. Nothing against any of the licenses that fall into these silos, but it's more of a personal/community line that makes running the site possible.
If you have licensing concerns, re-branch a virtual machine and plop the code in there instead so it can work within a 'closed environment' during testing.
Sharing certain formats may be deemed a 'redistribution' and if the materials are sensitive, it could get you into trouble. Be mindful, this was created as a way to organize YOUR information not other peoples. Although there are use cases where that can happen too.
There is a rule of thumb: Anything you think may be unsafe to be shared to the public should remain a Personal Entity File (PEF) instead. This is one of two symbolic distinctions. The second is symbolically called a World Entity File (WEF) and should be thought of as public even when you're establishing some sort of access protection using passwords or keys.
You should ensure your machine has been isolated correctly before working on sensitive materials for work. The best way to do that is by installing C.ORE™ on a fresh installation. Even then, EntityScript™ is meant to provide resources to the operator, not act as the system of last resort for every situation. New Entity Operations Inc. and affiliated groups take no responsibility for these types of creative decisions that end up getting made or for the outcome of their use. It's recommended not to use public wi-fi while working on your own data either, but various mechanisms are present to mitigate some risk of these scenarios.
Non-production facing environments can be set up with other tools and software, but EntityScript™ is meant to be a personal software tool to provide a full range of utility first and foremost and can be treated as a full system program.
Each 'Virtual Entity Package' (symbolically called VEPs) will have a corresponding environment file/setup definition that's controlled by your operating system and implementation language of choice. The default programming language chosen for user-space modding in C.ORE™ is Python 3.8.
Many times, Entity files will also be tied into an explicitly linked C.ORE™ routine to provide functionality to the end user to help complete a variety of tasks. These links can be extended with core_settings, core_operations, and core_interface too.
System tools will need some initializing program to handle shell functions. One of these programs is required to run the default programming language and operate various shell commands.
Some programs that you build with EntityScript™ are system-level, meaning you should be careful when running them!
Some programs here are compiled from source or explicitly installed with a managed environment. Make sure you're familiar with whatever language you decide to use to extend the New Entity Framework™ provided here.
In most cases you'll extract the X_fullname.ARCHIVE_TYPE file into the RING/PROGRAMS/* directory depending on your platform. This stores activated programs that aren't yours. So if you're looking to develop an extension yourself, it doesn't go here. An extension isn't a program, it's a module made available to EntityScript™.
EntityScript™ modules that you own or have created will go in the .CORE/RING/ENTITY folders. If the module also includes the implementation language, it goes into the linked-module area .CORE/OPENPACKAGER/
Packages running in OpenPackager™ are in isolation by default. They use a system runner to execute bound by initializer and setup scripts. One method of extending is with .CORE/OPENPACKAGER/corehost or by providing various notebook functionality provided by other programs.
Environment variables will be linked to program setup files regardless of the implementation language in use. These linked types function either directly in the C.ORE™ program or through a OS shell interface program.
ABOUT ENTITY: .entity file type
This is an example .entity file
Note*: There is a standardized version of this same file that also includes a block_hash_id and a timestamp if a storage of record is required.
Please consult other readings on how these storage of record functions are processed. It may or may not meet your needs. They work best as single purpose data sheet storage containers with exactly 1 byte size attributes. Read-only pages are rendered from those. They can be be programmed with more functionality and extended too.
To see more about Special File Types, click HERE
To see more about Meta-relationships: Standard Types and Reserved Keys, click HERE