Personal Context/Diary Note

This was written the morning after calling Jack Park to discuss using Glossaries as a means to tie documents and knowledge graphs together. I have since slept and I am now enjoying a nice single shot of espresso. Meanwhile, Jame’s sent an email with a great start to defining the goal and framework of a DKR, which I hope he will also blog so that I can refer to it easily here, while having yet another espresso at the Groucho. The approach comes from how yesterday morning I spent some time thinking about how I am kind of ‘representing’ the document approach and Jack Park and David Price representing knowledge graphs in databases approach and maybe I should quite simply switch my focus. For a while. I therefore thought about designing front end aspects of a knowledge graph while out for a walk with my son(!) across from Hammersmith to Wimbledon via the Common, and for some reason it hit me that a glossary definition might be a jump point between the two systems. I don’t know how this came about but here is the idea:

Glossaries Integrated into Knowledge Graphs

Doug sold me on the importance of glossaries, defined as definitions local to a document, author, field or some other particular use. It struck me that a glossary definition is made up of words and that at least some of these words also have glossary entries and that this might very well be a crude and simple knowledge graph!

Example

I enter “A DKR is produced using OHS technologies” which has two nodes: DKR as the term being defined and OHS being a term the DKR is being defined with, using the connection ‘is produced using’. This means we have two terms which are nodes and a link with a specific type.

Benefit: Reuse

This approach would allow for more easy re-use of contents (by having terms compressed and expanded into glossary terms in body text) and for rich visual and computational mapping of the terms in knowledge graph spaces with little initial effort when creating entries/nodes or integrating with them and keeps the various media intact all the while being deeply interrelated.

Glossary Entries as Knowledge Graph Nodes

So what I proposed to Jack is that we can use this as a kind of a human interface (as opposed to strict data transfer interface) between a regular document and a knowledge graph: A user can add to the knowledge graph by using this type of a ‘glossary’ interface when authoring and when reading a whole (or many whole) graphs can be accessible in this way. The reverse is of course also true, that when in a graph environment the user can benefit from what’s been added outside the graph environment.

So to achieve this we would have to build an interface for different platforms which can be invoked outside a knowledge graph but use its data. Jack said this is exactly what he and his team have been looking at but they called it something like wormholes or portals or teleports not glossaries but the principle remains pretty similar.

Scenario

I have posted a walkthrough scenario here: http://wordpress.liquid.info/glossaries-integrated-into-knowledge-graphs-scenario/

Importance of Powerful Views

Jack further discussed the importance of doing knowledge transforms, similar to how we can do mathematical transforms and this is just a powerful way of looking at it. I simply added the perspective of the user having the ability to jump around, to see same or related information in very different contexts and how I was annoyed that I refer to Headings as Nodes in Author when collapsing into Outline/Dynamic View and how that went further and how I found that the word Node actually basically means ‘knot’ and this removes the notion of a Node as being something solid and the connections between them something more etherial. Why not provide the user with the ability to flip the visual display so that Nodes becomes connecting lines and the connecting lines become the Nodes?

Seeing New Perspectives

BTW, I use purposefully visual vocabulary when discussing connecting lines since they could be so many things created in so many ways and interactable in so many ways, as I’ve been working on defining for some time and hope to put up a, yes, Glossary on, with the collaboration with all of you and particularly with our colleagues in Russia; Timour, Elena and Irina, based on Skype meetings, perhaps on http://symbolspace.info where we can write our definitions and where we disagree, if and when we inevitably usefully disagree, for a communal growth of this particular knowledge space.

Legacy Anchoring

This approach allows for interaction with a knowledge graph either natively or when in a more familiar environment and, crucially, allows for the user to switch between the environments at will and thus get the best of both worlds, or, to put it in a more Doug way, they get powerfully different ViewSpec options.

Issues

There are a lot of implementation issues of course, such as:

• what, if any, knowledge graph data is baked into the word processing document at the point of publishing the document

• what will the human-computer interfaces will be like; will they be plain text based like the original idea suggested or more click-on-categories and so on style?

• how should the data transfers be between these components? JSON-LD?

• how can we implement a frame for this on different OS platforms

• when should the data be integrated, immediately or use WordPress etc. as a glossary storage until a publish or other action?

• & more.

Proposal

I don’t know the answers, but I think this approach lends itself well to the criteria and goals proposed by James and should therefore be part of our core investigations.

I eagerly await comments here in the comment box, as blog posts or elsewhere.

Criteria

These are the criteria as we understand them at the end of 2017:

Design Perspective

• The system needs to have provisions to co-evolve with the end users so user engagement in the design process is important

• The system needs to be explicitly designed to bootstrap itself into ever more powerful versions

• The design direction is to imagine and build powerful tools first and then on making them as useable as possible

• Along the same lines, the design direction will focus on high performance users while providing novice users basic interactions

Interactions

• The DKR needs to support the CoDIAK process of ‘concurrent development, integration, and application of knowledge’

• The focus needs to be on rich interactions, where the user should be able to achieve high performance through powerful tools, not on ease-of-use for the sake of it

• Creating powerful views, or ViewSpecs, of the information space is a prime challenge

• Representing, analysing, creating and modifying information connections through links, associations, bindings, dimensions, searches and more, will further be a prime interaction challenge

Data Space

The system will need to support multiple data spaces, including but not limited to:

• Live Database Interaction of Knowledge Gardens

• Collaboratively authored Documents

• Individually authored Documents

• A Journal system for publishing Documents which are highly interrogable with a robust versioning system

• All current and future media types and meta data

• And the means through which to transfer data between the different spaces, both through networks and through something like Socratic Authoring

Underpinning This

• All material needs to be archived in usable and accessible ways for access in the distant future

• The DKR needs to be able to interchange data with legacy systems

• The DKR needs to be able to interchange data with different components among a heterogenous DKR

• The DKR will be heterogenous, meaning that anyone can build components

• The DKR must be massively scalable and robust, in order to deal with ever growing profusion of data and links.

Questions raised from Dialog

To contribute to this dialog please blog your thoughts and email a link to the webmaster, frode@liquid.info or post your thoughts as a comment below:

• Vint Cerf

“What kind of scaling problems might we encounter? will increasing numbers of documents produce increasing amounts of references that have to be repeatedly updated? the one-way links of the WWW escape this problem at the cost of broken links and lack of backward references”.

This was entered in the list as ‘Must be massively scalable and robust, in order to deal with ever growing profusion of data and links.’ In the Underpinning This section.

• Jack Park

You made it *document centric* since a repository holds stuff, mostly documents. I would argue that documents are only a tiny fraction of a DKR. For example, there is a kind of operating system for DKRs about which nobody (except the TQ tribe) ever speaks. After all, there is a social system in there together with a tool system. The social system needs an OS; we believe that an appropriate OS is Presencing.

In the document-centric context, please note that Ward Cunningham’s FedWiki comes damned close to covering most of your key points.

Also, too (channelling a recent female VP candidate), Yuzuru Tanaka’s Meme Media — WebbleWorlds — was invented when the OpenDoc initiative collapsed. You want documents, go talk to Yuzuru. He wrote a book about that whole space; well worth studying. At the same time, he conducted a major conference on Knowledge Federation on the Web, long before Dino and I did the same thing. In fact, he attended every one of our Dubrovnik conferences.

Final point: I salute any effort to come to grips with what DKRdom means. I would submit that it is borderline a fool’s errand to become so explicit in what, precisely, a DKR *is*. It will be whatever people make it to be. Pretty much, full stop. But, that’s not the end of the story. You heard this before:

Since there are now and in the future will be more DKRs out there, the Engelbart vision is best served not by engaging in pissing contests about *WTF is a DKR?* but, instead, how the hell to federate them. In that context, I worship another hero:

Oliver Selfridge, who, in 1958 — about the same time as some people got together at Dartmouth and invented the discipline of Artificial Intelligence — published a paper about his program Pandemonium. Pandemonium is a program with lots of agents. Some of them are pattern detectors. Like neurons, they shout according to the degree to which they detect a pattern. Others are listeners; they evolve to turn the signals of groups of pattern detectors into other signals which are monitored by decision makers. Think about it: that’s a DKR.”

• Mark Szpakowski

“I’ve installed Author (I’m a Mac owner, box of tissue by the side) & watched a couple of the videos. Gardening, documents, and document authoring certainly relate. You want to be able to harvest the garden at times, into forms such as text documents or more fully multimedia forms. Right now Author can bring in “citations” from sources such as Wikipedia or Amazon or anywhere: in this case the world-wide web is a kind of patchwork of jungle and cultivated areas. If there were a TopicQuests-style garden (a k-hub) then it could be a source from which Author could retrieve citations. Author-ed documents could then also get published/planted back into that garden. That could be mutually useful.

Another growth direction might be along the lines of a “perspective editor” (in context of quests hosted on k-hubs which result in perspective documents (more static) or perspective viewers (more dynamic)), which could have two panes, one being the document editor, and the other being a view into an information source (like a garden) where the pieces to be documented appear in various forms (for example, you might have selected subsets of an IBIS conversation tree). The pieces from which the document is written are assembled “in the garden” (which also enables persistence and further personal or group re-use as permissioned), and then the document is written by one or more people. If the latter, then another adjacent growth direction is multi-user authoring.

Regarding platforms, to further success these days the platform is the multi-device world. For example, for short-form writing and notes I use Bear, which works and syncs transparently across my MacBook, iPad and iPhone. Looking forward, I think DKR control rooms will be guild/agent-assembled mosaics making use of all available devices. But for now, as stepping stones and to demonstrate forward steps, limited platforms (Author is Mac-only) seem acceptable. If the functionality is seen as valuable, there will be pressure to implement it on the desired platforms.

So, tl;dr: let Author read from and write to knowledge gardens.

Is this Author-Garden federation?”

• James Prescott

“My name is James Prescott, and I was added to this email chain by Jack. We work together on TopicQuests. I have been hesitant to jump in because while I am a fan of Doug Engelbart’s work, I do not have the connection to him most people on this list seem to have. I never met him and, based on what I have heard, I felt that I would never be able to “get it” the way Mr. Engelbart got it. I would just have to muddle through with my interpretation of it.

In some ways the lack of familiarity is helpful; instead of being worried about strict definitions, my concern is what works best and is used by the most amount of people. I can never achieve perfect Engelbart form, but if I am really good I can capture the spirit and function.

In that spirit I would like to suggest two things. First, in terms of federating effort and creating an environment for development, I would like to recommend a process developed by Local Motors. They crowdsource the design of their vehicles at this site. It seems to me that creating a portal like this one to make it easy for people to jump on and off projects easily based on interest and skillsets is what the MOAD conference can use to facilitate the development of the Engelbartian tools we all need. It makes onboarding easier; plus you could build events around a site like this (hackathons, locals discussions, etc.) A centralized site with all of the projects that individuals across the country could swarm on. I think that could be a powerful thing.

Second, it appears to me that there is a definition problem regarding what precisely to build. Different people have different priorities, and in the spirit of federation that would seem to expected. Instead of trying to constrain people to one set of features and risk alienating allies, MOAD50 can come up with a general set of guidelines (possibly specifically about how the data will be structured) and set everyone loose. MOAD50 doesn’t build a product; it establishes a framework or schema. This way, instead of revealing one product or tool, you can have an eco-system of interoperable tools, each of which speaks to an aspect of the Engelbartian vision.

Just a thought from an uninitiated. Your personal mileage may vary. Thanks for your patience and thanks for organizing all this.”

2 Comments

Tag: OHS

Glossaries Glorified into Core Connectors