EntityScript

Draft 1.01:
Index







Sections: Status -> Approved

1.) EntityScript™ Overview - Overview of the project

2.) .entity/.ds Lookups - Overview of basic .entity and .ds file relationships. An overview of each file.

3.) Special File Types - Overview of special types of methods, files, and types in C.ORE™

4.) Log File Types - Overview of Logging within C.ORE™

5.) Using OpenPackager™ - Overview of the OpenPackager™ project and details regarding using the sub-system for organizing the base system and addons.

6.) Locations - Overview of various parts of the IPDVC™ file system

7.) System Audits - Overview of various audit mechanisms present in C.ORE™ and how to use them.

8.) C.ORE™ Scripts - Overview of scripts that run in C.ORE™, the purpose they have, overview of some scripting philosophy, and some usage examples.

9.) Startup - Step-by-step process of startup routines and how to extend them

10.) C.ORE™: AirEP™ file system (Access Identity Ring Entertainment Platform: AirEP™ - Understand more about the Access, Identity, Ring

11.) Keys: Each of the built-in keys that can be used to retrieve meta-information in C.ORE™

12.) How-to: Additional Notes

13.) Moderation: Basic moderation principles

14.) Social Pledge: Basic social-pledge for your interface and who you interact with

15.) Disclaimers: Basic recommendations for your interface and dealing with various types of commerce

16.) Additional Resources: Dig deeper into the technical stack, program methods, variables, and other happenings within CORE.HOST™

OpenPackager™



OPENPACKAGER™ - Tie real and fictitious entities to context modules that utilize the .entity to .ds relationship.

Using OpenPackager™

A variety of different environment choices can be made within your system but it's important they all conform to some higher standard of system security. These practices can be enhanced by additional middle-layer control packages that enforce certain behavior at the kernel level. OpenPackager™ extends these into a clear user-space package framework an is capable of being extended with meta-classes and other similar structures.

To search for, retrieve, install, and manage external packages your system may use your own distributed and controlled branch locations. It can also use those locations to retrieve system level packages. CORE.HOST™ was designed specifically to distribute and provide access to OpenPackager™ compliant entities. More programming languages can be used besides the one chosen to implement EntityScript™ but they'll be expected to various established conventions.

When distributing packages, the operator takes responsibility about how this software interacts with both the graphical system and the underlying sub-system code which will reach as far as the kernel itself. The sub-system takes you all the way into the metal through software and OpenPackager™ makes sure some basic details are in line before it'll allow your system to allow for that kind of control.

The following conventions for OpenPackager™ are relevant to this methodology:

Location: .CORE/OPENPACKAGER/

There are two preset environments for this convention. The first is corehost and the second is external

.CORE/OPENPACKAGER/corehost provides internally developed addons

.CORE/OPENPACKAGER/external provides externally sourced or collected addons with a preset that's set to 'WILD'. Anything 'WILD' is sand-boxed.

Whenever programs in these locations make system calls, they should also have some sort of logging mechanism attached.

These locations can be used by other programs of various types and also kept so they're only able to access certain or exactly supplied resources. You then can extend these locations usage and the way they allow certain behavior by altering enforcement mechanisms in place elsewhere within C.ORE™. See core_interface to learn more about extending system level functionality.

These locations link to the RING and the RING enforces what programs can and can't do. The same would apply for distributing or redistributing these types of files as well. You define the program behavior and the logging verbosity, and determine how to tie them into the RING properly. To summarize, the RING will control various parts of ENTITYSCRIPT™ contexts for accessing system resources within C.ORE™. The RING will also determine if those resources can carry anything towards the network for sharing or not. What people share on CORE.HOST™ is .entity files.

All .entity files will be stored according to the following conventions:

Collected software: additional items of interest that can be run as a system extension within the IPDVC™.

All .entity files are the root context provider to a package. Each type of traditional system can be extended with these packages and made into entity-extension systems. Systems that start enabled for this behavior are called entity-centric systems. These entity-* systems are sourced either locally or are made available globally. The default handlers for these files are written in Python. Python helps the middle-layer system calls as OpenPackager™ functions. Python is used as the implementation layer for the underlying system services in OpenPackager™ but it doesn't make others rely on it or any specific language. System services utilize the Access Identity Ring (AIR) platform can be used as acceptable additional system constructs.

