Glossary matching options

[Uffe]

Hello,

Are there any options to control how glossary terms are matched in the GUI?
I've got case-insensitive and whole word only. Can this be changed somewhere?

I am aware that this wouldn't make it possible to define two terms with only casing differences. That's not the question, I want to know if I can influence what gets highlighted in the Notes fields.
(For that matter, changing how the match is highlighted from underline to a different colour or something would be nice too.)

Cheers,


/Uffe

[qwerty]

AFAIK there's nothing except sending a feature request.

q.

[Paolo F Cantoni]

The whole Glossary subsystem leaves a LOT to be desired.

The underlying data structure is too simplistic, not just simplistic, but too simplistic.

Perhaps we could discuss what the requirements of a good glossary subsystem might be.

For example, we need to handle singular, plural, singural (my term for forms like: house(s) ) with the same definition.

Paolo

[Eve]

The underlying data structure is too simplistic, not just simplistic, but too simplistic.

Doesn't this contradict your previous assertion that the correct meaning of "simplistic" is "too simple to work properly"? Your definition is qualitative, this usage is quantitative.

[Paolo F Cantoni]

The underlying data structure is too simplistic, not just simplistic, but too simplistic.

Doesn't this contradict your previous assertion that the correct meaning of "simplistic" is "too simple to work properly"? Your definition is qualitative, this usage is quantitative.

Don't think so, I meant what I said.

The underlying model allows only for one term one definition, whereas it needs (at least many terms one definition and ideally a many-to-many relationship).

Whether you want to see it as qualitative or quantitative, the outcome is still the same - it's simplistic.

Paolo

[qwerty]

In a past project we introduced glossary as stereotype of the profile. That opened up a whole lot of new possibilities. Of course the highlighting does not work with that. But as long as machines have no real intelligence I usually don't want those techniques (as they either highlight the wrong words or they miss others).

q.

[Uffe]

Perhaps we could discuss what the requirements of a good glossary subsystem might be.

Say no more! 

I've put some (but not an infinite amount of) thought into this before. So something like this, mebbe?
There are other areas which need some new requirements, eg HTML and doc generation, but this should be enough to get the ball rolling.

/Uffe


DEFINITIONS

Glossary entry: an entry in the glossary, consisting of a term, a type and a meaning.

Homonyms: two or more glossary entries with the same term but different type.

Reference: a glossary entry which only refers to another entry.


REQUIREMENTS -- GLOSSARY TERM MANAGEMENT

It shall be possible to store multiple glossary entries with the same term but different type.

The full definition dialog shall not be editable. Editing a term shall take place in its own dialog.
(Wishing to see the full definition of a glossary term does not imply the desire to modify it, even if the user has that permission.)

References should be represented as follows.
A pre-defined glossary type "GlossaryRef" is introduced, with special handling in the glossary entry editing functions.
A term whose type is "GlossaryRef" shall only be allowed to contain a two- or three-line meaning, where:
    the mandatory first line shall contain the name of a glossary type and nothing else;
    the mandatory second line shall contain the name of a glossary term in the specified type and nothing else;
    the optional third line shall contain a description of the reference, eg "plural of", "abbr of".
Reference descriptions shall not be preset and shall not be interpreted by the software.
(References will be able to refer to other references by specifying the GlossaryRef type in their meaning.)


REQUIREMENTS -- GLOSSARY TERM DISPLAY

For a homonym, the full definition dialog shall display all meanings for the term in full, organized by type.

For a homonym, the tooltip shall display the following:
    If space permits: all meanings for the term in full, with the respective types indicated;
    otherwise, if space permits: all meanings for the term in abbreviated form, with the respective types indicated;
    otherwise, if space permits: an indication that there are multiple meanings for the term, with the types indicated;
    otherwise: an indication that there are multiple meanings for the term.

