When discussing application, infrastructures, protocols, messaging, etc, it is necessary to precisely agree on semantics of expressions in order to avoid “mistakes”. However, HTML as a representation format has survived largely due to its ability to “tolerate” expressions that are not understood… the browser just ignores those expressions it doesn’t understand. That behavior / tolerance has allowed “backward compatibility” of HTML and browser versions, as new language constructs can be introduced that are just seamlessly (mostly) just ignored by older browsers.

Recently, Frode (Hegland) has introduced a need to discuss representation formats. One very strong reason Frode likes HTML is this ability to tolerate expressions that are not currently understood.

Sam (I) was asked by Frode today “If you went off on your own today with $2M+ to build something, what would you build?” I recalled my early 90’s desire to build a “spreadliner” - an application (we thought in terms of apps in those days) that could take a chunk of text, and allow those memes to be spread out spatially so that visual relationships could be depicted (not just mind-mapped), and also have individual nodes / chunks / memes that could be attributed so that they could be viewed in tabular, or spreadsheet, views. Fundamentally, I (Sam) seek knowledge representation that can allow multiple presentation modes (Doug calls them viewspecs), clearly separating the KNOWLEDGE from the PRESENTATION OF THAT KNOWLEDGE. (reference here to GlobalSIM vs GlobalVIZ aka MenTour).

In order that the knowledge be presentable in multiple views, we must design knowledge representation in such a way that metadata required for one view be non-harmful to the fundamental knowledge object, or to other views.

What is still a question is WHERE this metadata ought be located. Is it a part of the knowledge itself? Arguably, it is NOT essential to the knowledge itself, but to the viewspec / presentation mode that is being applied at viewtime.

More to be mulled…