The .ds data sheet file type takes on comma separated cell usage, with constant quotes and headings enforced. Or it takes a general 'blob' format. There are index and key-based rows and traditional column-based lookups available if you extend the base system using core_gather. core_gather can be used to tie in and search for customized package formats as well. A .entity file defines the title, the middle-layer package index headers for the corresponding .ds files, and any additional modifications or add-on file extensions. That's it.

OPENPACKAGER™: Extensions

Right now, the only supported external extensions are:

Jupyter Notebook https://jupyter.org

The notebook should be accessed through a separate virtual environment and through a standardized https only approach. This requires some additional setup. Follow the following convention of placing the notebook system in a unique and separate ORE file elsewhere before you begin.

pandas https://pandas.pydata.org/

core_gather utilizes pandas when the operator chooses to do so. It makes things much more capable on the data science and framing end. Check out the project.


OpenPackager™ Entity Creator Questions

You can run the core_creator like this:

>>> core_creator.entity_options.entity_form()

This will return an interactive prompt that can be used for .entity creation and setup functions. There is also a graphical interface feature, but the default is just a plain text adding system if chosen.

Entity Creator Questions:



Would you like to add a New Entity? : 1 for Yes - 0 for No 1

Would you like to automate this process? : 1 for Yes - 0 for No 0

Would you like to automate this process? : a for Alias - b for Entity (Context) - c for Figments - d for Human - e for Location d

What type of Human are you adding? A for Contact - B for Fictitious - C for Person c

What is the name of the datasheet? DS{7^#} DS7746875

What is the datasheet key? X_uid (replace X) and single quote'X_uid 'fuuid'

What is title of the Datasheet? Follows standard entity naming conventions. Fun People

What is the type of the package? indexer, contact, or game? indexer

What is the unique package id? {14^#LR} CVF67I89MJ4EA

What is the index of this entity? This is a Dict of keys [] "id","fuuid","fun-name"

What Types are being used by this entity? Dict of Tuples [('ID', INT), ('CUID', CHAR)]
("id", INT), ("fuuid", CHAR), ("fun-name", VARCHAR)

What is the mapped datascript module context? Dict of Tuples [(),()] ("fun-name", "FUN PERSON NAME", "Who is this fun person?")

What modules will you be including? Dict of Tuples [(),()] ('DS1827293.ds', IMPORT_BY_LINKER('
DS1827293.linker'))

Note*: If everything worked you'll see the following message, or something similar in structure:

The following file was entity was generated and now resides in /DS7746875.entity

Now that this .entity exists, it's index and meta information can be called by performing a lookup to the file.

There are 5 starting types of Entities to create. These entity types are: Alias, Entity (Standard Context-index), Figments, Humans, Locations

All 5 of these types can either be a indexer, a contact, or a game. They all have different extensible features attached depending on what is chosen. Some are static while others have time-based parts.


.entity file example

# DS7746875.ds - KEY::: 'fuuid'

# Entity Snapshot
datascript_id = ['fuuid']
title = ['Fun People']

# Package Snapshot
package_type = ['indexer']
package_id = ['CVF67I89MJ4EA']

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

# Index-List
INDEX = ["id", "fuuid", "fun-name"]

# Identifier Overview
identifier_type = [
("id", INT), ("fuuid", CHAR), ("fun-name", VARCHAR)
]

# Datascript Module Context
datascript_module = [
("fun-name", "FUN PERSON NAME", "Who is this fun person?")
]

# INCLUDE - Additional modules that were included
include_module = [
('DS1827293.ds',
IMPORT_BY_LINKER(
'DS1827293.linker'))
]


The previous statement will be human and machine readable in C.ORE™ and provides a variety of meta-linking attributes.


Additional vocab that may be used in the documentation (Partial-list: Full list with version 1.1)

Known Defense Schema

A file system where the position of the files and the duties they have remain known by designating and keeping set keys for various meta-functions.

This happens while the security measures to obscure these files and their byte size remain hidden to other system programs and the operator unless they're accessed though specific program specific safe-lookups.

A Known Defense Schema is built to be compliant with various authorities and also provide ways of hiding data from unauthorized operators.

Protected EntityScript™ words: Strings that require an escape of ###/(YOUR_ESCAPE_HERE)

These escapes can be used inside of a .entity file so that it can display machine-significant keys in human readable context locations. An example would be if you tried to use a protected word in the 'datascript_module' section it would throw a silent error, although no alert is made. Upon an automated check these errors can become discoverable and are able to be fixed by replacing the protected words with the replacement text.

These protected strings are not able to be used outside of the default positions in .entity files only. If they represent a collision in the protected key section, a silent error is thrown and only discoverable upon a system-based check of each file.


Publishing to CORE.HOST™


https://CORE.HOST can be published to if you have a VCNKEY™. A VCNKEY™ is a authentication device used for posting according to a specific EntityScript™ defined block-storage format. Although CORE.HOST™ is featured, many other types of block-storage systems may be accessed or used as an extended drop zone if they follow this exact convention for entities.

Also, default stores of value can be made general through the following standardized exchange format. These units have no defined value but adhere to a defined system.

The system has 5 properties: 1.) ItemVisualIdentity 2.) UnitName 3.) ByRarity 4.) ConversionMap 5.) CoreUnitDescription

