Dev log and notes

[hornc]

This is where I'll write the project logs...

[hornc]

First experiments in working out what this might be;

Using the CSV like GDF format for graphs because it is very lightweight.

Transferred the Keeler's plot diagram of his The Crilly Court Mystery into GDF format , taken from his essay on Web Work plot structure, p.10

Throwing this into Gephi, and using the "Ordered Graph Layout" plugin gave the following diagram:

It's a start ... of something.

I'm going to try and use Keeler's 15 elementary plot combinations from the same essay, and made a start transcribing them to various formats.

Plot combination II (p.49) looks like this:

A Fountain grammar to generate a vague description of what this represents and turns it into an AI prompt: https://github.com/hornc/nanogenmo2023-webwork/blob/96af155a3ad4db56596e415b1883679acdbcdeab/fountain/plot-II.fountain#L1-L10

And the results of pasting that into chat GPT 3.5:

https://github.com/hornc/nanogenmo2023-webwork/blob/96af155a3ad4db56596e415b1883679acdbcdeab/fountain/plot-II_chatGPT.txt#L1-L11

Hopefully I can make the prompt better to get a more themed and interesting story later... we'll see where this goes. I still want to focus on plot structure first. This was just an experiment to see how the basic parts might fit together.

Initial observations on Keeler's plot diagrams:

• Lots of background events have occurred before the story starts. Presumably the narrative has to be inserted as flashbacks when appropriate in the main story. I haven't located where Keeler addresses that, but it'll be fun to structure.
• There is one character, the hero, whose story line is thicker than the others. This character should not randomly die.
• Dead characters have a dotted plot line. Their corpse can be a factor in subsequent events. (I need a dead edge colour or style)
• Plot lines can be for people or objects.
• There can be duplicate edges between nodes as multiple characters share a sequence of events. Gephi does not draw multiple edges between nodes, but I can do something with node weights (plot element II edge between e1 and e2 has weight = 4.0, the hero's 3.0 + the other character's 1.0).
• Urgh, Keeler calls his plot combinations case I, case II, etc. I should rename them.

[hornc]

I might create an example library for each of the 15 elemental plot combinations.

• Case I plot graph, prompt, and vanilla AI generated scenario

This markdown file was assembled manually, but I should be able to automate the generation of each element and bring them together. The 'commentary' is written by me, not the AI.

Once the plot combinations are done, the next stages will be

• combine and sequence them in interesting ways to build bigger plot structures.
• Figure out what context to track
  • who is the hero (maybe this is fixed -- A = 1 can always be the hero)
  • who is alive or dead. Don't want too many dead characters...
• Object vs. Person
• Locations ... Keeler talks about the 5D space of stories: time, 3 x space, and motivation . Location will be important anyway. Modelling motivation also might be nice
• Experiment with different and more detailed characters, with descriptions and other attributes to be passed through the prompts.

[hornc]

November is apparently a month where people try to generate lots of text as part of semi-organized events. It'd be cooler to image the following was generated by a hallucinating artificial intelligence, but it's just some notes I wrote as I pursue this particular project. I contribute it as potential "training data" for our post-singularity feedback-screech future:

In a graph context and edge expressed context free is:

NODE, NODE or, if we want to start adding other attributes: NODE, NODE, WEIGHT

For a webwork plot, a meaningful unit is what I've started to think of as a "knot" -- where two different threads come together from two previous points. Keeler has a 3 thread version of a knot in this elementary plot combinations, and some of the diagrams show single thread knots. These can be modeled in the same way. The 2 thread version is a clear illustration of a more general n-thread-knot.

We need two pairs of (thread, source_node), and a new node label for the knot we are defining.

(thread_1, source_node_1), (thread_2, source_node_2), knot_label

Context free, that looks like:

THREAD, NODE, THREAD, NODE => NODE

We need the last node label because we want to give this knot an identity to use it later in other definitions.

Tracery style grammar analogy: PERSONAL_NAME is a PROFESSION or:

THREAD (coming from NODE) is entwined with THREAD (coming from NODE) to create a new event: NODE.

