Skip to content

Category: Liquid | View

… Further Notes on a ‘Add Term’ dialog box

Further to Wednesday calls it might be useful to let the user choose which pre-set Categories sets to import from the chosen Knowledge Graph. Also, the creation of relationships here is done in a pop-up box where [OHS] [builds] [DKR] is manually ‘coded’, where the verb can be typed or chosen from a list based on the knowledge graph space interacted with.

This is based on the previous post.

1 Comment

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’


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.



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.


Concept: Subspace (unlikely to implement as described)

Subspace is a specific view layout where the user can choose to see only a subset of available headings, hence the name.  


The purpose is to allow the user to explore a subset heading, to see and interact with what’s below it in the hierarchy but more importantly to allow the user to see and interact with what it is connected to, manually and otherwise. Any changes to this view will be stored for future access of this view.  


The interaction here is to make the interactions more ‘physical’ or tangible than clicking on buttons or choosing from options in menus: 


• The user taps/clicks on a heading and drags it to the top of the screen, onto the top toolbar. The result is that the name of the heading becomes appended to the name of the document, such as: Document | Heading (this can be done from this view as well, increasing the depth).  

• The result of the canvas is that it only shows headings connected to the selected heading.  

• The specific layout will have to be experimented with but this initial design is for higher or same level are shown horizontally under the top toolbar and those of lower levels are shown in the main canvas (to be tweaked of course) 

Leave a Comment