In testing, the following table was defined and is accessible within core_transmitter as the example framework. It includes server-time based standardized unit distributions to members, and a mechanism for reclaiming unposted Unit transactions. These scripts can be built on and altered to define units and values of your choice. You define by Rarity, function, time, and purpose.

The default theory peg is "DGOLD-X" a mock digital store of value to use during testing.



IdentityItemVisual UnitName ByRarity ConversionMap CoreUnitDescription
BRONZE CORE DGOLD-X-Bronze Common 250,000 Distributed Daily, no base value - 1/40,000 a DGOLD-X DGOLD-X-Bronze can be exchanged into the server each day to keep your network ad-free, permanently. You get Bronze each morning at 00.01 server time. If you don't exchange it or only exchange part of it to peers, the machine reclaims what's left at the end of every day and the DGOLD-X-Bronze goes into a collective server-holding account. When there is 400,000,000 DGOLD-X-Bronze there, it forks over the span of 24 hours known as 'THE AUDIT PERIOD' and at the end, 1 Diamond C.ORE™ is created and made available to the community according to a giveaway-game format. 1 Silver is worth 20,000 DGOLD-X-bronze.
SILVER CORE DGOLD-X-Silver Uncommon, achieved 1/2 of a DGOLD-X DGOLD-X-Silver units are used to aggregate tasks into value groups, and reward completed actions of various types. They're allotted once per day, 20,000 to be exact. They're only able to be spent on unlocking certain additional meta-structures within the program.
VIRTUAL VirtualFigment™ Special Object (Periodic) AWARDED FOR COMPLETING THE TUTORIAL - grants 1 VirtualFigment™ struct-entity that can be used for publishing content to peers. You have to earn the right to post by completing and continuing to understand a community guidelines rule-set.
GOLD CORE DGOLD-X Rare: Upgraded to -> 'HIGH EXCHANGE' type Earned through various defined behavior This is the basic system-crypt-peg within C.ORE™. All other units operate based off of it.
DIAMOND CORE Diamond C.ORE™ MINTED: VERY RARE Prestige When the CommunityCollection reaches 400,000,000 bronze, 1 Diamond C.ORE™ is created and made available to the community. A Diamond C.ORE™ can be used to unlock general chat structures and various long term meta-methods. No one can speak in general until they've discovered at least 1 Diamond C.ORE™. MAX 1 per day. Anyone who has discovered a Diamond CORE™ may also give away an established set of chat invitations monthly afterwards to peers.
GEM CORE Gem C.ORE™ GEM Special Object: Awarded Gems are awarded to you for community building and assistance. They're based on internal nominations. They hold no value, but are required to be above rank 30 in the system. Above rank 30 provides additional meta-structures.
THE LAST KNOWN CORE Mystery C.ORE™ Unseen Estimated Exchange: 4,000 DGOLD-X Somewhere around the year 2020, a machine known as C.ORE™ came online and began indexing information differently than before. The mystery core is still unknown but it's rumored to have various meta-structuring properties granted with the discovery of this type. In the archives it simply states - "The mystery C.ORE™ was best left undocumented, and better left discovered".

When any resource is made available to exchange types, it's also recorded on three sub-tables. Here is an example of what each of the 3 look like.

1.) Value-table, general:



Domains C.ORE™ Gold Silver Bronze Diamond Gem Mystery
333300030000132

2.) Public Domains accepting ORE™:



domain times seen
https://ryanmckenna.com2
https://NewEntityOperations.com23

