Skip to content

Category: HyperGlossary

Notes on a ‘Add Term’ dialog box for document centric use, which can be shared with knowledge graph systems

A simple wordpress dialog slightly modified to cater for glossary terms, with the option to provide more than one term for search/listing and a free-form text definition entry field which is constantly analysed to provide possible links to previous terms are shown below, for the user to choose to connect to or not:

Analysis For Connecting (?)

I am a very simple guy, with no real knowledge of AI or anything like that but if we really can have the system do basic semantic analysis then it would be very useful I think, so that users won’t have to manually make links between terms (it’s time consuming when you link two new terms and you have to go back to the first to manually create a link to the second and so on). IF the system can extract ‘term’/nodes from text (and go back and do this on older entries for auto-linking and then use the rest of the sentence for link-typing, that would be very useful I think.

Furthermore, if this analysis was in real time with writing the terms then the system could show the old connections found and allow the user to approve, disapprove or modify them. THAT would be great, as mocked up here:

  • Field for Term on top (with ‘+ Add New Term Text’  option to add acronyms etc.)
  • Definition Field in plain text
  • ‘Found Related Terms’ with check boxes to approve
  • Other standard WordPress fields, such as ‘Categories’, ‘Tags’ and ‘media’

Usefulness

The usefulness of this approach of using glossaries will come when someone reads the authors texts and chooses a ViewSpec to access the glossary entries from (stretch text or mouse over fx) and when the author publishes text by choosing to export related terms and ‘freeze’ them in the document for future reference.

 

Visualisation

The resulting information can then be brought into visualisation systems and presented in a myriad of ways, as a part of a dynamic view in the authoring or reading systems or in full knowledge graphs, such as this:

or even this:

or this:

This continues in the next post.

2 Comments

Glossaries Glorified into Core Connector MacOS Implementation

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? 

Leave a Comment

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