Classes not seen in Class viewer after opening file.

[Derek S]

I have opened a file with 133K classes. No errors reported, but I can't see all the classes in the class navigator. Other symptoms:

(i) If I search for a specific class that is not present in the navigator the search is returned, but if I click on a class from the search result window, then the search result window closes and I'm returned to the class navigator and the previous current class.

(ii) if I save the file from TBC as another name and check it with vi, all the classes are present.

So the import is fine, all the classes are loaded, but not visible in the navigator. I seem to remember that the navigator only shows a limited number. Is it possible for it to show all the classes?

[Richard Cyganiak]

Hi Derek,

There is a preference at:

    Preferences > TopBraid Composer > Max. number of instances to display

This affects the class tree even though the name refers to instances.

I doubt it will work for 133k classes.

Richard

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/731b5495-8b5d-42db-897e-a76d89d23f5d%40googlegroups.com.

[Derek S]

Apologies for the slow reply. Thanks for details. 

This doesn't seem to be a problem in Protege. I'm working on other ontologies with 300k+ classes (in the main these are converted from OBO, so have a class explosion when converted to OWL). However, it's not an uncommon practice in biology. Is there an architectural difference between TBC and Protege, that allows a greater number of classes in the entity navigators?

[Holger Knublauch]

The default number of nodes that TopBraid Composer displays in trees is limited to what we observed to be realistically handled by the underlying UI libraries (which in our case is https://help.eclipse.org/2019-12/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjface%2Fviewers%2FTreeViewer.html). Other frameworks may scale better, but that's nothing we can realistically work around. In any case, having a tree display hundreds of thousands of sibling nodes sounds a bit steep. I guess you'd really just want to navigate to certain nodes, and that could be achieved by tabular views too. Have you tried to increase the "Max. number of instances to display" in the TBC preferences?

Holger

--

You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2221ed07-67f4-4c6e-ae4e-6f350ae45dfb%40googlegroups.com.

[Irene Polikoff]

To add to what Holger says, you may get better results in EDG than in TBC because EDG builds and maintains Lucene indexes for search and autocompletion. 

The class tree may or may not scale better - it depends on the nature of the hierarchy. If you have thousands of siblings under the same parent, the tree will not give you a very useful view. However, in EDG, you also have an option of using the class list panel. As in TBC, this panel, by default, is limited to presenting 1K results. You can increase this default to 5K or 10K without much (in my experience) performance degradation. Importantly, you can enter text search criteria which will filter the result set to the resources that match it. As Holger says, simply scrolling through hundreds (or even tens) of thousands entries is not something any user would want to do. Ultimately, you probably just want to be able to navigate to the resources you are interested in and see their information.

As an aside, I find that proliferation of classes in the bio ontologies is often very questionable. Too often, these are not classes in a traditional sense. In other words, it is not clear what are the instances of these classes and there are no definitions that would describe the instances and differentiate instances of one class from another. In reality, these classes are simply vocabulary concepts. Most likely, this is a baggage from the OBO formalisms that do not support instances, so by necessity everything is a class. For use in applications, it is very common to transform these classes into instances.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d3996c27-eee7-fd23-86de-50215de26305%40topquadrant.com.