-
Notifications
You must be signed in to change notification settings - Fork 34
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
ISSUE-125 Use wikidata to provide skos:definition to owl:Class'es #208
Conversation
I did not do a complete pass through all the suggested Wikidata definition mappings. I suspect there are other defs that should be rejected... I can work on that but it will take a few days. |
@smrgeoinfo ... no problem. I am in no rush to close this issue. If and when you can review, please do. Thank you |
link to spreadsheet for convenience I'll start from the last entry and work my way up (as I have time this weekend). |
Have you looked at Chris Mungall's sparql-prog tool for wikidata?: https://github.com/cmungall/sparqlprog_wikidata It may help mine data from Wikidata. |
Excellent @rrovetto thank you so much. I'll incorporate these into the solution when I get a minute. |
@lewismc are the previous iterations of SWEET available on COR? i ask because, from memory, there were previously Wikipedia definitions in SWEET. I'm not sure which version, or why they were removed, but they may be useful for disambiguation in this task. |
Just had a look --- apparently I still have a local copy of at least a few previous versions of SWEET :) On a quick grep through, it appears that there was text in the There is no link, version, or any other information, but there is text which could be compared using a similarity function which may, at minimum, rule out the non-domain faff. Does this help, or hurt? :) |
Yes, for any given resource just navigate to the |
Hi folks, any further comments here? Thank you |
It's still on my radar. Haven't had time to dig into it properly. |
Discussed on today's SemTech call. General feeling - as long as this doesn't overwrite the work done by the Semantic Harmonization and the issue of label/domain matches (see below), then we can move forward. Things should be clear as long as we're clear who (e.g. Wikidata, ENVO) is making the definitional claim (e.g. by annotating the definition annotation property). The issue of a lack of domain matching in favour of simple label matching presents a major issue - some are simply wrong. Suggestions to split this PR into a realm-by-realm task may be better to focus work and spot issues in a contained space. |
Now that #211 is resolved. I will revisit this issue and update the conflicts. |
If interested, we could sort out #218 first and then work on developing a more intelligent filter for matching and generating results. |
Yes Brandon... excellent idea --
*Lewis*
Dr. Lewis J. McGibbney Ph.D, B.Sc
*Skype*: lewis.john.mcgibbney
|
Nice work @brandonnodnarb I'm happy to close this one off and regenerate the PR. |
I think we should also push 3.5.0 once we have merged this into master branch. |
This issue addresses all prior suggestions contained in related PR's #205 #203 #202 #201 and #200.
@smrgeoinfo it also removes all spurious definitions as you had highlighted.
@brandonnodnarb this addresses of all the issues you pointed out.
Please review and provide any feedback. Thanks