Skip to content

Category: Liquid | Author

Glossaries Glorified into Core Connectors

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.  

 

Leave a Comment

blog update 17 Sept 2017

 

Author & Liquid

I launched Liquid | Author to the App Store the Friday before The Future of Text and we have had some time to test it and Jacob has worked on improvements but today is the Sunday after and I’ve had to withdraw it from sale since there are still some issues.

What remains to be done are a number of smaller issues, which I’m sure he can complete on Monday, but there is also the issue with the pinch to collapse into Outline which is concerning me since this is something he has worked on even with a special build. Maybe it’s really simply to fix, maybe it’s more fundamental.

I have also introduced a change which I hope will be quite a big boost for the project, removing Liquid | Flow as a separate product and integrating it into Liquid | Author so that I only have one macOS product and yes, Flow will still be useable from all applications but will now be called just Liquid again :-)

I have therefore re-written the User Guide: http://wordpress.liquid.info/liquid-author-user-guide/

This causes more work and time and stress. Will it ever be releasable? It is simply not easy to develop with a small budget. I hope Author will be solid enough so that the stress on my chest will lessen (I feel like I’m about to star in the original Aliens movie) and I can think more about development and so on…

 

Future of Text

The feedback has been very good and it really is great to have quite a few people from Southampton involved. Second day feedback not as excellent and maybe in the future we simply make it a networking/discussion day? Archived: http://thefutureoftext.org/2017.html

 

PhD

I feel utterly at the mercy of development for Author as to how I can do with my PhD. I am not a literature review or review person nor am I am philosopher, I am an inventor/developer who needs to live in the environment I am trying to invent for. If I don’t have Author to build Liquid Views into, I simply can’t see what I can do.

I mapped out some interactions for mac vs iPad which was useful. What became clear from this is that interactions for executing commands immediately and an equivalent for mouse over to show further information needs to be developed for iOS for Liquid Views:

This is related to mapping functions to interactions for Liquid View in general:

Which situated within the space of textual elements, as shown in a  small view:

And a massive view:

All of which is designed to augment the document’s knowledge lifecycle, in a very wide map, which is best viewed in the Scapple authoring app where you can zoom and pan and which presents design issues for Liquid Views because of its size and interaction complications:

Anyway, tomorrow we go to Oxford and I’ll get to spend some time with Wendy and Edgar will hopefully get to meet Tim.

 

Note: I was planning to design a freeform thinking tool for iOS but it becomes clear again and again that any tool must be part of a real workflow, which is why Liquid Views are a view of normal Author documents.

Leave a Comment