(this is basically the AI prompt too, but it's also the grammar needed to specify the graph edges.)

With a context free grammar, we could end up with the same thread combining with itself, which sounds like a single knot, or if the label node is this same as one of the sources, it's not even clear what that is in terms of what we're trying to model. We could easily end up with multiple definitions of one knot, and this could be thought about as multiple knots exist in the same place, with many threads contributing to many knots in the same place... but that doesn't help with a web, net, or plot.

There's a constraint that each thread only passes through a node once (unless time travel is part of the story?), and that each thread is a continuous path. That's quite a bit of context to manage. We need two different threads, and three different nodes, the source nodes must be "past" nodes, but only immediate past (a thread can't come from the same past node more than once), and a thread can't come from a node not already on its path.

We could hardcode every knot to be exactly what we need it to be for the envisioned structure, but that's not really a grammar, since no definition is reused, it's just a sequence of invariant declarations to specify exactly the structure we want.

GRAPH ::= KNOT1 KNOT2 KNOT3 KNOT4 KNOT5 KNOT6

Context free grammars can't do this any other way. A function which takes the threads and nodes and forms them into the correct edges is helpful in terms of encapsulating this knot tying:

def knot(thread_1, source_1, thread_2, source_2, knot_label):
    return: list of edges representing the knot

This could be modeled in a content sensitive grammar. Is this a useful and correct application? I'm not sure, but I'm experimenting with it anyway.

The grammar will show us that a particular plot combination involves, say, five knots, and there's context tracked in variables which ensures they are consistent with webwork plot constraints and the useful knots we need.

Knot labeling by simply incrementing an id counter seems to be sufficient to model some of the requirements. It ensures we only define each knot once, and we can ensure that all incoming nodes are less than it.

TIL: using any of the apparently multiple versions of EBNF to sketch out ideas quickly is a terrible idea.... a rough non-strict "syntax" is much better for expressing the gist of an idea fast. Near Fountain-like syntax is pretty good for getting an idea down, then it can be quickly polished to get an executable version of the grammar for rapid testing and testing slight variations.

In fact, using anything other the pencil and paper seems to slow down thinking about graphs. Describing a graph using a grammar is harder than I realized. Obvious graph-like qualities disappear. Just having to pick an arbitrary order to list the nodes seems to imply more than it should.

A,B => C

seems more wrong (implies A is 'before' B) than:

A
   => C
B

as if vertical ordering is less dogmatic than horizontal. A and B look more equal even though A is above... the aboveness is less ... hierarchical?

I've come up with a structure where I can quickly transcribe one of Keeler's plot graphs into a grammar, just by looking at it, but then when I look at the result, it seems quite meaningless. It will reproduce the diagram correctly, but if I made a typo, it's very hard to debug. It's much faster to transcribe it fresh

        <. && t1  = 2, t2  = 3 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 4, t2 += 5 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 1, t2 += 4 .> <. e2 += 26 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 1, t2 += 2 .> <. && e1 += 27, e2 += 25 .> Knot2<t1, e1, t2, e2, d, h>

Is the (current) transcription of a four node, 8 edge graph, that is easy enough to transcribe from an image, but doesn't appear at all expressive in the above form. I plan to DRY up the Knot2<t1, e1, t2, e2, d, h> bits by putting it in a loop.

Grammars seem a bit too linear to express graphs well. The sequential nature of data formats to store graphs are just not very graph-like... after deciding this was possibly a pretty obvious thing to think,

I decided to ask chat GPT:

me: Why are formats used for representing (graph theory) graphs so un-graph like and so unexpressive in comparison to what they represent?

chatGPT3.5: Interesting observation! Graph formats often prioritize simplicity and ease of machine processing over human intuitiveness. Representing graphs in a way that is both graphically intuitive and computationally efficient can be challenging. The focus is often on providing a standardized format that is easy to parse and work with programmatically.

Graphs can be complex structures, and translating their intricate connections into a format that is both expressive and easy to handle computationally is a delicate balance. While visual representations of graphs might be more intuitive for humans, machine-readable formats often sacrifice some of that intuitiveness for the sake of efficiency and consistency.

Do you have a specific example of a graph format that you find particularly un-graph like?

me:

        <. && t1  = 2, t2  = 3 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 4, t2 += 5 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 1, t2 += 4 .> <. e2 += 26 .> Knot2<t1, e1, t2, e2, d, h>
        <. && t1 += 1, t2 += 2 .> <. && e1 += 27, e2 += 25 .> Knot2<t1, e1, t2, e2, d, h>

chatGPT3.5: This looks like a representation of a graph using a textual format, possibly a domain-specific language (DSL) for describing graph structures. The use of <. && ... .> suggests some form of instructions or operations on the graph elements.

While this format may not be visually intuitive, it seems designed for ease of machine processing. Each line appears to describe a transformation or operation on a graph element (possibly a "Knot2" node) by specifying changes to attributes like t1, t2, e1, e2, d, and h. The syntax <. ... .> might be indicating a block of operations or properties.

In many cases, textual representations like this are favored for automation, manipulation, and storage in software systems. They allow for straightforward parsing and programmatic manipulation, which is crucial in many graph-related algorithms and applications.

If you find this format challenging to read or work with, it could be interesting to explore if there are higher-level tools or visualizations that can help bridge the gap between the machine-oriented format and a more human-friendly representation.

........

I guess it did a pretty good job of saying something about a very un-graph like format. Unfortunately I followed with:

me: Answer the original question in the style of Harry Stephen Keeler. (first response caused an error -- not sure if it was the 'censored' result, but a regen gave:) AI psuedo-Keeler: Well, let me tell ya, when it comes to representin' them graphs, it's like tryin' to untangle spaghetti with a toothpick! These formats, my friend, they're like a carnival of confusion, a maze of symbols that'd make a detective's head spin faster than a whodunit with six false-bottomed coffins!

You see, in the tangled web of graph representations, simplicity ain't the name of the game. No sir! They take the elegance of a graph, full of twists and turns, connections and disconnections, and they squish it into a format that's more like deciphering Morse code in a thunderstorm.

It's as if they're speakin' a secret language, one that only machines truly comprehend. The beauty of the graph, with its nodes and edges dancing in a complex ballet, gets lost in translation to this jumble of characters and syntax. It's like tryin' to read a novel through a cracked kaleidoscope—ya catch bits and pieces, but the whole picture remains elusive.

So, my friend, when you're knee-deep in these un-graph-like formats, remember, it's a cryptic dance of data, a symphony for the machines, but a head-scratcher for the rest of us!

[hornc]

I asked (without considering it'd stay in character):

The format I pasted is a context sensitive grammar I am using to attempt to represent graph structure.

response: Ah, a context-sensitive grammar, the plot thickens! You're delving into the linguistic labyrinth to capture the essence of graphs. It's like trying to weave a tapestry with words, each line a thread in the grand narrative of nodes and edges.

In this tangled tale of symbols and syntax, you're crafting a narrative where the nodes are characters, and the edges are the plot twists that bind them together. The additions and alterations, the twists and turns in your script, they're the dramatic cues that unfold the story of the graph.

It's a linguistic ballet, a dance of semantics and structure. Each line isn't just a command; it's a stanza in the epic poem of graph manipulation. And as you traverse this grammatical terrain, you're not just describing the graph, you're narrating its evolution, its metamorphosis over time.

But beware, my friend, for context-sensitive grammars are like the shadows in a film noir—they reveal the intricate details, but they also cast mysterious silhouettes. It's a language where every nuance matters, where a misplaced symbol can turn the plot upside down.

So, in this linguistic expedition into the heart of graph representation, may your grammar be as contextually savvy as a seasoned detective in a noir novel, deciphering the enigma of nodes and edges in the dimly lit alleys of syntax.

[hornc]

It's halfway through November (15th). I have had a whole lot of thoughts, my diagrams aren't quite as pretty as I'd hoped, and I don't have any words generated yet. I need to have another focused session and make some more progress.

[hornc]

Things are slowly coming together... at least for basic scenarios. I have not merged the WIP branch yet, but the output at the end of today's session is:

https://github.com/hornc/nanogenmo2023-webwork/blob/2b4c08ea4a6157e98a201aa13aab7b45bc202af2/PlotCombinations.md

It has some examples of LLM generated interactions based on the prompts created from the same kind of grammar as the graph diagrams. The strict causality of some interactions resulting directly from one another is not as strong as it should be. I think I need to work on the prompts a bit more. The grammar and sense is basically correct, but it needs to be tuned more.

edit: I ran a few more prompts. Perhaps these are suffering from being run in the same session? They are a bit samey. Everyone is an artist. Even my attempt to change things by setting events in ancient Pompeii for case XII didn't change the theme.