For a reference, the tooltip shall display the meaning of the referenced entry.
If the reference has a description, the meaning shall be preceded by the description and referenced term on the form "["<reference description> <reference term>"]".
If the referenced entry is itself a reference, the meaning of its referenced entry shall be displayed instead, etc.
A circular reference chain shall result in an error message in the tooltip.
A broken reference chain shall result in an error message in the tooltip.

For a reference, the full definition dialog shall display the chain of references and the meaning of the ultimately referenced entry.

For a term, the full definition dialog shall highlight glossary terms and, on mouse hover, show the glossary tooltip. The term currently displayed in the full definition dialog shall be excepted from highlighting and tooltip in the dialog.
In other words, the highlight/tooltip function shall be the same in the full definition dialog as in other displays, except that the term being viewed shall not be highlighted.


REQUIREMENTS -- OPTIONS

The presentation of reference descriptions in glossary tooltips shall be selectable on/off.

The style of highlighting of glossary terms shall be selectable as one of:
    underlined (default);
    alternate text background colour.

The matching of glossary terms in other windows shall be selectable as one of:
    off (meaning no matching occurs, no glossary terms are highlighted and no glossary tooltips are presented);
    whole-word (default);
    substring.

[Paolo F Cantoni]

Thanks, Uffe!

Really good start!  I'd like to combine what you're saying with what qwerty was saying.

We already have an Onto-Terminological model that relates terms, abbreviations and concepts (as items in the repository) - and then allows direct relationships to other items in the repository.  What we'd like is the extension of the reference concept that links the "meaning" part of the glossary entry to one or more links to our "concept(s)" for that term - that is, it links back into the repository rather than duplicating meanings into the separate table.  That may have been one of your intended uses for the Glossary Reference, but I wasn't sure.

Paolo

[Glassboy]

What about synonyms?

[qwerty]

Synonym -> Same Meaning

What about multi-word glossary terms? And even worse: inflections?

q.

[Uffe]

Hello,


The intent with the specially-handled GlossaryRef type was solely to allow references between two glossary entries, not between a glossary entry and anything else. I feel that would require more substantial changes (ie a stronger integration of glossary and model), while the changes I've outlined here really only augment the existing glossary functionality. For better or worse.

What about synonyms?

Synonyms would be implemented using references; if you wish you could add a description saying "synonym". The description of a reference is optional.

What about multi-word glossary terms?

Multi-word glossary terms are already supported, and the highlighting correctly deals with the situation where one term is a substring of another.

And even worse: inflections?

Inflections would also be implemented with references. I used "plural of" as an example above, here's how that would look in the glossary:

Term	Type	Meaning
Hospital	Building	A big building with patients
Hospitals	GlossaryRef	Building Hospital plural of
Sanatorium	GlossaryRef	Building Hospital	<-- This is a synonym entry; you could add a "synonym" line for clarity

As to making a model of the glossary, I've toyed with that a bit but never used it in anger. I had in mind to develop a profile and Add-In to work with glossary models, but it's up there on the shelf with the other Good Ideas (TM).

/U

[qwerty]

Would be nice to see that in EA. But the Sparxians never had a strength in adopting good ideas coming from outside :-/

q.

[Paolo F Cantoni]

Would be nice to see that in EA. But the Sparxians never had a strength in adopting good ideas coming from outside :-/

q.

I think it was Proctor & Gamble who famously went from "not invented here" to "proudly found elsewhere"  (sometimes also described as PIE - Proudly Invented Elsewhere)

Paolo

[Eve]

The limiting factor for extending the built-in glossary functions is really the database structure in place.

Even with that, I think it makes a lot more sense to model your glossary than to use our glossary list. I would encourage you to implement your ideas as a profile. The management of it is then integrated with all the rest of EA functions (eg. version control, searching, reporting) you get traceability between terms etc.

Once you have that in place I see potential for an add-in to help manage a profile glossary. I can also imagine automation/scripting broadcasts to determine what should be highlighted, how to display a tooltip etc. A flexible solution like that is going to serve the needs of the community much better than any predefined glossary structure defined here.

[David Rains (bioform)]

And yet years have gone by with no action...