Understanding, Using, and Enhancing dash:SubClassEditor

[Marius]

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 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 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.
• 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.
    

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.

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").

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.

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.

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).

[Holger Knublauch]

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.

[Marius]

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

[Marius]

Dear Holger,

I have a follow-up question regarding the custom display label using "rdfs:subPropertyOf rdfs:label".

1. How does EDG decide which of the present label (sub)properties is displayed?
2. How do I tell EDG to use ex:myCustomLabel even if rdfs:label or skos:prefLabel are present in the graph for the same concept at the same time?

I would really appreciate it if you could help me understand EDG's behavior or what I am doing wrong in this regard.

Best,
Marius

My test set up:

• Ontology in Ontology Editor
  
• Includes "SKOS Core" asset and thus the statement  "skos:prefLabel rdfs:subPropertyOf rdfs:label ."
• Includes custom label property: "ex:myCustomLabel a owl:AnnotationProperty ; rdfs:subPropertyOf rdfs:label ."
• Example class from made-up classification:
  

ex:A
  a owl:Class ;
  ex:myCustomLabel "A | Animal" ;
  rdfs:label "Animal (rdfs:label)" ;
  rdfs:subClassOf owl:Thing ;
  skos_core:notation "A" ;
  skos_core:prefLabel "Animal (skos:prefLabel)" ;
.

Based on this class description, I have removed properties to test which properties are displayed in the Class Hierarchy for the following combinations:

• only rdfs:label exists → rdfs:label is displayed
  • Makes sense in my view 
• only skos:prefLabel exists → skos:prefLabel is displayed
  • Makes sense in my view
• only ex:myCustomLabel exists → ex:myCustomLabel is displayed
  • Makes sense in my view
• rdfs:label and skos:prefLabel exist → skos:prefLabel is displayed
  • Makes sense in my view
  • Combination only used for test purposes. In my use case, the vocabularies use either rdfs:label or skos:prefLabel, not both at the same time.
  • Why is skos:prefLabel displayed instead of rdfs:label? Because it's more 'specific' as it's a subproperty of rdfs:label?
• rdfs:label and ex:myCustomLabel exist → rdfs:label is displayed
  • Corresponds to one of my use cases. However, I'd like to display ex:myCustomLabel instead of rdfs:label.
  • Why is rdfs:label displayed instead of ex:myCustomLabel?
  • Why does the behavior differ compared to the combination rdfs:label and skos:prefLabel?
  • How do I tell EDG to use ex:myCustomLabel instead of rdfs:label?
• skos:prefLabel and ex:myCustomLabel exist → skos:prefLabel is displayed
  • Corresponds to one of my use cases. However, I'd like to display ex:myCustomLabel instead of skos:prefLabel.
  • Why is skos:prefLabel displayed instead of ex:myCustomLabel?
  • How do I tell EDG to use ex:myCustomLabel instead of skos:prefLabel?
• rdfs:label, skos:prefLabel, and ex:myCustomLabel exist → skos:prefLabel is displayed
  • Makes sense when looking at the results for the other combinations.
  • Combination only used for test purposes. In my use case, the vocabularies use either rdfs:label or skos:prefLabel, not both at the same time.
    

In the next step, I defined "ex:myCustomLabel rdfs:subPropertyOf skos:prefLabel" instead of "ex:myCustomLabel rdfs:subPropertyOf rdfs:label" to test if the display behavior changes for the combinations listed above. The results did not change. I was thinking that maybe the 'most specific' property is displayed and thus EDG might select ex:myCustomLabel instead of skos:prefLabel since they are no longer siblings. I don't know if this approach would make sense though. It was just a quick thought.

[Holger Knublauch]

Yes we have hard-coded skos:prefLabel to be always used first because some graphs use skos:prefLabel and rdfs:label at the same time.

• rdfs:label and ex:myCustomLabel exist → rdfs:label is displayed
  • Corresponds to one of my use cases. However, I'd like to display ex:myCustomLabel instead of rdfs:label.
  • Why is rdfs:label displayed instead of ex:myCustomLabel?

The algorithm first checks skos:prefLabel then the sub-properties of skos:prefLabel, then rdfs:label and then the sub-properties of rdfs:label.

I could turn the question around: why should it prefer myCustomLabel? This is rather arbitrary.

In general I would find it rather unusual to have labels in multiple label properties at the same subject. This is asking for problems. I know that some people assert the same value for both prefLabel and rdfs:label, but that's basically because some tools understand this kind of inferencing while others don't. But it's redundant and a maintenance nightmare.

• • Why does the behavior differ compared to the combination rdfs:label and skos:prefLabel?
  • How do I tell EDG to use ex:myCustomLabel instead of rdfs:label?

Either don't assert any rdfs:label or give the values of myCustomLabel a higher ranking through their language tag. For example you could give your rdfs:labels no language (xsd:strings) but make all myCustomLabels @en.

But that's a TopBraid-specific hack that isn't clean either. Better to decide on one property only and go with that. You can store extra non-primary labels as skos:altLabel.

• skos:prefLabel and ex:myCustomLabel exist → skos:prefLabel is displayed
  • Corresponds to one of my use cases. However, I'd like to display ex:myCustomLabel instead of skos:prefLabel.
  • Why is skos:prefLabel displayed instead of ex:myCustomLabel?
  • How do I tell EDG to use ex:myCustomLabel instead of skos:prefLabel?
• rdfs:label, skos:prefLabel, and ex:myCustomLabel exist → skos:prefLabel is displayed
  • Makes sense when looking at the results for the other combinations.
  • Combination only used for test purposes. In my use case, the vocabularies use either rdfs:label or skos:prefLabel, not both at the same time.
    

See above, I wouldn't have multiple values.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/139d2842-cfc6-4fa9-bef7-fee68d820e9an%40googlegroups.com.