i'm trying to consolidate my thoughts around building a comprehensive self-publishing and cataloguing workflow into a cohesive programme and i think i'm getting somewhere with it

So I've been doing a lot of thinking about my work, and my goals, and where it's all headed lately, and something that seems to be a continuous thread throughout it all is freeing up publishing and cataloguïng tools for indie creätors and really just making the whole process as clean and smooth as possible. Because like, I got into web technology in order to do self‐publishing; virtually all of the development work I've done has been related to publishing somehow; and still, looking around, nothing really feels any easier than it did when I first got started?? Maybe things are even harder now—idk.

On my birthday at the beginning of the month, I published a preliminary catalogue of all of the projects and creative works I've put time into over the years. You can view that here. I think that these sorts of catalogues, on a personal level, are cool and important, and something that the Internet enables in a new way. There's no reason to limit ourselves to only the most polished and refined of our works in a world where sharing text is as easy as uploading a file, and being able to trace a text back through past forms and iterations is (I think) really useful both in terms of historically situating a work, and from a pedagogical standpoint of demonstrating the act of revision and contemplation by example.

There are some authors who are content to use Git for this sort of thing, which I disagree with, firstly because Git revisions do not map wholly or cleanly onto the system of volumes, versions, and drafts commonly used in literature—you can get around this, somewhat, given enough repos and tags, but it's honestly in my experience more trouble than it's worth—and secondly, because Git does not actually provide an accessible means of publishing multiple drafts of a work in a manner that is easy to host and browse using basic web technologies—at best, the process is something like Releases[Your draft here]View source[The page or document you are looking for] via a site like GitHub—and then only if the format is something which the site is capable of displaying. And certainly, if Git isn't a suitable technology for browsing multiple drafts of the same work, it's not going to hold up when trying to browse multiple drafts of a complicated and potentially interconnected network of works, the sort of which I would like to see and am interested in publishing for my very self if nothing else.

Organizing drafts in a manner easy to browse using a filesystem (and by extension, a web browser) is something I've been grappling with for as long as I've been typing my works up onto electronic devices, as I'm someone who has always kept every draft, and benefitted greatly from being able to browse old copies of works for new inspiration. I came up with the Branching Notational System as a way of hierarchically organizing works into a tree structure that can be represented as a single string suitable in a URL or filesystem. As it currently exists, I basically have a script which trawls my filesystem for files, reads their associated metadata for more information, and constructs a giant YAML file which is then piped through Jekyll for the resultant site. This works, but it's a delicate system, and not one that can easily accommodate the workflows of others.

That said, the problem of converting work metadata into a single unique identifier representing a location within a filing structure is the problem of library cataloguïng more generally, and so although my particular system has developed in a personal manner through my own work habits and practices, the systems and technologies that I use when managing it have the potential for significance to a much wider audience. And it is a problem for which technologies have already been developed—Linked Data, as a field, is concerned with the interrelationship between object metadata, as RDF, and unique identifiers, in the form of (hopefully) dereferencable IRIs.

However, Linked Data and related technologies are not something which is really accessible to anyone who doesn't have a high level of web literacy and who hasn't spent the past several months reading up on relevant W3C standards on the internet. So, what I'm aiming for in all this is the following:

  1. I want there to be comprehensive tools for working with Linked Data from a client‐side, programming standpoint. Many programming languages already have libraries for something like this, but they tend to be outdated, unmaintained, or cumbersome. My emphasis here, at least initially, is on JavaScript, since clients written in HTML and JavaScript are the most accessible for laypersons to run, regardless of platform or environment.

  2. Next, I want there to be meaningful high‐level tools for people to write documents, associate them with metadata, and catalogue them in an easily‐browsable fashion, without necessarily having the programming chops to deal directly with the above. This is, in fact, the same design goal as ActivityPub clients, since ActivityPub objects are, in essence, just metadata‐rich documents catalogued in a typically‐chronological manner. Of course, I'm looking for a cataloguïng system more complex than pure chronology, and a more expansive system of metadata than just the Activity Vocabulary. But my hope here is that some of the work that I do will be transferrable over to the ActivityPub client realm, once ActivityPub clients are actually a thing, in the supports C2S services in the way outlined by the spec sense.

  3. Finally, as an ultimate end‐goal, I want there to exist easy‐to‐use tools for publishing said documents, on the internet, in such a way so as to be accessible for other Linked Data clients (including but not limited to the above) to discover. This is roughly the same goal as ActivityPub servers, and if I end up writing an ActivityPub software of my own to supplant Medium as the première in accessible document publishing, I certainly won't be shedding any tears.

    There's a lot more to having an accessible publishing programme than simply building a server software, and this is all a bit above my paygrade, but these are bridges to be crossed once reached and not a second before.

To tackle the first of these wants, I'm currently in the process of developing a software called—and yes the fullwidth is important, this is kibigo! speaking after all—mermaid. It's starting out as an implementation of RDF Interfaces—in spirit, at least, since I'll be updating things to be a little more compatible with RDF 1.1. From there, I'm adding in support for XSD Datatypes, different parsing and serialization formats, and honestly who knows where I'll end up.

The whole thing is being written in Literate CoffeeScript 2.3, and I'm targeting ECMAScript 5.1 with my transpilation so that it will hopefully run pretty much anywhere.

mermaid is a personal project, and I'm not really looking for outside code or contributors, because if there's one thing I don't need after the past year of work with Mastodon development, it's the stress of trying to manage an Open Source Project™ on top of actually coding my dang shit. That said, it will be licensed GPL, literate‐as‐in‐educational, and I'll have the whole source up somewhere as soon as I have it somewhere worthwhile to put up.

More info soon hopefully! But that's all for now⁓.