Hi Holger, Thanks a lot for your timely and clear response. I now know the next steps, will discuss them in my organization, and if applicable, open corresponding tickets via the support portal.
Best, Marius Holger Knublauch schrieb am Dienstag, 11. Januar 2022 um 05:15:23 UTC+1: > Hi Marius, > > yes this is one place to ask such questions. > On 2022-01-11 12:31 am, Marius wrote: > > Hi, > > I would like to understand and use the dash:SubClassEditor better ( > https://datashapes.org/forms.html#SubClassEditor). > I assume that most of the items listed below are rather feature requests. > Nevertheless, I'm asking in case I'm overlooking how to implement/configure > them using the already available TopBraid EDG features (version 7.0.3). > > This is my first post in this Open Forum and I hope it’s the right channel. > Thanks in advance for any feedback and help. > > Best, > Marius > > *Context: *I have set up knowledge, shape, and data graphs so that data > graph editors can link instances to classes, which are defined in separate > classifications (included ontology assets), using the SubClassTree editor > within the Form panel. The items below are mainly motivated by improving > the user experience for the data graph editors through GUI customizations. > > *Are the following items currently feasible and, if so, how?* > > *1. Custom display labels for classes:* > > - As I understand it, the classes in the hierarchy tree of the > SubClassEditor are labeled using the rdfs:label or skos:prefLabel > properties in the applicable interface language such as @en. > - Is there a way, to set a different property as display label? > > The system will look for any rdfs:subPropertyOf rdfs:label here, so if you > have stored the labels in another property then you'd need to declare that > property rdfs:subPropertyOf rdfs:label. Note however that the UI for class > creation will assume rdfs:label. > > > - The users of my data graph, for example, would like to see both > notation and label of the classes (instead of just the label). For > instance, *<skos:notation> <separator> <skos:prefLabel>* such as "*I21 > | Acute myocardial infarction*". > > In this case you probably ask whether the label can be inferred. This is > not possible with the auto-complete widget because that widget relies on a > look-up index of labels, so if the labels are dynamically assembled from > somewhere then this would be too hard to maintain correctly. I am afraid > this would require a custom editor, e.g. based on a normal HTML <select> if > you really want to support that. Or assert the combined labels as real > triples, of a subproperty of rdfs:label as above. > > > - In my case, overwriting the original rdfs:label or skos:prefLabel > with my custom display label is not an option. > - Ideally, the custom display label is generated ad-hoc when > generating the GUI without having to store it persistently. In my case, it > would also be ok if I created a new property for the custom display label, > created the custom display labels using SHACL/SPARQL, and stored them in a > graph. > > Yes that's the only option that I see right now, see above. > > > - This requirement does not only refer to the hierarchy tree of the > SubClassEditor, but to the display labels of classes in EDG in general. > The > editors of my data graph would like to see the custom display label in the > Form panel as well. > - I tried to implement this by creating a new custom display > property and defining it as dash:LabelRole ( > https://datashapes.org/propertyroles.html#LabelRole), but failed. > The GUI still displayed rdfs:label or skos:prefLabel instead of my > custom > label. > > Try rdfs:subPropertyOf rdfs:label. > > *2. Show classes in hierarchy tree in specified order:* > > - As I understand it, the subclasses of the specified dash:rootClass > are displayed in alphabetically ascending order of labels (rdfs:label or > skos:prefLabel). > - I would like to display the classes in alphabetically ascending > order of notations (skos:notation) instead. > - Motivation is that users of my data graphs expect classifications > (such as the *Anatomical Therapeutic Chemical Classification System* > or the *International Classification of Diseases*) to be displayed in > their notation-based structure, not in alphabetical order of concept > labels. > - This problem might be solved if I could implement item 1, but only > if I put the notation first in the custom label. Since I might put the > notation at the end of the custom label, this workaround would not be a > proper solution for item 2. > > Yes, if you can construct labels that happen to also be sorted > alphabetically then this should be solved. Otherwise, again a custom widget > appears the only solution. > > (Like with most feature requests, TopQuadrant staff can help through > professional services or premium support.) > > *3. Show hierarchy by specific hierarchy property:* > > - As I understand it, the hierarchy tree of the SubClassEditor is > displayed based on rdfs:subClassOf. > - While this is adequate in most cases, there are vocabularies which > use other properties such as ex:isA or ex:isPartOf to represent > hierarchies. Is there a way to set a specific property by which the > hierarchy tree of the SubClassEditor is displayed? (perhaps along the > lines > of "ex:myPropertyShape dash:hierarchyProperty ex:isA" similar to > "ex:myPropertyShape dash:rootClass ex:myRootClass"). > > No, SubClassEditor is only designed for class hierarchies. A custom widget > can be developed. > > *4. Jump to already selected class when clicking on class tree icon:* > > - When editing in the Form panel, if one clicks on the class tree icon > to revise an already established link, the pop-up window of the > SubClassEditor displays the hierarchy tree collapsed (the root class and > its subclasses). > - Users of my data graphs would prefer to see the concept already > selected in the hierarchy tree instead, i.e. the hierarchy tree expanded > from the root class to the selected class. (For comparison, this is how > the > Class Hierarchy panel behaves when clicking on a class in the Form panel > in > the Ontology Editor). > - For polyhierarchical classifications, it would be nice to have all > paths expanded from root class to selected class. > > I see what you mean. This currently always starts at the root. I have > recorded an internal ticket (tracking number TBS-4444) to improve that. > > *5. Enable multi-selection:* > > - Users of my data graphs would like to select multiple classes via > the class tree editor (without having to add a row each time via the plus > icon). > - As far as I know, multi-select is currently not possible, but > already as a requirement in TopQuadrant’s backlog. > - I would like to emphasize that I would appreciate multi-selection > not only for the "Find a Resource" dialog (magnifying glass icon) but also > for the "Select a Class" dialog (class tree icon) of the SubClassEditor. > > Right, we have this on the backlog somewhere. It's hard because the way > that our widgets are wired is that they represent one value each. Also, our > trees don't support multi-selection elsewhere. > > *6. Enable quick search in hierarchy tree*: > > - As I understand it, the class tree in the SubClassEditor can only be > navigated by clicking to expand branches. > - Users of my data graphs would appreciate an additional quick search > (for comparison: as enabled by the Quick Search in the Class Hierarchy > panel of the Ontology Editor). > > Ok another feature request that makes sense in principle. You will > understand that we are receiving many feature requests and have limited > staff. So we need to prioritize. As I indicated above, one way forward > would be to open a TSM support desk ticket (instead of an email here to the > public list) where we can see which customer organization you are from and > discuss possible ways forward. It seems like these UI improvements would > make quite a difference to your users, but we need to balance this with > other requirements. > > Regards > 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/b4683bd7-0d51-4166-bb1c-ef38ba3761ccn%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/b4683bd7-0d51-4166-bb1c-ef38ba3761ccn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b83316f7-660b-4958-9f9a-446ac2458eb9n%40googlegroups.com.
