Skip to content

Month: October 2015

Definition of ‘text’ for FoT purposes

We don’t define text rigidly as this would constrain our future. The essential element of text is its symbolic meaning, which even the first red dot in the cave provided – giving it the property of communication over time. Further is the grammar which connects pieces into greater wholes. As for the rest, let’s look into that together.

Please comment. We want to focus our discussion and innovation, but not constrain it.

Leave a Comment

Call for the creation of a new document format for text and rich multimedia contents.

This is a call for the creation of what you might think of as an extension of .rtf which will remain robust but which will also be incredibly flexible and extensible.


  • .deep
  • .linked
  • .future
  • .fdf
  • .rdf
  • .liquid
  • .iceberg
  • .neuron
  • ?… please suggest


The name of a new document format is still to be decided but the need is very clear: We need to create a technical environment where innovation can flourish. It’s not enough that a single company for a single application can make something flexible, we need ways where any company can create an application which can open, edit and save to the document.


What we are calling for is the co-creation of the landscape for innovation – you can’t build without ground. You can’t extend without a robust and shared base.



The paper in documents is the substrate where the information sits.

Digital documents are not just the substrate of what they contain,
but also the soil, it is where our work grows.




The basic requirement for the document format is that it is open for anyone to use.

Ad-hoc additions should be possible, provided the ad-hoc additions are clearly, humanly, explained where added in the document.


I write a document in Author which I send to Sam. Sam chooses to open the document in a 3D concept map space, where he moves my text around in paragraph chunks as nodes, collapses some text under headings, adds new headings, connects nodes, annotates, tags with comments and so on. He then sends the document back to me and I can open it in Author and see his additions without loosing my basic Author style of viewing the document. I make further changes and sends it back to him and all the information need to display the in his system are still retained, with my additions politely placed to let him move around in his more advanced space, should he so wish. He then further works on it and sends it back to me, with all the contextual information retained, as before. And so it continues, with each sharing of the document being robustly versioned and any and all useful meta information retained (and shared, depending on each users preferences0, such as when information was added, where the user was when it was added – as much meta as possible for the user in the future to be able to richly view their history in the future.

That is the goal- to have an ever expanding document format. Will it matter that it will be very large? No, not in a world of gigabyte video files. Why should text based documents be smaller?

Information is Interaction 

The development of this new document format will allow for the proliferation of new ways to richly interact with information, while retaining the ability to share the information.

It will also be crucial that a new way of linking will be developed alongside this document format, along the lines of academic citations but digital, liquid links, with link types.


Such a rich new document format would enable innovation, but there also needs to be innovation with text based applications as well, for paragraph level links, link type and link previews for example.


Let’s upgrade the space we have for innovation.


Re: Sam’s Dictapedia

In response to Sam’s post.

First of all, as discussed on Skype today with Sam and Stan, Liquid Server can be expanded to do some of this. I have emailed the following to the original developer, Tobias, to see what it would cost to do it this way:



First would be the general cleanup of the issue that the mouse over the menu items (nothing visual happens for MO) and creating a new account needs to work, not solid now.


User Interaction:

• User selects text on blog.
• Liquid list comes up. Top level includes: Glossary. Sub menu is names of any person on this wordpress site which has written a glossary definition for this word. (If no-one, then this menu item will not appear at all.)
• User choses a persons name and is presented with the text of the definition in the normal Liquid window.
• Top left in the window, where the name of the site would be, appears the name of the author of this definition. Click to open that persons glossary definition post.


• The possible list of definitions are from those authorised to be a writer on the wordpress blog.
• This means the system needs to have an index of all the definitions so that the menu can be grown dynamically (on page load I suggest).
• Results are shown as in current prototype.

How to create a Definition:

Data comes from the wordpress site itself: User posts the subject in the format: “Definition: Word” (non-case sensitive).

The body then becomes the glossary entry.





Other Issues


The above system is quite old and I never really manage to get it off the ground. It was co-developed by Fleur and Rob, back in the day.

Concerns about developing it now is that it’s for one platform only, I’d like to be part of a Liquid system, which is faster and works in all apps, but I appreciate that now all KF members are OS X users :-)



We could also look at how Wordnik scrapes for definitions, learning them automatically.

oh, this is an area ripe for innovation….


1 Comment