Several comments regarding better visualization

[jbkoh]

• What is "schema" compared to "properties"? I loaded our internal ontology and all the properties are repeated at the schema. I'd like to understand the reasoning behind "schema" and possible hide it optionally?

• I see stars and question marks left to every property. Could you explain what they mean?

• Can we make the tree frame horizontally configurable? If the hierarchy is too deep, the text gets ugly. E.g.,
  

• I agree with filtering out less important classes #1 and maybe we can specify the top level classes we are interested in inside package.json and ignore the rest in the tree view?

• I have properties whose values are actually an enum (and I'm surprised that those are well-visualized!) but the number of values of the enum can be long. Can we make each cell collapsible if it's too long?

For all those questions above, I'd be happy to ask my company's engineer to contribute if you can share any pointers.

[epaulson]

I'm also very keen to help on this - I'd especially like to factor out the navigation sidebar content from each file and have it be a loaded asset that some javascript can pull in to cut down on the overall size of the static site. (Happy to open a new issue for that)

I know enough vue.js to be dangerous but it's probably not too hard to do this without a framework.

[ektrah]

• What is "schema" compared to "properties"? I loaded our internal ontology and all the properties are repeated at the schema. I'd like to understand the reasoning behind "schema" and possible hide it optionally?

Both are views of the same data. I find it useful to have both: the compact summary to quickly grasp what's there, and the detailed list including all inherited properties. It would of course be possible to introduce some configuration options to hide one or the other. That would be a simple if (...) e.g. here. The slightly tedious part would be to pass the configuration option from where the configuration file is read through the entire call stack to this point. I'd be happy to give more pointers for this.

• I see stars and question marks left to every property. Could you explain what they mean?

If you hover over it, you should see a tooltip with "zero or more" for stars and "optional" for question marks. So it is an indication of the cardinality of the property; see here. Suggestions for improvement are welcome 🙂

• Can we make the tree frame horizontally configurable? If the hierarchy is too deep, the text gets ugly.

A simple fix would be to enable the horizontal scrollbar for the panel, but I personally always find that awkward to use. It would be really nice to have a draggable divider that allows the user to change the size of the panel. That would need to go in here. (Another view is that you just have too many levels of inheritance 😉)

• I agree with filtering out less important classes #1 and maybe we can specify the top level classes we are interested in inside package.json and ignore the rest in the tree view?

Currently, the code here creates a tree structure from a list of classes and their parents and returns the set of tree nodes that have no parents. It shouldn't be too difficult to extend this to return a different set of tree nodes.

• I have properties whose values are actually an enum (and I'm surprised that those are well-visualized!) but the number of values of the enum can be long. Can we make each cell collapsible if it's too long?

Sure; that would have to be added here.

For all those questions above, I'd be happy to ask my company's engineer to contribute if you can share any pointers.

That would be very much appreciated! 😃

@epaulson: Yes, please open a new issue for this

[epaulson]

See #6 for taking a stab at setting the top-level classes