Idea: Relate all the things

(This is an idea for a future readmspa.org project.)

It may sound similar to the previous idea - but in practice it involves different work, and it supports other outcomes.


INSANE BLOCKS OF GRAY ANGRY TEXT

First, let us divide the story into a sequence of narrative blocks.

(It is already a sequence of pages inside a hierarchy of Acts and Parts. It naturally divides up further into a sequence of panels - images, Flashes, sections of prose, pesterlogs - and that is how my archive currently represents it. In principle longer panels could be divided up further e.g. divide Flashes into different scenes - although those boundaries seem more arbitrary and editorial.)

Then the idea is to relate those blocks to the things (such as characters, objects, locations, etc.) that are contained in them.

Immutable Facts I Am Stating For The Record

This is a “structured data” version of the plain text descriptions from last time.

Free-form text is good to stand in for media that the reader couldn’t see, and to provide a word-based measurement of how big things were.

But structured data is better for other things. With enough richness, this kind of data lets us more reliably answer search queries like “where did John and Vriska see Typheus in a dreambubble?” or statistical questions such as “how many Flashes include scenes on Derse?”

It would be a searchable Homestuck database. A formalized Wiki.

Of course this is not a new idea. There are various half-finished attempts to do it. Some are individual efforts, others are crowd-sourced. I would mix these existing sources together with data I’d extract automatically from the story and tidy/curate a little manually, use this to seed a framework that makes it easy for me or anyone to add new facts, and invite everyone to play.

Now, the space to fill is enormous - and it would be ambitious to expect to complete every detail. However, there are ways to cut sections through this very compositional space that deliver incremental value. And, different contributors could indulge their own interests - if someone loves the Mayor, they can generate lots of Mayor facts and ignore everything else.

The awkward thing about this kind of data is that (especially in Homestuck where characters and objects can split and merge) it can be very hard for people to agree on a standard set of names for things. But the nice thing about this kind of data is that so long as any one data set applies its own conventions consistently one can typically write a program to ingest it automatically.

(Full disclosure: I’ve done this sort of thing before, for far more massive datasets. I worked on a team at Amazon for several years who manage the “inherent relationships” between products and other entities, such as “these two books were written by the same author” or “this camera model is the newer version of that one”. We ingested data as “opinions” from many different “providers” - such as libraries, manufacturers, internal Amazon staff - and combined them together, “arbitrating” disagreements and producing a “reconciled world view” of what the company should believe.)

Getting the correct foundational model is really important for a project like this because it determines what kind of facts you can express. Too much to discuss here now, but one thing I think is important is to define the relationship as well as the things that are related. It isn’t just that John is in some panel: one should distinguish the way in which he’s in it. Is he pictured? Is he talking? Are his actions described by the narrator’s prose? Or is it another story character talking about something he did? I think most RDF projects are far too ontologically ambitious and heavyweight, but I do buy the “(subject, predicate, object) triple” part of that approach.

whos in charge of timeline management there

Lastly, I have one more data concept I would want to mix in (and propose to capture facts about) because it makes a really cool project possible.

There’s already a default order to the story blocks - the one presented on the website. (Yeah, there are some allegedly branching choices, but due to the page numbers it’s easy to squash it back to a linear narrative that reads great.)

Now, even in the crazy time-travel scratchy alchemizing Homestuck universe, most often from block to block the different things in the story follow that order. If you consider John, then if he’s in one block and then he’s in the next block - or maybe he skips a few and then we see him again - then typically that’s how the story plays out for him.

Not always, of course. And even in the non-crazy universe of regular story-telling, not everything is linear. Suppose that later in a book you find out about the childhood of some character. For that character the events mentioned in the later chapter happen before those in the earlier ones.

My idea is that as well as recording appearances of some thing in blocks of the story as a whole, we should capture where that appearance fits into the story of that thing in particular. Due to the above, we could just note when it is different to the regular story block order.

(Details omitted, but since we never know when new sections of some story may appear, I think probably a partial ordering is necessary. And that splits and joins should fundamentally act at a level of the identities of things. This model needs work, but I believe I see how to do it.)

If you have that information, you can then present the story of Homestuck from the perspective of any character or object. You can see the story blocks in the order that Spades Slick does. You can follow the timeline of Dad’s car. Etc. Folk do this already in a text summary form for various bunnies and clowns, but this would let us read the story of anything.

As much as I love doing them, most of my remixes of MS Paint Adventures data seem to dry it up somewhat. And so a “read along the timelines” presentation really appeals to me because it would be a remix that preserves the visual, liquid story-telling nature of the original work.

(That was a long one even though it remains only a sketch. Thanks for reading!)

  1. readmspa posted this
blog comments powered by Disqus