October 08, 2019

Static Websites Using AWS CDK, Cloudfront, & S3

Scope

This article is primarily scoped to the Ontology of the "Tag Graph". In it, the name of this method will be deconstructed, along with the methodology. There will be some treatment into why or the implications of design choices as well, but that will be limited to keep the scope focused on the Ontology. Emergent Properties or Gestalt resulting from the combination of multiple elements of this methodology will be given limited treatment, with future posts giving fuller treatments.

Deconstructing "Tag Graph"

A phrase can be treated as a series of tags in a one dimensional graph, which create the context for meaning.

Ordinally, the phrase "Tag Graph" can be read left to right, right to left, or from other combinations of ways. The progression of reading each word builds a context. The order (left to right/right to left) of read words, generates a graph of progressive contextual development.

Left to Right: Tag Graph Naming Convention

This sequence follows the English rules of Grammar for a phrase.

The object is "Convention": A practice or procedure widely observed in a group, especially to facilitate social interaction; a custom.

The prepositions are:

  • Tag
    • A keyword, term, or phrase associated with or assigned to data, media, and/or information enabling keyword-based classification; often used to categorize content.
  • Graph
    • a graph is a structure amounting to a set of objects in which some pairs of the objects are in some sense "related"
  • Naming
    • The process of giving names to things.

The vector can be used:

⟨Tag, Graph, Naming, Convention⟩

Subvectors can also be extracted:

⟨⟨Tag, Graph⟩, ⟨Naming, Convention⟩⟩⟩

Right to Left: Convention Naming Graph Tag

If one reads the phrase right to left, while applying the rules of grammar, a different meaning is built from the reversed phrase.

However, if one treats each word as a Tag, then the mix of Tags, can yield a set of derivative meanings, often related to the primary order of these tags. To stay on scope, this will be left as an exercise to the reader.

⟨Convention, Naming, Graph, Tag⟩

Constituent Parts

What makes a variable name? The rules of the Javascript language will be used as a primary example, with treatments for other languages.

Javascript allows the alphanumeric characters, _, & $ as valid characters to represent the names of variables (which include functions, classes, etc.). The variable name may not begin with a number. The regex for a valid name is /^[a-zA-Z_\$][a-zA-Z0-9_\$]*/.

Other programming languages may use other characters (e.g. Ruby utilizes @ to represent an instance variable) or not utilize some characters (e.g. $). Most modern programming languages allow alphanumeric characters & underscores _ to be used for variable or Type names.

Tag

A tag (T) is composed of a vector of tags or a word.

	T = ⟨T⟩
	
	T0...i = ⟨T0,...,Ti
	T = ⟨⟨Tag, Graph⟩, ⟨Naming, Convention⟩⟩
	

Underscores

A vector of _ characters have different meanings.

Single Underscore, _

The Tag Graph Naming Convention build on the single underscore naming convention. A single underscore represents a linkage of words into a single tag. This series reads from general to specific, where the instance type is the last segment, while the context are the beginning segments.

For example customer_id has the context being customer and the id being the instance type.

A leading single underscore, _, represents a function that returns the value represented by a Tag.

	`_` = f
	
	f(...) = OT
	
	customer = _customer()
	

If there are multiple segments, one can think of a series where each word is passed to the next word.

	my_customer_id
	T = ⟨my, customer, id⟩
	

Double Underscore, __

A double underscore, __, represents an arrow relation between Tags.

	R = {⟨T0, T1⟩,...,⟨Ti-1, Ti⟩}
	

A Set of Relations can be reduced into a single Relation.

	R0,i = {R0,1,...,Ri-1,i}
	

Where:

	R = T0__T1__T20_T21__T30__T31
	

Direction of __

The Tags are related from specific (i.e. instance) to general (i.e. context).

	Rispecific,igeneral
	

For example:

	a1__customer__active
	

Is a 1-dimensional array (instance) of customer that is of active context.

Considerations for specific to general ordering