3.) Private Domains accepting ORE™:



domain owner last public
MASKEDMASKEDAugust 28 2020
MASKEDMASKEDAugust 27 2019

Together, this type of system creates value exchange options in C.ORE™. 'ORE' is the default exchange type. It stands for Operations Resource Enclave and ORE has significant properties in EntityScript™. ORE™ provides a way to exchange meta-information of various types in this format.

The following set of publishing tools makes up the entirety of this posting, editing, and removal system. core_url and core_transmitter work together to format these requests on the fly, including validation according to the below format details.


Block device ledger: Standard .entity retrieval mechanism from an ordered and compliant index



position index-slug vcnkey ore-access master-copy record-location
1 LINKED_OBJECT_1 KHN3LPHN57H89L 1 DGOLD-X-Bronze ORE KHN3LPHN57H89L/DS3927107.entity RECORD
N* LINKED_OBJECT_N ULPH73L9BYNB3R 1 DGOLD-X-Bronze ORE ULPH73L9BYNB3R/DS7204432.entity RECORD

'index-slug' is setup to also take keys. Keys are created by others in C.ORE™ or adhere to a prebuilt kind. For instance, 'L:' at the beginning of index-slug declares a readable and compliant list location.

'index-slug' can also be either openly named, or masked through a special property called 'MASKED ENTITY'. When a masked-entity is created the default master-copy location is 'MASKED RECORD', while the default 'record-location' value will be set to 'UNAVAILABLE RECORD'.

Each of these aren't set up to follow to any specific position in this example, but while live, three distinct locations become available once activated. The first is a 'index-slug' location, storing the resource location of the LINKED_OBJECT. The second linked-to position is the 'master-copy'. A master-copy is a direct link to the stored location on a compliant block-exchange structure. Lastly, the 'record-location' provides a unified resource point that stores meta-data about the linked-entity.

Together, these actions will eventually store the meta-information on a ledger and become an available resource.

FinalLedger



position index-slug vcnkey ore master-copy record-location
1 data_sheet_b NK3hPHNsLpHHHa 1 DGOLD-X-Bronze ORE NK3hPHNsLpHHHa/DS3927107.entity RECORD
2 threed_Entity_unique yNXLPHa390HanP - yNXLPHa390HanP/DS7964744.entity RECORD
3 MASKED ENTITY AHnsLPyaH3a9PN - MASKED RECORD RECORD UNAVAILABLE
4 MASKED ENTITY BLPa2HnnLP210N - MASKED RECORD RECORD UNAVAILABLE
5 L:OriginalUSPresidents iPhs29Lna21qfp - iPhs29Lna21qfp/DS1000022.entity RECORD

With these ledger types now available, records can be determined 'ONLINE' or 'OFF' making them either discoverable to those with resource access or they'll be not available if they're 'OFF'. Next, the default record values of each entry will generate into a posted and compliant block-storage structure according to this format. Here is a look at the default record-store.

Example:


C.ORE™ Record - DS3927107



Creator affiliated-tag time-stamp master-copy Entity vcnkey type ore extension
Ryan McKenna RyanMcKenna 08/23/2029 - 06:34:55.3332 PST NK3hPHNsLpHHHa/{}/DS/3927107.entity data_sheet_b NK3hPHNsLpHHHa struct-entity 1 Bronze ORE .ds

FinalIndex: General mass-access location


A final index is now made available. Here is an entire FinalIndex example.


C.ORE™ - FinalIndex



Entity type index-slug vcnkey level ore extension status
Actor List struct-entity data_sheet_b NK3hPHNsLpHHHa protected 1 DGOLD-X-Bronze ORE .ds ONLINE
Basic Square 3D ASSET threed_Entity_unique yNXLPHa390HanP open - .entity3d expired
MASKED PRIVATE AHnsLPyaH3a9PN open 42 DGOLD-X-Silver ORE . ONLINE
MASKED PRIVATE BLPa2HnnLP210N open 2 DGOLD-X-Silver ORE . ONLINE
US Presidents struct-entity L:OriginalUSPresidents iPhs29Lna21qfp compiled 1 DGOLD-X-Bronze ORE .ds ONLINE

To summarize, OpenPackager™ gives the operator various forms of open information exchange formats to utilize for various tasks, from packaging to meta-information, to transaction methods.


To see an extended list of special locations in C.ORE™, click HERE