I agree with all these criticisms of the information in Wikidata. There are quite a few important classes in Wikidata where there are missing, questionable, or incorrect structural data. Look at colors (instances of Q1075), where some colors are both instances and subclasses of color; or ships (instances of Q11446), where some ships are subclasses of ship; or the superclasses of geographic region (Q82794), which include set; or the instances of woman (Q467), of which there are only 28.
I believe that these structural problems in Wikidata are a major, probably the major, reason that Wikidata does not have considerably more uptake than it currently does. Certainly every time I think of using Wikidata I have to think hard about what I need to do to ensure that the structural problems in Wikidata will not pose too much of a problem for my use. (In most cases I come to the reluctant conclusion that they will.)
It's not so much that there are examples of bad structural data, it is that examples are so easy to find. And it's not so much that the problems arise from bad policies, it is that there are no enforced policies. And it's even not so much that these are unknown problems as most of them have been previously reported.
It is for the above reasons that I believe that lack of tool support is not the major driver of the problems, and certainly tools that can only point out problems are not going to be a significant help in solving the problems. Instead I believe that what is driving the structural problems with Wikidata is that there is insufficient effort paid by the Wikidata community to identify and implement fixes for the structural problems. Tool support is important, I agree, but without people in the Wikidata community putting a higher priority on fixing data in Wikidata than even adding more data to Wikidata structural problems will continue.
I also feel that it does very little good to ask people who are adding new data to Wikidata to only create data with good structure when there are so may existing problems. Instead the existing problems first need to be fixed up. This will both show that the Wikidata community cares about good structure and show people who are adding new data how new data should be added instead of the current situation which in too many cases provides examples of how not to structure data. Consider a tool that retrieves items that are similar to an item being added. If this comparison item has bad structuring nearby it is very likely that the new item will be either given similar or linked to the existing bad structuring.
As far as labels, descriptions, and aliases go I agree that the current situation is poor. But what I believe is missing most is enough description that the intent of an item, particularly a class, can be correctly determined. I often end up with only a poor idea of what items should be an instance of a class, particularly when considering several classes at once. The various geographic classes are a prime example here for me. In my view many of the natural language information associated with Wikidata items should be tagged with the English Wikipedia multiple issues template.
Queries that show the above problems:
SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q1075. ?item wdt:P279* wd:Q1075. SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }
SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q11446. ?item wdt:P279* wd:Q11446. SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }
SELECT ?item ?itemLabel WHERE { wd:Q82794 wdt:P279* ?item . SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }
SELECT ?item ?itemLabel WHERE { ?item wdt:P31/wdt:P279* wd:Q467. SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }
Peter F. Patel-Schneider