Keys
Keys are preset activation instances that fork the program behavior into different sub-routines. When a valid-key is discovered by the program parser, additional functionality is granted to the user.
EntityScript™ Keys are both pre-built and user-defined
The following Keys may be used to access various parts of the system:
| DS |
access-key |
Use DS before any file to make it discoverable to the datascript_id module |
| LL |
access-key |
standard connector objects that archive locations and endpoints to descriptive or qualitative text |
| LLB |
access-key |
standard media retrieval mechanisms that are able to be discovered and processed by the BrowseMeh™ |
| PK |
access-key |
Access a Personal Key |
| |_| |
filter |
Mark a location for filtering |
| XA_ |
storage |
a compliant storage structure but one that hasn't been certified as archive ready |
| XAA_ |
storage |
a compliant storage structure and also one that has been reviewed either by a machine or human and certified for sharing |
| ESE |
entityscript-meta |
retrieve, edit, and delete RING/ENTITY/ locations |
| ESO |
entityscript-meta |
retrieve, edit, and delete ORE/ locations |
| ESV |
entityscript-meta |
retrieve, edit, and delete VISUAL/ locations |
| AAA_ |
indexer-general |
topics and information that you didn't generate yourself |
| RRR_ |
indexer-recovery |
process old, past, incomplete, or broken archives |
| VIN |
input-voice |
link to CORE.VIN audio command center (Voice Instruction Notation) |
| z_ |
index-alert |
unspecified contents that have been alerted as ready for deletion |
| ZZZ_ |
index-alert |
unspecified contents location |
To summarize the above table, there are 7 default key-types and 15 behavioral modification-keys:
More about key-types:
access_key: DS standards for discoverable source, though the file itself is a file-system agnostic container housed in something called a "datascript" container. access-key types can be set as discoverable components by C.ORE™ that have taken on a program-wide default context.
entityscript-meta: When you need to provide access to another system-resource, you do this by default through EntityScript™ scoped processes. For this reason, if you're accessing network locations or interacting with machine-code, you will define an entityscript-meta location that starts with ES and then includes a context variable. The default contexts are E (ENTITY) O (ORE), and V (VISUAL). EOV locations allow any stateful machine to take on a human-context covering a defined instance type, a specific data-silo to operate on, and a visual component to display it to the user. Note that for those with visual impairments another type is made available through the input-voice modules that backs up to sound-based I/O.
filter: When you want to make sure certain machine-behavior can't reach or modify the kernel, you can put it behind a defined filter module. For instance, a browsers download folder could be directed to a filtered location that then containerizes each new file by default. They then can be vetted more, stripped of execution permissions, and more.
index-alert: Can be used when there are no known locations for the housed content. This content is to be thought of as raw data and a ZZZ_ modifier will treat any housed data as untrusted.
indexer-general: When you have something that you want to store but it wasn't created by you, you can define this type of data-silo with a general index, which will consider the data itself unowned but discoverable.
input_voice: take data-types that are sound related and convert them into another type of context. This type of module also does sound outputs as well.
storage: when you've generated something by yourself, such as writing, photos, ideas, data-points, documents, or more that you want to give 1st order priority too in the system, you use this location type. XA_ is used by default to signify a general yet compliant stored structure. From there, you can extended with addition keys such as XAA_ XAB_ ... XAA0_ XAA1_ ... XAAC48 etc. Each will lag in priority of an XAA_ instance, and XA_ instances will be appended to the end of the XAA* stack.
There will eventually be a much more detailed usage page available. Extra features and additional resources will be posted here: How-to
