Deeper into Fedwiki interoperability

Should I even be writing this as an ordinary journal entry?

I want to write more about the potential for interoperability between Fedwiki and the rest of the web, and at the same time I have this feeling that it doesn't really belong in a journal. Perhaps I have a case of cognitive dissonance when thinking about potential readership. Who is going to be interested in what I write about Fedwiki interoperability? Would it not be better to put technical thoughts in a separate place? I know some people keep distinct blogs for that kind of reason – a separate blog for each different ‘persona’.

But I have qualms about separating things in that way. I've been enjoying the fluidity of writing about technical matters and then adding more personal or emotional asides, even as I expect that those different parts may speak to different people. In a personal journal like this, I want to make a point of claiming my ‘fluid identity’, relating those different aspects of my own self. It's paradoxical, this idea of fluid identity. If I identify too strongly with a fluid identity, it detracts from its very fluidity. So, comforting myself with the idea that the main reader of this journal is myself (in whatever persona that may be at a later time), I will jump into technicality.

Export and import

Last time I was rather too negative about Fedwiki interoperability, and I've just changed a bit in that entry to equivocate a bit more. I recognise now that it is actually very straightforward to translate a fedwiki page into HTML, using the ubiquitous <div> feature of HTML, and to lay it out readably with CSS stylesheets. Essentially:

  1. the Fedwiki "title" becomes the HTML <title> in the <head>, and in duplicate, starts the <body> with an <h1> element;
  2. the Fedwiki "story" translates to an HTML <div> encompassing the rest of the <body>;
  3. each item in the Fedwiki "story" becomes an HTML <div>, with the id as an id attribute of the <div>, and an HTML class corresponding to the Fedwiki "type";
  4. if the Fedwiki "type" is "paragraph", the "text" is put into an HTML <p> element
  5. if the Fedwiki "type" is "html", the "text" is put unaltered into the HTML;
  6. if the Fedwiki "type" is "markdown", the "text" is converted from Markdown to HTML (easy);
  7. and Fedwiki links within the "text" would be converted to HTML <a> elements, with some attribute on that element signalling if it is an internal link.

Each other Fedwiki "type" will need a function that translates it into appropriate HTML. Presumably that is already done within Fedwiki, as that is needed for display in an ordinary browser. Similarly, the relevant parts of the stylesheet which govern how each item is displayed when using Fedwiki can be added to the head of the HTML, or alternatively the whole stylesheet can be provided as a separate .css file in the normal way. It doesn't really make sense in an export to convert the Fedwiki "journal", which is a record of changes to, or reordering of, the items in a Fedwiki page, so that can be left out.

To achieve a ‘round trip’, first from Fedwiki JSON to HTML, and then converting the exact same HTML back to Fedwiki JSON, a conversion program would need to be written. There are several aspects that would clearly need to be included.

Notice my strongly stressing the exact same in the previous paragraph. It is a whole other question, how to import HTML that has not been previously exported from Fedwiki. The JSON page model is tightly constraining compared with the general HTML Document Object Model, so the task of importing arbitrary HTML is effectively the same as converting it into a form that fits into the constraints of the Fedwiki model. This may not be as impossible as it looks at first sight. I've noticed, when browsing a complex web site on my phone, that sometimes I am given the option of viewing a simplified version of the page. This seems to be the case particularly when the page has HTML tables in it. So, somewhere in the browser lies a program that takes the original HTML and transforms it to a simpler format.

As an aside, if I were tasked with improving the potential for Fedwiki interoperability, one thing I would do would be to have a tree structure, rather than a flat list, for page content; and I would try to make that more compatible with the HTML DOM. One minor advantage of this would be that it would support effective lists, which could easily be reordered though drag-and-drop interactions.

The question, for conversion to Fedwiki, is not whether HTML can be shoe-horned into Fedwiki format, but rather, how much of the original page will be lost, or distorted beyond usefulness. Trivially, HTML can be converted into Fedwiki JSON simply by putting the whole of the web page HTML into a Fedwiki JSON "html" item, but this would bypass much of the Fedwiki functionality, as the page would be one monolithic block. The question becomes, how much from an HTML page can be effectively recognised as corresponding to the Fedwiki model, and separated out into a paragraph-like "item"? We can see this as a serious, open question, which I will not try to answer at this point.

APIs and protocols

I've just dealt with data export and import – data portability – which is only one (though large) part of the interoperability issue. There is another whole aspect to interoperability, which is to do with active interaction between one server and another, via APIs and the respective protocols. The first thing that comes to mind is my lack of knowledge about the interoperability between different Fedwiki servers. How is this arranged? I have yet to delve into the mysteries of how the "story" item "id" values work. Before knowing more, what occurs to me is that, to get cross-server interoperation, either there needs to be a way of ensuring that item ids are globally unique, or they would have to be relative to a server. As I don't see how they could practically be globally unique, I would like to see an explicit reference to the originating server as part of the id.

The second thing that occurs to me relates to the more general interoperability with anything else on the web. This is closely related to separating the interface from the functionality, which I wrote about before. If there was a clearly documented split between the two, not only could different interfaces be designed and remain compatible with the whole Fedwiki ecosystem, but also other software could interact with Fedwiki content in different ways. Just to give an example that is not yet possible, if Fedwiki adopted JSON-LD, along with extra semantic content in the JSON views, I can imagine some service using SPARQL including Fedwiki content in semantic searches. That, by itself, could be a valuable contribution to a knowledge commons.

Including the human side

A couple of points of reflection on all this. First, I feel an uncomfortable embarrassment about writing so much about Fedwiki so soon – it's not academic practice to publish without careful checking. I'm seeing myself getting carried away by my own enthusiasm, in either direction, in positive or negative reaction. So I'll reconnect with my intention here: to find some software that is well-adapted to what I see as a desirable knowledge commons system. Obviously I would be delighted to find something that is both open source (as Fedwiki is) and perfectly well adapted: a nice dream. Dreams being broken lead to negative emotional reactions against what doesn't live up to the dream – in many walks of life. So one of the things I want to do here is to observe my own patterns, and see if I can find my way, at least to recognising when they happen, and moving on gracefully!

On the technical side, I want to come back from this detour with Fedwiki, enriched with much more clarity about what the software needs to do for us. So right now, I'm thinking of reconnecting with my intention to write more about what an effective knowledge commons would look like, in context; and what part would be played by the ICT, including the wiki or wiki-like system; always trying to keep in balance attention both to the technical and the human sides of the challenge.


Topics: Interoperability; Journal writing; Wiki software


If you have any remarks on any of my posts, please send me e-mail, saying what you want me to do with your remarks. Are they private to you and me, or would you be happy to quote you (I will always attribute your words unless you ask me not to), and add your response (or parts of it) to the post it's about?
Creative Commons Licence