When working with a value, the instance is the interface to the concept. As demonstrated with "Left to Right" & "Right to Left" deconstruction of the title, Order affects meaning & building of context. Order also has Temporal & Proximal characteristics.

Temporal reasons for specific to general ordering

If one models an agent reading the code at the rate of one Tag per cycle, the T0 is read & processed in 1 cycle & further context is built over subsequent cycles.

This requires the fewest number of cycles to model the type of instance & related local context.

Where n is the number of unique Tags in Scope S.

	S = (T0,...,Tn)
	

If the local programmatic scope is using a set of Tags with different instance types but the same contextual type:

	T0,0 ≠ T1,0
	... 
	T0,i-1 = T1,i-1
	T0,i = T1,i
	

the programmer can distinguish the different Tags inlog n time vs n time for Rigeneral, ispecific

If the local programmatic scope is using a set of Tags with the same instance type but different contextual types:

	T0,0 = T1,0
	... 
	T0,i-1 = T1,i-1
	T0,i ≠ T1,i
	

it would be n time to distinguish the ordering vs log n time for Rigeneral, ispecific

In this case, it would be faster log n to reverse the Tag reading from context to instance (right to left).

The effect is the programmer has quick access to the instance type, when reading the Tag forward, while having quick access to the context, when reading the Tag backward.

Proximal reasons for specific to general ordering

When setting a local variable from a Tag, the programmer can use the specific subTag, Tispecific as the local variable name.

This enables shorter local variable names, assuming local variable names are unique.

Tispecific is proximally closer to the beginning of the line or the operator token (=, <, >). Since Tispecific is proximally closer, the programmer is more likely to see Tispecific without having to scan across the line of code. Tispecific is more relevant to the runtime, as it expresses instance Types.

Open Ended Double Underscore __

An open ended __ is composed of a subset of the Tags connected to a general context.

The relation seen above can be reduced in either direction:

Setting a variable including Tispecific means the variable is an value of the instance type.

	T0__ = T0__T1__T20_T21__T30__T31
	

Setting a variable including

Tigeneral means the variable is an value tagged with the general type.

	__T30__T31 = T0__T1__T20_T21__T30__T31
	

Higher order Underscores

It is logically possible to have more than 2 underscores have additional meaning. While I have not encountered a situation where I used more than 2 underscores, it is worth the thought experiment to consider what more that 2 underscores could mean.

One could relate nth order of logic is the nunderscore

	norder = nunderscore - 1
	

Relating to 1st order logic (_) is an individual Tag. Relating to 2nd order logic (__) is a Vector of Tags. Relating to 3rd order logic (___) is a Vector of Vectors of Tags.

It becomes decreasingly practical to a human to use higher order underscores. One way to mitigate is to use a number representing order logic. For example a1_ could represent a 1 dimensional array, a3_ could represent 3 dimensional array.

Triple Underscore ___

If we treat 3 underscores as the combination of 1 & 2 underscores, we can model it as a factory of relations, which includes an array (___ball) and a dimension in a matrix (ball__red___cube__green).

	___ball
	ball__red__sally___cube__green__bob
	

As noted previously, more than 2 underscores are difficult for a human to interpret, so this usage will probably not be common.

Abbreviations

Abbreviations can be used for common types, programmatic, or mathematical notation.

a[0-9]+

a[0-9]+ represents an nth dimensional array.

For example a1__vehicle represents a 1 dimensional array of vehicles, while a2__vehicle represents a 2 dimensional array (array of arrays) of vehicles.

arr

arr represents a single dimensional array. arr can be join with additional arr to represent higher dimensional arrays. For example, arr__vehicle represent a 1 dimensional array of vehicles, while arr__arr__vehicle represents a 2 dimensional array (array of arrays) of vehicles.

ctx

ctx represents a context object holding data related to the following Tag context.

fn

fn represents a function. It is synonymous with a leading _, and used to explicitly mean a function in cases of ambiguity.

idx

idx represents an index, of type integer.

txt

txt represents text.