Sparx Systems Forum

Enterprise Architect => Bugs and Issues => Topic started by: Uffe on March 16, 2017, 10:42:38 pm

Title: Glossary matching options
Post by: Uffe on March 16, 2017, 10:42:38 pm
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
Title: Re: Glossary matching options
Post by: qwerty on March 17, 2017, 08:41:48 am
AFAIK there's nothing except sending a feature request.

q.
Title: Re: Glossary matching options
Post by: Paolo F Cantoni on March 17, 2017, 10:55:40 am
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
Title: Re: Glossary matching options
Post by: Eve on March 17, 2017, 02:42:34 pm
Quote from: Paolo F Cantoni on March 17, 2017, 10:55:40 am
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.
Title: Re: Glossary matching options
Post by: Paolo F Cantoni on March 17, 2017, 06:22:24 pm
Quote from: Simon M on March 17, 2017, 02:42:34 pm
Quote from: Paolo F Cantoni on March 17, 2017, 10:55:40 am
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

Title: Re: Glossary matching options
Post by: qwerty on March 17, 2017, 08:44:53 pm
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.
Title: Re: Glossary matching options
Post by: Uffe on March 17, 2017, 09:16:08 pm
Quote from: Paolo F Cantoni on March 17, 2017, 10:55:40 am
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.
Title: Re: Glossary matching options
Post by: Paolo F Cantoni on March 20, 2017, 11:05:23 am
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
Title: Re: Glossary matching options
Post by: Glassboy on March 20, 2017, 02:53:03 pm
What about synonyms?
Title: Re: Glossary matching options
Post by: qwerty on March 20, 2017, 05:47:29 pm
Synonym -> Same Meaning

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

q.
Title: Re: Glossary matching options
Post by: Uffe on March 21, 2017, 08:16:50 pm
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.

Quote from: Glassboy
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.

Quote from: qwerty
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.

Quote from: qwerty
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:
TermTypeMeaning
HospitalBuildingA big building with patients
HospitalsGlossaryRef    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
Title: Re: Glossary matching options
Post by: qwerty on March 21, 2017, 08:27:43 pm
Would be nice to see that in EA. But the Sparxians never had a strength in adopting good ideas coming from outside :-/

q.
Title: Re: Glossary matching options
Post by: Paolo F Cantoni on March 22, 2017, 10:29:15 am
Quote from: qwerty on March 21, 2017, 08:27:43 pm
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
Title: Re: Glossary matching options
Post by: Eve on March 22, 2017, 10:45:44 am
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.
Title: Re: Glossary matching options
Post by: David Rains (bioform) on July 31, 2019, 07:13:16 am
And yet years have gone by with no action...
Title: Re: Glossary matching options
Post by: qwerty on July 31, 2019, 08:22:25 am
I'd do as Eve suggested. EA has (I mentioned that elsewhere) which are half baked. A sales disease. Anyhow, I once modeled my own glossary which also had the capability to be multi-lingual (a feature which tends to bite back where you don't expect it, so better not to be really used). But having <term> and <definition> lets you create your own glossary at the end of a document (at least if you use your own document generator like me). Admittedly, it would be smart to see EA offering such a generic way rather than that home brew glossary. Finally attaching that highlighting mechanism would have been really smart. UML is such a nice language. But well...

q.
Title: Re: Glossary matching options
Post by: timoc on August 03, 2019, 08:10:06 pm
Quote from: Eve on March 22, 2017, 10:45:44 am
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.
Can i ask why there is a limitation with regards to database structure changes?
Title: Re: Glossary matching options
Post by: timoc on August 03, 2019, 10:30:13 pm
My 2eurocent on the topic.

I had a different idea which i submitted to sparx about about the glossary feature - essentially extending the 'glossary' to a 'generic link' style, like you might see in a wiki. That way you make all of a model addressable from the text, and can define the word in the visual context of a diagram.

The implementation of the idea i had in mind, which should not require database changes per-se, is essentially using a regular expression to match to an EA URI type link.  e.g. "/matchthis/EA-uri:link/". This idea can solve these other issues by allowing yoiu to explicitly match to the correct glossary item with "/pluralmatch/glossary-uri:singluar link/'.