Skip to content

Category: HyperGlossary

Glossaries Integrated into Knowledge Graphs Scenario

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  

Leave a Comment

Liquid Glossaries

The Liquid Glossaries are an ancillary issue to the process of writing academic documents and as such is being looked into. The web page for this project is http://www.liquid.info/glossary.html and the blog posts relating to it are on http://wordpress.liquid.info/category/liquid-glossaries/ The relevance of glossaries for Liquid View is that the Liquid View needs to be able to show glossaries where required, in an visually efficient way.

You may have noticed the large amount of links to blog posts in this article. This is not only because I wrote too much, it is also an exercise in learning how to write re-usable chunks, which is where the Liquid Glossaries will come in.

Create a Glossary Entry

User selects text does keyboard shortcut cmd-l and the Glossary Dialogue opens with the selected text copied into the ‘Heading’ field. 

If the user did not select text but does cmd-l the Glossary Dialogue opens and the user can type in a Heading. 

There is a visual mock-up here: http://wordpress.liquid.info/glossaries-over-coffee/ 

The Glossary Dialogue

The Glossary Dialogue contains various fields, all of which can support rich text. They include: 

 

•  The ‘Heading’, or the subject for the entry. Name to be decided. 

•  Brief Definition (max 140 characters, indicated in [hard brackets for use in the Visible Glossary View]) 

•  Full Definition (long. This field can contain external links as well as in-document links

•  Option to save to Personal Glossary or only use in this document

On clicking ‘OK’/Enter, the Glossary Definition is saved to a database in the Author application (or in the document, depending on preference, as above). This database is connected to online versions (to be developed and discussed).

Interacting with Glossary Entries in Edit Mode

Wether the author has created an entry while working on the current document or created it earlier, the author can interact with the glossary entry in much the same was as interacting with a citation in Author. The Glossary Definitions are not visibly indicated (by default) so that to interact with the selected text’s glossary entry the author would need to do the cmd-l keyboard shortcut (or ctrl-click and choose). If there was a document entry it comes up for editing, if there was none, a new dialogue, as above, is presented. 

Glossary Logic

If the glossary entry is two or more words long, even though it can also be spawned on one (as shown in the screenshot in the blog entry referred to above), then if the single word spawn is followed by a capitalised word, it will not spawn. This is so that an entry can be for a name and if the author refers to another name where the first name is the same as what’s in a glossary entry, but has a different last name, it will not interfere.

Interacting with Glossary Entries in Read Mode

 

•  In Read mode the reader can click on text with a glossary definition to see the Glossary Dialogue in Read Mode (similar to the Citation Dialogue in Read mode). 

   

Visible Glossaries 

•  The reader can choose to turn on [Visible Glossaries] where all the Brief Definitions are automatically shown in-line in the text, either the first time they appear or every time then appear, in [Hard Brackets, in grey]. This mode can be turned on in a Glossary Dialogue button in Read Mode or through cmd-[ or cmd-] (’tab’ will have to be used if the user wants to indent). 

–   If the [Brief Definition] is clicked on in Read or Edit mode, it will open the Glossary Dialogue in Read or Edit mode. This text cannot be further interacted with on the page. 

Publishing A Document with Glossary

When the author chooses to Publish the document the document will be presented with all the ‘Brief Definitions’ inline, [inside hard brackets, in grey] for the author to review. The author can click on any of these definitions to turn them off (and the text goes red) and back on again with another click if mistakenly clicked on. The document is then published with a list of all the Glossary Entries at the end of the document (same as Citations are listed at the end of the document under ‘References’). How the glossary entries are embedded is up for discussion. 

Leave a Comment

Glossaries. Over Coffee.

Mark and Chris and I had a long discussion about glossaries where we ended up with the simplified dialog box shown here.

The logic is that the user creates a new entry, as in the case of an entry for ‘Mark Anderson’ here. The text [in the hard brackets] is the brief summary which will appear if the reader chooses to view brief summaries. The main body text is full rich text, which the user can enter URLs into etc. and where any mentioned Glossary entries will be interactable.

There is further an option to save this entry into the person’s glossary or just keep it for this document only.

The Botton underlined ‘Mark’ is showing what other text strings will activate this glossary.

Glossary Logic: If the glossary entry is two or more words long, even though it can also be spawned on one (as shown in the screenshot in the blog entry referred to above), then if the single word spawn is followed by a capitalised word, it will not spawn. This is so that an entry can be for a name and if the author refers to another name where the first name is the same as what’s in a glossary entry, but has a different last name, it will not interfere.

 

Chris’ notes:

 

Audio record of the meeting (marked private):

https://soundcloud.com/user-75792421/chris-mark-glossary-chat-may-2nd

 

And Chris’ notes via email later:

 

What we see here is the representation of a kind of relationship object which relates the following:

A search term within a scope [ “Mark” within the scope of the whole document ]

A (liquid) text #1 “Anderson Southampton PhD Student”. This is constrained to contain no structural elements (paragraphs etc.) but can have other elements (links, bold, etc.)

A (liquid) text string #2 “Mark Anderson\nHe is also at Southampton…”. This is constrained that it is a titled article, so the first text in the string must be a heading. The dialogue has chosen to place the rendering of the heading in a different part of the form, but editing it edits the text.

There is a heading relationship/range/whatever we call markup in this system, defined as the Mark Anderson text range at the start of text #2 to the end of character 13, indicating this is a title of level 1 within the article. This constrains the content that it may not contain additional markup. It also implicitly designates a section which exists between the start of this heading and the end of the flow of text, or the next title of the same or higher-level.

 

Leave a Comment