Skip to content

Glossaries Integrated into Knowledge Graphs Scenario

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




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.  




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:  

Published inDougDemo@50HyperGlossary