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™

EntityScript™ Overview



Release Program Title: EntityScript™

Copyright: New Entity Operations Inc.


Purpose: Add a functional data-to-machine program to the system of your choice with EntityScript™. Interact with CORE.HOST™ related programs.

Extensions: https://CORE.HOST/


Background:

EntityScript™ provides a data-to-machine interface for operators working on a concept system called C.ORE™ (COGNITIVE ORE™).

This concept interface acts as the structural authority to a machine's visual user-space by processing system-level data and providing extensions to end users. This user-space control methodology has to do with accessing and processing personal data of various types. These types usually can be defined and processed using various techniques made available by EntityScript™

Implemented techniques are ultimately processed by a kernel program of some sort and various system-dependent implementation languages to handle scripting. This language acts as a control center for keeping your machine data and formats enforced through 1 access control program. This access control program also controls various parts of a host system and makes and provides ways to extend that systems functionality both in text and visual modes.

C.ORE™ was built to interact with the memoryform™ application program that ties kernel and user-space together into an audit driven complete system-UI capable of handling many different operations based computer functions on behalf of the end user. EntityScript™ gives end users of these new kinds of systems ways to interact and control them in a way that is fully transparent and open source.

Interface programs like the one presented in C.ORE™ can sit on top of a windowing system of some sort or some other type of custom machine-to-visual space implementation. In this specific type of program, as long as you can get to user space and run Python 3.8, you'll be able to run this tool-chain in the minimal mode. The minimal mode is text based, while the advanced modes include graphical components.

For many years the Interface of a computer has been a mystery because of how hard it is to track what happens with each type of input interaction. With EntityScript™ we can get a handle on most of those mysteries and give the end user a way to automate many types of tasks or dive into the current workings of their computer.

We decided to virtualize this interface so you could have one program to technically handle all input related tasks in a way that was safe for a machine with a finite amount of host resources to run in various sensitive situations.

While designing EntityScript™, eliminating the need for host machine dependencies was essential. The goal is to give one tool to cut out the need for multiple other types of packages currently in use. EntityScript™ provides the operator with more add-ons through a pure module approach, following conventions to extensions and operations of varoius types.

Auditing these routines and packages easily was also essential in this format. A way to create your own routines is available and there are also ways to access the community on CORE.HOST. When the operator creates a convention according to this format, it will be able to be shared, found, and installed by others easily.

The C.ORE™ program helps you organize large quantities of both structured and raw data types of unknown origin or to clean up past systems. Afterwards, the system is correctly 'metatized' and these new attributes can more easily be recalled at a later date according to setup routines. In EntityScript™, you'll do a lot of routine building with community defined formats and extensions hosted on the CORE.HOST™ platform. These formats and extensions can be utilized in both static and automated scripts. Scripts are made available by categories. These categories allow you to find routines for your own data and implement them quickly. The community website is setup to help you build, enforce, and discover system-linked data later.

Sometimes you'll use the tooling to build your own entities, or connect provided formats into various legacy data structures. EntityScript™ is loosely defined yet there are exact conventions to creating new entities. All of these rules are clearly defined and eventually the person using them will have little trouble creating them quickly in a manual way or using automated tools that are provided.

EntityScript™ is the next thing in enabling and extending "Operator driven computing". This is a new type of computing where the machine has less base functions and more abilities to build in original or community generated routines using simple interfaces. The original goal of this project was to develop 1 and only 1 system interface to sit on top of any kernel as long as it had the basic supported language able to run. Today, that supported implementation language is Python (www.python.org). It was chosen as the build and extension language for many reasons but mainly because of how widely supported it has become and how strong the language scope is. You don't need to know the implementation language to use EntityScript™. However, if you do, you're able to mod the entire program in various ways that other users couldn't.

The implementation language may always change in the future, but the principles needed to endure over a variety of strict criteria made Python the best initial choice. A small version of everything runs in C but that build is experimental and there isn't any intent to make that version public.

Data that's structured and trackable in a variety of modern formats from text-search to voice-control became essential to meet the demands of the future generation and EntityScript™ supports both of these types. Also, a high degree of customization for this overall operations format was essential as well. EntityScript™ is an attempt to summarize all of these essential parts into one interchangeable middle-layer resource.

The featured library, scripts, and information featured here help assist humans in defining exact output formats that utilize this "known always" philosophy to file systems. These "known always" formats can be of both traditional or experimental in practice formats with EntityScript™, but they have to yield to a structured and reusable end result with common elements to be consider valid. A valid EntityScript™ file will be both able to be run and also become discoverable within the C.ORE™ application.


