Glossaries Glorified into Core Connector MacOS Implementation

Published by Frode Hegland on January 30, 2018

The way I plan to implement the glossary system for Knowledge Graph integration is in my current systems:

When writing any document anywhere, select a phrase to turn into a Glossary Entry by launching Liquid http://www.liquid.info and choosing ‘Glossary’ (g) which takes the selected phrase and presents it in a dialogue with options for plain text and single line fields for specific natural language phrases such as ‘xx is a part of yy’. This dialog must be designed in collaboration with the team (Jack, James and David, at a minimum).

On ‘Enter’ the information is posted as a blog post to a WordPress site with the correct ‘Category’ to assign it as a glossary entry (Liquid already has the ability to post to WordPress).

The team must then design a scraper to work to take these blog post glossaries and turn them into Knowledge Graph.

On reading in WordPress, we can have our Hyperwords plugin (which works by showing a blue dot when selecting text) include an option to ‘Show Glossary Entry’ (we already have search and references and so on) which shows the entry in a window. This window will have an option to ‘Open As Knowledge Graph’ which results in a Knowledge Graph software product (DebateGraph, TopicQuests…) opening the associated Knowledge Graph with the current phrase highlighted/in the centre.

This is only using my stuff, with a minimum of effort to start testing. Other platforms and other software is for others to put effort into but I’m very happy to work on this have have the components and APIs be open, so at least we can try out this kind of a concept.

What do you think?

Glossaries Glorified into Core Connectors

Published by Frode Hegland on January 29, 2018

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.

Glossaries Integrated into Knowledge Graphs Scenario

Published by Frode Hegland on January 29, 2018

A scenario of how glossaries can be implemented and integrated with a Knowledge Graph (KG).

Adding

I am writing a document and I type DKR and realise I should probably explain what I mean by DKR. I therefore select the word and choose ‘Add to Glossary’ which produces a form with the word ‘DKR’ as the subject and several fields. The first field is a plain text comment field and below that there are a few single line fields where I can write sentences in plain text (or via pop-up menus, if I so choose) which explains how DKR relates to the rest of the concepts in the relevant space I am writing about. For example:

DKR is made by OHS tools

This then is interpreted by the system as having two nodes; DKR and OHS and a relationship ‘is made by’. If OHS is already in my glossary the word will be auto-complete ready to turn into a token. (This is done with the logic of a link, so that if there was no OHS and I add one now, I’ll have to go back to this to make OHS a live token, though this is up for discussion, I just think we need to be careful here).

In the future, when I write, DKR I won’t have to explain what I mean by the term.

There design problem here is illustrated with using someone’s first name in a sentence, such as ‘Doug’ and have this refer to a specific person for a while, such as ‘Douglas Carl Engelbart’ and then there is a reference to another ‘Doug’. Should we therefore make the default to auto-tag all Doug’s and make the exception something the author un-tags or should the user be in control of which glossary to use on which document?

My perspective at this point is to treat included glossary terms in the same was as included citations and that is to provide the author a way to see all the occurrences somehow (perhaps at the back or at the end of the document) for editing and approval before making the document public.

When the document I am working on is published, any new glossary entries are upload to the associated KG (or live, it’s up to discussion). This is the part we need to collaborate on, for this system to perform a useful function as part of a real 21st Century DKR.

Advanced features could include being a part of a community of glossaries so that when I try to make an entry for DKR I will be shown that someone else has made one and I can either import their definition, with attribution, or link to it.

Using

When I read a document and come across the term JSON-LD I can choose to view only the glossary entry or view the term as a node in a KG.

In traditional word processing software such as Author, the logic of the KG will be internally understood, to provide data for a dynamic view including or only of glossary terms: http://www.liquid.info/view.html

Month: January 2018