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.
Marius schrieb am Dienstag, 11. Januar 2022 um 09:34:37 UTC+1:
> 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 [email protected].
>> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/139d2842-cfc6-4fa9-bef7-fee68d820e9an%40googlegroups.com.
