-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When using isothes:superGroup + skos:member, the parent group information is duplicated #433
Comments
Thanks for raising the issue. I've myself wondered about the relationship between skos:member (between skos:Collections) and iso-thes:superGroup/subGroup. They are not formally related at all, but both can be, and are being, used for creating a hierarchy of Collections/Groups. Maybe this should be raised on the SKOS mailing list (public-esw-thes)? I'd like to hear if there are opinions and advice on which one should be preferred (in which situation), and whether using them both at the same time, as UNESCO Thesaurus for example seems to be doing, even makes sense. |
I wrote about this to public-esw-thes: https://lists.w3.org/Archives/Public/public-esw-thes/2016Jan/0012.html Let's see if there are any opinions. I'd especially like to hear if one or the other is obviously better, so that Skosmos could for example preferentially expose the "better" modeling. Though I suspect it's not going to be so clear-cut. |
Thanks for your feedback.
|
The short discussion on public-esw-thes didn't really go anywhere but I'd suggest the following: If two groups/collections are linked using both skos:member and isothes:superGroup/subGroup, suppress showing the skos:member relationship as if isothes:subGroup were a sub-property of skos:member, though it isn't officially. So in the above screenshot, "SUPER GROUP" would be shown but "BELONGS TO GROUP" would disappear. |
Thanks. I agree with your suggestion. |
I have thesaurus data mixing standard SKOS data + isothes extension. Group/subgroup inclusion is declared both using skos:member and isothes:subGroup + isothes:superGroup.
In that case, on a group page, the parent group is shown twice :
First line corresponds to isothes:superGroup property, second line corresponds to the inverse of skos:member.
This is not really "incorrect", but quite disturbing for end-users.
I thinks when detecting isothes properties, the skos:member information should be hidden is already expressed in isothes.
The text was updated successfully, but these errors were encountered: