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.
