Flat concept maps – Aliases – Group and Branch Root Nodes
We have recently deployed a significant performance improvement, particularly
when it comes to “flat” concept map structures.
Here more details about these news!
Regards – your Coreon Team
Fast Browsing through Thousands of Siblings
Imagine … from the very beginning you had worked in Coreon and your data allows you to always create manageable clusters of max, say, 20 to 30 narrower concepts, you add nested and nested structures and have always a nice tree … imagine …
Well, in real life, you probably will have to look at not only 30 but several hundred siblings underneath one broader concept. Or you just started with Coreon and now imported a flat list of concepts, a flat TBX file with many thousand concepts. And these thousands concepts are now all stored as siblings besides each other. And then you click the (+) button in the concept map … then – up to now – it would have taken quite some time until the data loading has finished. This is, rather “was”,
a true performance weakness when working with such “flat” structures.
We have resolved this challenge. We have introduced a so-called pagination logic when sets of concepts are sent from the server into your browser. This reduces the amount of data sent around, makes the whole application behaviour more light-weight. Though, to achieve this we had to touch all areas that affect the sorting of concepts: how concept headings are computed, how aliases are stored, how the information about “group” and “branch root” concepts is stored.
This is now achieved. Experiences from the beta phase show that as soon as you are in a context with more than 50 sibling concepts you should already notice an improvement. If you are in a context with more than 150 concepts (or even several hundred) then the improvement is significant.
You will notice it mainly in the following situations:
- Browse narrower concepts (by type) – in the concept’s Broader-Narrower area as well as in the Concept Map widget: you will notice that when on bottom of say 20 concepts the next set of concepts is retrieved (but only then, instead of all together)
- Save terms / concepts – when saving a term, the concept is resorted triggered by the change, followed by retrieving all its siblings. Which is now faster.
Mark a Concept as a ‘Group’ or ‘Branch Root’
Triggered by above mentioned change of the sorting logic we had to touch the alias management, and the ways to store whether a concept is a group concept and/or as a branch root.
For maintainers therefore, we have one noteworthy change when editing: The ways to mark a concept as a group or branch root are no longer shown as a simple concept property (and no longer mixed with real content carrying concept properties). Rather these two switches show up on the very top of the
concept editor.
Re-Index Repository
As you may know, the so-called Rating rules – configured in the repository dashboard – have an effect how concepts are sorted. Now, with above changes to improve the performance, the sort index requires to be re-written when changing the rating rules as well as when changing the configuration of the repository model. Therefore, in the repository dashboard you will now find a way to re-create this sort index (it is automatically selected when you changed one of these configuration settings).
Note: In your daily work you probably will touch this functionality very rarely, since the configuration of a repository doesn’t change that often.
Miscellaneous
Overall this release covers 50+ backlog items. Amongst the further noteworthy changes are:
Anything Aliases
- Alias – referent editing: When deleting a referent, an alert is shown as soon as there are still aliases pointing to this referent.
- Alias vs. Concept counting: Above mentioned rework of the alias management, allows now to count aliases separately from the “real” concepts. This is already reflected in the repository statistics and export / import job figures in the dashboard.
- Export an alias: Option to select whether to force the inclusion of its referent (even when the referent may be filtered out)
And also …
- Relations editing: Fail to create a broader alias relation when dragging and dropping the alias from the clipboard. This has been fixed.
- Sorting: Invisible markdown characters (like an asterisk or underscore) within terms are influencing the sort algorithm. This has been resolved, formatting characters no longer influence the sorting.
- Access control: When you have access rules set up (such as: hide a given property for some users) occasionally in search results as well as alias contents, the property value was unexpectedly shown. This was a caching issue and has been resolved.
- Export: When creating a new template the settings whether to include admin data, markdown syntax, and selected filters was not stored. You had to re-apply them when using the template. This has been fixed.
- Applying a snapshot: A progress indicator is now also shown.
- Coreon XML Schema (
coreon.xsd) has been updated to reflect the changes on alias, group concept, and branch root modeling. Note: the previous version of coreon-xml continues to be fully supported when importing into a repository.