Secondary Purpose: C.ORE™ can be extended to replace most basic system functions through a virtualized I/O interface that helps map and protect personal information on stateful computer systems.


How to use:

A C.ORE™ operator can collect information from many public or private sources in any format they would like. Once it's collected, if the information is extensible and previously defined through a New Entity File (or .entity file), it can be stored according to that format and made re-discoverable to your system. If there is no previous definition, a new definition can be implemented and enforced by the underlying code by creating a new .entity file and relationship code. This means that you'll easily be able to utilize a variety of meta-structures that you define that will help you with future information recall. This information recall can also be implemented by various predefined data-points made available by the program. The goal is to be able to reuse these data points as blueprints for future processing as much as possible. Ideally, nothing on a HOST machine would ever be able to not be instantly recalled, mapped, edited, or removed. That goes for packages, scripts, components, templates, etc. The only thing that should ever need to exist is the underlying kernel code and the program itself which is entirely open source. So, using EntityScript™ will require making those two environments as separate as possible. A good way to do that is by starting with a fresh distribution installation of your choice operating system.

Information sources include media and static content from a variety of legacy and modern file formats. These formats are made up of structures holding an exact type. Even structures that are anti-patterns of various kinds can also be made to be discoverable as well. With C.ORE™ you're able to replace the need for any third party or closed source tools to get these interface options available. To make the data summary/recall processes complete, you can use EntityScript™. This originally was known internally as the IPDVC™ (Internal Processing and Deployment, Vetting-system, and Creator). The aim in using the software was to get various data types to conform to a access control schema chosen by the operator. This ends up being enforced by lower-level kernel code within your machine and the program itself. This process unfolds with a similar tag based approach and can be extended with EntityScript™. This enables internal tracking and policy-based enforcement on the system. You're able to take these past information types as inputs from various structures (currently there are 104 finalized) and restructure them into a variety of both trackable and loosely defined (yet exact in methodology/form) recall structures. These structures will be available at https://CORE.HOST/entity/ and are either provided by the system or generated and distributed by the community.


Some closing introduction thoughts:

When information goes into C.ORE™ it can be configured to be logged and later accessed in various ways. These information types can then be stored locally, in local system groups, or publicly by being published to the central repository on https://CORE.HOST/community/. In short, you're creating the context and then defining how that information is recalled later and making it available as a category. The information can be recalled according to various methods, either ad-hoc or strictly tracked by your machine through logging. Further, for important user-space methods and security enforcement, an entire alert tagging and tracking system also exists within the program to help with future event tracing that can be used by EntityScript™. In summary, EntityScript™ helps you with user-space auditing and key system functionality.

Any information you come up with at some point in the future should have an equal and opposite .entity file to store that information with safely and accessibly for the future.

In C.ORE™ you're able to sort and inspect this set of interactions deeply and with various intents. The information that ends up coming in and being stored on your virtual interface can adhere to both on prem or cloud-first models. EntityScript™ is built to interact with both.

Lastly, the resulting .entity/.ds format simply called "EntityScript to Data Sheet" can be stored, customized, and accessed at a later time too according to a set of structured yet flexible storage of last resort methods. These methods can be published without revealing format-specific information using various templating techniques provided by the program.

Omission Schedule

* at the start of a line means a single release related detail will follow. No * at the end of the line or area means it's not a site que yielding any specific information other than what's described. There are more expansive details, such as 'RUN/START COMMAND COMMING IN Version X'. There are two others: 'DETAILS coming Version X' to say that the details of what is being talked about in the omitted text will be there in a specific Version mentioned or not at all depending on what's decided, and 'commands coming with Version X' to signify general common types of omissions related to in use commands. These commands are covered more next.

* at the start of an area followed by a * yielding one of the conventions from above will show that those omissions mean that. This will only occur when the whole omission area matches the convention. In most instances an omission is there because the status of that part in the next Version is still in question or in the process of changing.

*** anywhere means something has been omitted for an unspecified reason.

***** anywhere means something has been partially removed for an unspecified reason.


Summary of Goals: Take any legacy file format that contains information and convert it into a dynamic and instantly accessible data portal through the EntityScript™ file-recall and operations format. Provide functional computer services with software.


To learn more about the .entity/.ds format, proceed to the next section .entity/.ds Lookups

To read more about the technical specifications of the system, see the section Technical Specifications and Extended Library Features.