here i use the term exclusion rules, which means: within any single branch, you can only tag at one, fixed depth level. you can tag siblings, because those are roots of two different branches. you can tag different depths on sibling branches because those are not on one single branch. really it’s just one rule, one canonical rule with a couple derived rules.

I also interchangeably use functor and relationship. ENTS is designed to work with two different things of two different categories: files and nestable tags. using category theory terminology, a functor is a relationship between two different things of different categories. so here we are dealing with file-tag functors. colloquially, here i use “relationship” to refer to a file-tag functor.

here i use file group to mean all the files in a folder and all the files in any nested subfolders.

the normal tag is going to have soft enforcement for the exclusion rules. to follow these rules (non-strictly), there has to be one functor called the principal functor, and there can only be one of these. when the enforcement is broken with additional functors, these will be additional associated functor/ies. the user has to use the --force flag to break the exclusion rules and create an associated functor (done to encourage the user to keep files to tags at a fixed level and keep a clean tagspace). Principal and associated functors are explicit functors, because the user has to tell the computer explicitly that there is a functor. when doing filtering for a parent tag, if an explicit functor is a child tag of the tag being filtered for, than these show up as implicit relationships. if the user uses the --explicit flag, implicit relationships don’t show up. if the user uses the --principal or --fixed-depth flags, than only the principal functors show up. if the user uses the --associated flag, than only the associated functors show up.

there are a couple body-diagonal cases (this borrows from the “edge case” and “corner case” analogy from a cube. a body-diagonal case is not quite an edge case because it is more frequent and it is in the thing, but it is not the whole design thing) that need to be considered. these two are closely related. they can likely be done with flags - to promote an associated functor to the principal functor. this entails to destroy the old principal functor and promote the targeted associated one to the principal. --promote - how to swap principle and associated functors. when someone already has an associated functor from file to tag but they want to turn that one into the principle one and make the old principle one an associated one. --swap

these two are also closely related. when forcing a functor, when it requires force, is that to move the principal functor, or to create an associated functor?

i am going to get rid of the “exception” tag. if you want one file to have a relationship that breaks the exclusion rules, you shouldn’t have to edit the schema that governs relationships for all the files in the file group. changing the tag type between - and * in the old ENTS specification is if you want the file/tag relationships to have either the exclusion rules or exceptions to them for all the files, but i can’t imagine a scenario where someone would want the exclusion rule to be broken for all the files in a bundle. dropping a tag type and introducing new relationship types is more purist and keeps the focus of the program to making file-tag relationships. this change was catalyzed by considering multi-user tag schemas where one user might want to make an exception to the exclusion rules. they could go in to change a - to a *, and messing up how it looks visually for everyone else using the schema and creating potential for their relationships to get screwed up. these changes get rid of that problem and make much more usable multi-user schemas. no more unexpected filter results because someone changed a tag type and you ran tagging commands without you being aware of that. it gets rid of the “why did you change the tag type? change it back!” dialogues.

matrixes

ents also naturally lends itself to matrix construction as well. one possible syntax is this choice. when tagging a file with a matrix, the user would be enforced to tag with one element from each of the vectors in it.

[[A, B, C][1, 2, 3][X, Y, Z]]

another one would be use dud tags, which naturally could lend themselves to matrix construction. I am thinking of adding a hedger symbol (possibly ^) to indicate “to tag with something from this dud tag, you have to also tag it with these linked dud tags at the same time”, with the added scheming enforcement that they have to be next to eachother in the schema to go together. that, or, i reserve a different symbol for that function entirely. or, i just make it so you have to use the array notation. something like

^+ author
    - hunter s thompson (hst)
    - alan ginsberg
^+ state
    - california
    - new york 
    - other

which would be pretty necessary for a project like a literary overview of the 1960s, because both authors wrote extensively in both states.

permissions

in a multi-user ENTS file group, there can be permissions levels of whether to move the principal functor. happily, this can be denoted by ENTS itself.

using the considered hedged duds syntax in perms.ents

^+ functors
    - principal 
    - associated
^+ perms
    - create destroy move
    - suggest
^+ users
    - alice
    - bob
    - charlie