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
o Makes sense in my view
* only skos:prefLabel exists → skos:prefLabel is displayed
o Makes sense in my view
* only ex:myCustomLabel exists → ex:myCustomLabel is displayed
o Makes sense in my view
* rdfs:label and skos:prefLabel exist → skos:prefLabel is displayed
o Makes sense in my view
o 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.
o Why is skos:prefLabel displayed instead of rdfs:label? Because
it's more 'specific' as it's a subproperty of rdfs:label?
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.
o 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
<https://groups.google.com/d/msgid/topbraid-users/139d2842-cfc6-4fa9-bef7-fee68d820e9an%40googlegroups.com?utm_medium=email&utm_source=footer>.
