Problem: I have many items on my watchlist in Wikidata and I'm only able to evaluate the quality of edits of labels/descriptions/interwikilinks in German and English. Yet whenever there are changes in another language on the items I watch they show up and clutter my watchlist.
Who would benefit: All Wikidata editors who use the watchlist.
Proposed solution: Allow users to filter out changes in the watchlist that aren't in the languages in their babel box.
I support this request. The main issue is with added descriptions/aliases of other languages which I don't speak (Side benefit for this request: filtering out recent changes entries => less purges/reparsing?). eranroz (talk) 18:16, 10 November 2018 (UTC)[reply]
Problem: Repost since this is still a problem: The edit summary for this diff does display that a reference was added, but not which reference it is. References can be unreliable, spam links etc. so having them be easy to monitor is desirable.
Who would benefit: People who patrol Wikidata items for problematic edits, since the content of the diff is immediately displayed.
Proposed solution: Add the content of the reference to the edit summary; in this case it would be "Added reference (imported from:English Wikipedia) to claim: mountain range (P4552): Andes (Q5456)"
More comments: I hope that this isn't too late. This feature would be useful as well if it displayed in crosswiki watchlists. There may be length issues when the reference is long.
Neutral A single reference on Wikidata may contain more than one property-value pair and all of them can be added at once. Enumerating all of them (if not all, which one? the first/last one?) in the edit summary may be undesired. Matěj Suchánek (talk) 10:33, 25 November 2018 (UTC)[reply]
Problem: Currently Wikidata do not sort claims of a property and it could cause terrible mess. Many templates on a lot of Wikipedias load their parameters from Wikidata, so there are thousands of articles where parameters (e.g. awards) aren't in ordinal scale (but they should be). Fixing is very hard or almost impossible, because the only way to do it is deleting and re-adding every claims.
It would be great and will simplify reading of some properties having multiple values. I’ve written a script specifically for software version identifier (P348) but a Wikibase-integrated solution would be better. I just added some ideas in the Phabricator task, basically to allow editors to define themselves the order instead of hardcoding it in Wikibase. ~ Seb35[^_^]12:17, 4 November 2018 (UTC)[reply]
Support I would like to see this, but take into account that some claims should be sorted by other qualifieres (see my note above). U+1F360 (talk) 21:04, 19 November 2018 (UTC)[reply]
Support Yes, we should be able to specify different ordering for different properties: by date qualifier, alphabetically, or by some other qualifiers. Jarekt (talk) 05:18, 25 November 2018 (UTC)[reply]
Problem: Wikidata can only link one article per language. There are, however, cases where a single article in one language corresponds to two articles in some other language. A prototypical instance is Bonnie and Clyde, with most languages having an article about the duo Bonnie and Clyde, some having an article about Bonnie Parker, and some having an article about Clyde Barrow (see also d:WikiProject Cross Items Interwikis). The articles about the individual bank robbers cannot (at least not both) link to the many articles about the duo, which exist in many languages, so it is hard to find the corresponding articles in those other languages when coming from such a single-person article. (Other relevant situations I can think of are misfitting taxonomies; while e.g. in biology the international research community has agreed upon a common hierarchy, this is not the case in many other fields, where it might turn out to be unclear or questionable which term in another language an article should be linked to when there is no perfect match.)
Who would benefit: Potentially all readers, exact number of relevant cases unknown so far
Proposed solution: While allowing Wikidata items to link more than one page per language is probably not a viable option, having language links as displayed in Wikipedia side-bars link to more than one article in another language should be principally possible. A language link to a language version in which more than one article is linked to the current one could, for instance, show a pop-up menu instead of directly navigating to the foreign-language article in question. More important than the GUI design for this feature would be the question where to take the target articles from. In the case of Bonnie and Clyde, a language link connecting Bonnie Parker articles (or Clyde Barrow articles, respectively) with Bonnie-and-Clyde articles could be obtained from the ‟part of” relation (d:P361). A sufficiently general solution would perhaps allow for a set of relevant Wikidata relations, to be determined by the Wikidata community, that are used to populate ‟multiple” interwiki connections of the proposed form. Even if the ability to have ‟multiple” interwiki connections is undesired, the Wikidata relations could still be used to connect articles to languages for which a direct equivalent has not yet been registered in Wikidata (either because a corresponding artcile has not yet been linked or because such a corresponding article does not yet exist).
I am unadopting that proposal in order to adopt another proposal, now that someone have created a similar proposal. If someone think the proposal that I wrote would be better than this proposal then they're welcome to adopt it. C933103 (talk) 01:20, 9 November 2018 (UTC)[reply]
I don't think P361 is sufficient for determine the display of multi interlanguage link. For instance New York is Part of the USA but I don't think many would want to see such interlanguage link when there are no direct correspondence. Additional properties could be created for situation that would match this. C933103 (talk) 01:32, 9 November 2018 (UTC)[reply]
If this is done, I think it would also be beneficial to fix these links for wikis which use multiple different untranslatable scripts or dialects (i.e. wikis which use permanent duplicated item (P2959)), perhaps by allowing a set number of interwikis for each wiki (e.g. one each for hak-Hant and hak-Latn). Jc86035 (talk) 12:31, 11 November 2018 (UTC)[reply]
Given that the AfC for allowing redirect was just closed, it's now possible to solve one way of the Bonnie-and-Clyde problem.
I don't think the other way should be done via a property based way. Lets say we have en:"Bonnie"->de:"redirect:Bonnie-and-Clyde" and en:"Clyde"->de:"redirect:Bonnie-and-Clyde" but no existing link from the de:"redirect:Bonnie-and-Clyde" to English. We could have a plugin that provides a page that lists en:"Clyde" and en:"Clyde" that gets automatically generated (e.g. no Wiki page) when a user clicks on `English` in the interwikilink list. ChristianKl ❪✉❫ 18:38, 14 November 2018 (UTC)[reply]
The problem of P2959 related to, however independent from, the problem we are talking about here. With a full overhaul to the wikidata structure, both problems will be solved immediately, however it seems like no one is actually willing to spend serious efforts on improving wikidata, I guess we have no other choice than to accept that only minor improvement will be made and hope that it will become more useful after accumulating all the minor improvements after a decade or so. From this perspective, the proposal doesn't goes against resolving the problems related to P2959. Hence SupportC933103 (talk) 07:04, 17 November 2018 (UTC)[reply]
Partial Support. I support this proposal in the sense that the issue needs to be looked into and be resolved within reasonable time, yet not necessarily in the exact same manner as suggested by the proposal. --Beat Estermann (talk) 16:33, 18 November 2018 (UTC)[reply]
Support with "FYI: The Wikidata folks say that they could commit to analyze and solve the problem, but not necessarily with the solution offered here. Ryan Kaldari (WMF) (talk) 23:08, 14 November 2018 (UTC)" in mind. Topper13009 (talk) 20:34, 21 November 2018 (UTC)[reply]
Problem: At the present moment Petscan allows the user to input one or more categories of one single project (e.g. en.wikipedia, it.wikipedia ...) and a depth (e.g. 0, 1, 2 ...) and find all the items containing one sitelink which bellongs to this category or its subcategories. However, the user has to input one by one all the categories regarding the same topic in different projects (e.g. en.wikipedia - Ancient Greece, it.wikipedia - Antica Grecia ...; the most important categories exist in tens of projects!) and cannot easily compare the results for each project.
Who would benefit: Wikidata users who try to find and merge duplicates (the user can explore in one single list all the items belonging to the same categories in all the projects); Wikipedia users who want to translate articles regarding a specific topic (the user can see in one single list all the items regarding this topic in all the project)
Proposed solution: The main idea is the possibility to explore at the same time all the articles belonging to a category which is common to two or more projects: in my opinion, the best option would be integrating this function into Petscan, but it may also be a new independent tool. The tool should be like this: the user inputs a category item (e.g. d:Q7215882) and a depth (e.g. 0, 1, 2 ...); given these inputs, the tool should give a list of all the items containing at least one sitelink which belongs to a category that is a sitelink of the category item. Possible filters: by type of project (all projects; only Wikipedias; only Wikisources ...); by the date of the articles' creation.
Problem: We do not have items for many ISO/ASTM/EN... standards. This is usefull for projects because these standards list the official names and definition of some other items such as material properties.
Who would benefit: Wikidata projects and the community as a whole.
Proposed solution: Write a script that crawl ISO/ASTM/CEN sites for standards metadata.
Comment@Thibdx: I already have a simple scrapy script that dumps ISO data into a CSV file. The time consuming part is not having a model for ISO standards, and not having an easy and efficient way to write data back into Wikidata (one edit per item with multiple statements, not Pywikibot's one edit per minor change). You can copy and have a look at the spider (especially the xpath rules) at [1]. Dhx1 (talk) 12:46, 19 November 2018 (UTC)[reply]
Oppose; there is basically nothing for Community Tech to do here – users can already import this data themselves, and there aren't so many new standards that a bot is required to import new standards every five minutes. Jc86035 (talk) 15:47, 17 November 2018 (UTC)[reply]
Support There is 22400 ISO standards + 13000 specific ASTM standards + 8000 SAE specific aeronautic standards + .... I couldn't find the quantity of specific EN standards. AFNOR list 100 000 standards valid in Europe.The 22400 ISO standars have to be priority since these are valid worldwide. Thibdx (talk) 18:14, 17 November 2018 (UTC)[reply]
Problem: There is no easy way to navigate from Q-items to their connected L-items
Who would benefit: All wikidata editors, specially those working with lexicographical data.
Proposed solution: it would be nice to have a script or gadget that converts the labels/aliases of a Q-item into links to L-items that are connected with "item for this sense (P5137)". So basically what it should do is to see if the text of any of the forms of the linked L-items matches 1-to-1 with any of the label/aliases of the Q-item for that language, and if it does, it should convert the text of the label/alias into a link to the L-item.
More comments: Normally there should be only one exact match per label, but there is at least a known exception: both "gwenn (L30900)" (noun) and "gwenn (L30901)" (adjective) link to "white (Q23444)". For cases like this it would be nice if the additional L-items are linked with a superindex if possible, if not then it is ok to just link one of them for a first version.
Problem: When one's watchlist is set to display edits made on linked statements on Wikidata, they are always displayed in numerical code even if labels exist on the Wikidata entries. For example, this diff on enWikipedia's watchlist displays as "Created claim: Property:P4552: Q5456; Added reference to claim: Property:P4552: Q5456" whereas on Wikidata it's two diffs with two edit summaries, "Added reference to claim: mountain range (P4552): Andes (Q5456)" and "Created claim: mountain range (P4552): Andes (Q5456)".
Who would benefit: People who use their watchlist on a non-Wikidata project to monitor changes to the Wikidata item linked to an article they have watchlisted. On enWikipedia some templates draw information from Wikidata so making it easy to monitor the edit content may be beneficial.
Proposed solution: The watchlist should display the language label if it does exist in lieu of the numerical code; in this case the summary should be "Created claim: Property:mountain range: Andes; Added reference to claim: Property:mountain range: Andes" perhaps with the "property" omitted if it makes the summary overlong.
Problem: Wikidata is often considered unreliable as a data source due to vandalism and a lack of adequate sourcing. In spite of these issues, Wikidata is still used in infoboxes across Wikipedias, even though it can be difficult for Wikipedia editors to edit Wikidata; and on many wikis references are omitted entirely from Wikidata infoboxes, making it more complicated to check the veracity of data.
Who would benefit: Wikidata; Wikipedia articles (infoboxes, descriptions, external database links, etc.) and other users of Wikidata data
Proposed solution: In order to verify existing data, it would be helpful to make sure that references used in Wikidata are shown when statements are used in Wikipedia infoboxes and the like,[note 1] and it could also be helpful to allow editors of both Wikipedia and Wikidata to add maintenance tags with a script (e.g. "[this statement] might not be true" or "needs a source"), replicating the utility of Wikipedia's venerable [citation needed]-style tags. Particularly for data which can't be verified easily using secondary sources or constraint violations, like geographic coordinates, it would also be beneficial to have tools to easily find errors (e.g. wrong coordinates) or oddities (e.g. weird precision) in the data.
Notes
↑This would probably involve editing the Wikidata-related Lua modules for each wiki, or by creating a new module to incorporate all their features and localizing it across all wikis (there are currently multiple disparate modules in use, even on individual wikis).
More comments: Originally page protection enhancements were part of this proposal. These are now part of a separate proposal.
Phabricator tickets:
phab:T209242 – For Lua modules across Wikipedias, allow display of sources from Wikidata and filtering of unreferenced statements across all Wikidata infoboxes (11 November 2018)
phab:T209237 – Gadget for Wikidata and Wikipedia users to add maintenance tags to Wikidata items (11 November 2018)
phab:T209241 – Creation of software to auto-detect errors or oddities in internal or unreferenceable Wikidata statements, e.g. images, geographic coordinates (11 November 2018)
Related: phab:T148928 – Wikidata integration for proveit gadget (23 October 2016)
One issue that I hit recently is outdate Wikipedia imports. For instance, a (wrong) set of coordinates was imported from de.wp. In the mean time, the data was corrected on Wikipedia, but not Wikidata. A lot of additional work can be done on coordinates, such as supporting areas, which in turn allows checks such as "is this coordinate within the area indicated by the P31 of the item?"--Strainu (talk) 21:55, 29 October 2018 (UTC)[reply]
One possibility would be to add a button "doubtful" to the right of the "edit" button. Then others could query the doubtful statements (possibly using Wikidata Query) and fix the problems by deleting or editing the bad quality or wrong statements. Geert Van Pamel (WMBE) (talk) 10:47, 4 November 2018 (UTC)[reply]
@Geertivp: I think that sounds like a good idea; such a feature could be used to add preset tags like in Wikipedia articles (e.g. citation needed, needs update, doubtful/dubious), possibly by making the script add qualifiers to statements. I have proposed a property for this information, since one does not yet exist. Jc86035 (talk) 11:16, 4 November 2018 (UTC)[reply]
There is a way in Lua to ensure that only sourced properties are displayed in templates. That could be a first move for critical pages. Another idea could be to convert URL listed as sources into special items that could be reviewed to status on the source quality. This could be partially automated using the source base URL. Pubmed is reliable. CNN is quite reliable. The Onion is fake. -- Thibdx (talk) 00:08, 5 November 2018 (UTC)[reply]
Define Quality of external source and double check
I think Open Free Knowledge most important component is having references to external trusted sources. I therefore would like to see
in the Wikipedia infobox
that the reader easy can see
that a fact is based on an external source
the quality of source used - we need to find a way to describe quality of a source and our experience using it
that we have confirmed that this fact is the same as an external fact compare Listeria list that runs daily comparing Wikidata with Nobelprize.org link see example diff
that we also visualize in the Wikipedia infobox a mismatch with an external source found in Wikidata
- 09:56, 30 October 2018 (UTC)
@Salgo60: Added a sentence and a note to the proposal. The English Wikipedia's WikidataIB Lua module is able to filter statements based on whether or not they have a source which is not to a WMF project, but I don't think it's able to display sources from Wikidata. Jc86035 (talk) 13:21, 30 October 2018 (UTC)[reply]
I think the quality of a source might be difficult to categorize, although perhaps one could filter out sources which are blacklisted by the English Wikipedia for being unusable. Jc86035 (talk) 13:37, 30 October 2018 (UTC)[reply]
Thanks If you listen to the vision of en:Tim Berners-Lee then in an en:linked data world then I as a reader should be able to select what sources I trust... I feel Trust is very important and we need to think about how Wikipedia explains to the reader the quality of used sources. One vision could also be that I as an reader of Wikipedia should be able to see what facts in the article I read is based on sources I trust - Salgo60 (talk) 13:44, 30 October 2018 (UTC)[reply]
Basically your solution to vandalism is to prevent Wikipedia editors without existing Wikidata edits from removing vandalism that might show up on Wikipedia for critical fields. That sounds to me like a bad plan. ChristianKl (talk) 18:03, 2 November 2018 (UTC)[reply]
@ChristianKl: Not necessarily (although that specificially would probably not be a good idea). Obviously what exactly to protect would be decided by Wikidata admins. You might
prevent a class of users from editing a group of pages;
prevent a class of users from editing specific parts of a group of pages;
prevent a class of users from adding statements without references on a group of pages;
prevent a class of users from adding statements without references on specific parts of a group of pages;
prevent a class of users from editing existing data for a group of pages;
prevent a class of users from editing some existing data for a group of pages.
The latter two would probably be quite difficult to implement properly without preventing some registered users from reverting vandalism and without preventing some users from editing the data that they just added, although perhaps they could be limited to the scope of statements with existing references which have URLs or which cite another item.
I think some of these would also be particularly useful for items about scientific articles, since usually after import they shouldn't need to be edited manually (and edits are likely to come from Special:Random). Jc86035 (talk) 05:19, 3 November 2018 (UTC)[reply]
I would forbid that it could be put "imported from Wikimedia project (P143)", because we are not a primary source and can not serve as a reference in certain affirmations. --Vanbasten 23 (talk) 11:11, 4 November 2018 (UTC)[reply]
Jc86035 Hello. Thanks for submitting a proposal for the wishlist survey. This proposal is very broad and proposes a number of different solutions. I'd encourage you to make the problem statement more focused on specific issues (like Ability to easily import references) that are individually actionable. Otherwise it will be very hard for us to focus our work on what's important. Thank you. -- NKohli (WMF) (talk) 23:40, 5 November 2018 (UTC)[reply]
@NKohli (WMF): Would it be sufficient for me to order the Phabricator tickets (once I create them) from most important to least? I think they're all important, although some of them would certainly have a bigger impact than others. Jc86035 (talk) 14:08, 6 November 2018 (UTC)[reply]
@Jc86035: Just writing down what you think are the steps to solve this in order of importance would be fine. Phabricator tickets would be nice but aren't necessary. I can't say we will be able to do everything but having the proposed solution in order of importance according to you would be helpful. I see Geert Van Pamel and Lydia suggested a solution above. You could also incorporate that in the proposal if you think it's a good idea. Thank you. -- NKohli (WMF) (talk) 22:49, 9 November 2018 (UTC)[reply]
Support Sounds like a basic requirement to backup Wikipedia mission on neutrality and trustability. Also, still in the vain of trustability by traceability, one should also be able to get the license of the sources, to let reuser of large portion of Wikidata that they are not unwillingly using Wikidata as a license laundering canal. See Address concerns about perceived legal uncertainty of Wikidata for this later point. Psychoslave (talk) 04:12, 18 November 2018 (UTC)[reply]
Support Why not letting the creation of Wikidata items for sources, for example: a news article or a book, so these can be linked to the statements as sources backing up them. Hienafant (talk) 19:45, 22 November 2018 (UTC)[reply]
Problem: Wikidata diffs (item changes views) are currently only show which statement/reference/description/etc. changed, they don’t highlight what exactly changed within it. For example, in this diff, only one word was changed (the first one in the parentheses), but the whole description is highlighted with the same style which shows the actually changed parts on wikitext pages. (I had to use Navigation Popups to find the actual changes.) Here only the first snak changed, but the whole reference is highlighted (more or less). (The hash is also different; I don’t know if it’s because of the bot edit.) Here only the day changed, but nothing is highlighted(!).
Who would benefit: Wikidata users patrolling edits.
Proposed solution: Create more fine-grained diffs.
More comments: For string values (including labels/descriptions/aliases as well as string/external identifier/URL/formula/etc. datatypes), it seems pretty easy as the wikitext diff engine can be reused. Time and quantity values are a bit trickier, but even more needed, as it’s much harder to use an external diff software. It doesn’t make any sense for entity values such as item, property, lexeme etc.
Phabricator tickets: Any? It’s quite hard to search for this on Phabricator.
Problem: There is hard to distinguisch which statements have preferred and wich deprecated rank. Usually the best ranks are used in queries and in other wiki projects, but these are not easilly to distinguish. On the other side deprecated satements are usually not of big importance, but visualizing them in the same manner like statements with normal and preferred rank complicates the readibility.
Who would benefit: The acceptance of wikidata statements in other wiki projects, the wikidata projects itself (editors and users can more easylly distinguish between ranks).
Proposed solution: One possible solution would be that in SQID
Whilst not taking away from your request, which I think makes good sense, deprecated statements can be made a bit more obvious by adding a reason for deprecated rank (P2241) qualifier.
The design of the visual distinction would need some care, on the one hand to make the unusual rank more obvious; but on the other hand still being quite subtle, to avoid too much damaging the visual unity and visual flow of the page. For example, Reasonator distinguishes quite strongly between statements of different rank, but I find its very pronounced bold for preferred items (see eg: Glasgow - Population [2]) to be overdone and distracting. Jheald (talk) 15:36, 9 November 2018 (UTC)[reply]
A pink pastel and a green pastel for deprecated and preferred ranks might be a nice way to meet the intent of this wishlist item. --Izno (talk) 17:53, 9 November 2018 (UTC)[reply]
Problem: The Wikidata community has now decided that sitelinks to (some) redirects should be allowed. (see RFC;subsequent discussion; 25,000 current uses of Template:Wikidata redirect on en-wiki). Where a Wikidata item links to a page that is a redirect on a particular wiki, it would be good if this was indicated on the Wikidata page; and by that wiki's entry in the sidebar interwiki links section of its corresponding Wikipedia pages. (An 'R' on a red circle might be appropriate next to the link, in at least some languages)
Who would benefit: Readers, who would know whether to expect the iw link to take them to an article with a matching subject; or whether the link would instead redirect to a related or umbrella topic.
Proposed solution: A relatively easy way to achieve this might be to use the "badge" mechanism, as currently used to identify interwikis to good and featured articles.
If I understand well the problem we have a script for this: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Matěj_Suchánek/checkSitelinks.js&action=raw&ctype=text/javascript' ); It show redirect and disambiguation. --ValterVB (talk) 19:01, 17 November 2018 (UTC)[reply]
I suggest to indicate links to redirects in the iwl sidebar simply by using italics. This does not consume more space and would be in line with how redirects are rendered if they show up in categories. --(Matthiaspaul) 178.10.50.19120:56, 17 November 2018 (UTC)[reply]
Problem: It takes a long time to add inverse statements, father/mother -> child; owner of-> owned by; Spouse/Partner (including qualifiers start time, place of marriage, etc)
Who would benefit: Everyone editing
Proposed solution: Possibility to automatically add inverse statements, including qualifiers.
I actually wonder why inverse properties exist in the first place. It seems like they exist so that the inverse can be referenced on other wikis. Perhaps it would be better to make it easy to reference "the inverse" in a sidebar on Wikipedia instead of having to actually duplicate the data in the database. For instance, if there was a way to say that I want the items, where the "father" is this page, it would give me a list of the page's children. That seems like it would be way better than trying to ensure that the inverse statements are correct everywhere. U+1F360 (talk) 23:22, 14 November 2018 (UTC)[reply]
@Germartin1: How would this handle qualifiers and references, and statements with the same value but different qualifiers (for e.g. adjacent stations, offices held)? I like this proposal (and added my support vote) but I think these are things that would need to be addressed in the implementation. Jc86035 (1) (talk) 08:11, 20 November 2018 (UTC)[reply]
Support As I added above, I think the reasons why we have inverse properties should be investigated first (as their might be a better technical solution that removes the need for them). But if removing them is impossible, then we should make it faster/easier to add them. U+1F360 (talk) 21:53, 16 November 2018 (UTC)[reply]
Support Inverse properties are trivial case of properties which can be derived from other properties. See https://phabricator.wikimedia.org/T167521 for more complicated cases. We should have some mechanism to define such properties. Maybe as "read-only" properties automatically generated if some condition is met. One danger of inverse properties is thay have to be removed in 2 places. One thing we do not want is a property added by bot, so if a person deleted one of them bots re-adds them based on the other one. Jarekt (talk) 05:47, 17 November 2018 (UTC)[reply]
Support also "has part" - "part of" and similar. Perhaps the properties could be "weak ones" - autogenerated, unless someone overrides them? Andree.sk (talk) 19:58, 17 November 2018 (UTC)[reply]
Support model and implement 1:1, 1:n, n:m relationships navigable in both directions as single entities and all operations (like add & remove) as atomic, not as two inverse properties (which exposes an implementation detail). The names of the relationship's ends still should make sense, like ownes and owned by.. Herzi Pinki (talk) 22:52, 17 November 2018 (UTC)[reply]
Support At least checking and easily creating the other end for symmetrical properties (spouse, etc.) would be great. Note we'd also need to be careful with qualifiers. References should be carried over too. Laboramus (talk) 07:14, 21 November 2018 (UTC)[reply]
Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)[reply]
Oppose (with the understanding that oppose votes are not counted here) per Arthur in full. I think this is useful for properties where the likelihood of introducing unnecessary bloat to items is very low, but I am against using this functionality with properties that have a strong likelihood for bloat (such as "part of", "has part", and most recently "owner of" and "owned by"). Mahir256 (talk) 21:07, 23 November 2018 (UTC)[reply]
Support Only as optional, not as mandatory. It can be either per property (e.g. father/mother -> child is automatic, part of is not) or as an option (Preferences, pop-up etc.) — NickK (talk) 15:32, 30 November 2018 (UTC)[reply]
The notification view should show the label for an item instead of showing the item ID
Problem: Given that I don't know which item has which numbers this view isn't very informative. It would be a lot more informative if it would show the label of the items in the list.
Who would benefit: Everyone who works on Wikidata in a way that they get notifications.
Proposed solution: Show the labels of the items instead of showing the ID.
Problem: (by Man77) It is (still) my firm opinion that the control of incoming data and of changes to the data stored in Wikidata does not work as well as it should. What is a tiny edit on one of Wikidata's ~ 52 million items can cause wrong information to appear in many thousands of pages in more than a hundred other projects, even those which chose to have flagged revisions as part of their quality control. There are many examples where the threat of vandalism not being detected is significantly higher than the possibility that the information provided actually needs to be changed (for instance: Chiapas is located in Mexico); some information is actually timelessly true (such as population numbers from a census at a specific date in time). Allowing such stable data to be actually stabilized and only be changed under circumstances yet to be defined could not only increase Wikidata's reputation as a trustworthy database but also increase its usage, while reducing its vulnerability.
(added by Jc86035) Wikidata's core editor base is also quite small in spite of the large amount of content, and unlike on other projects, some items may never be edited manually because of the breadth of this data. Directly because of this, some vandalism can go unnoticed for months. On the other hand, it would be impractical and problematic to e.g. semi-protect large groups of items in their entirety, because this would prevent a lot of page moves and deletions from being reflected on Wikidata by the user performing the page move or deletion, and it would prevent anonymous and new contributors from adding valuable data (particularly translations of labels and descriptions).
Who would benefit: Wikidata as a whole (reputation, usage), Wikidata volunteers, other projects' volunteers (lessened workload), readers (wouldn't see wrong information)
Proposed solution: Allowing partial protection of items, and protection of classes of statements across all Wikidata items based on their content (i.e. usage of properties, qualifiers and references), would help with preventing needless vandalism. Users might be deterred from vandalizing (due to the additional effort required) or might be encouraged (or forced) to discuss potentially problematic changes with other editors.
More comments: Originally flagging of problematic statements was part of this proposal's solution. This is now part of a separate proposal.
@Man77: This is quite similar to part of my proposal (page protection for classes of statements and statements with references; gadgets for WP and WD users to add maintenance tags). I think it might be beneficial to either merge the proposals together or distinguish them in their aims, due to the rule that only the top ten proposals will certainly be looked at. Jc86035 (talk) 16:05, 11 November 2018 (UTC)[reply]
The other proposal is too sprawling, so we're going to close that one but retitle this one to mention the solution suggested in the other. Hope that makes sense. Ryan Kaldari (WMF) (talk) 23:43, 14 November 2018 (UTC)[reply]
@Ryan Kaldari (WMF): Would it be fine to only keep the parts of the proposal focused on issue tags and showing references with the Wikidata Lua modules? There are clearly at least a few editors (who I did not canvass) who think the topic is important, so I think it would be somewhat inappropriate to close it outright; and I think those things would be fairly doable. Jc86035 (talk) 06:20, 15 November 2018 (UTC)[reply]
Problem: Very often there is a need to create new Items of a similar kind, series of Items. For example a roster of team members, works by an artist or so on. This is actually only possibe, when I create for every Item from the beginning a new Item, where I have to do it alway from the beginning. This needs a relly long time. Or I have to use external helpers and concepts, so Google or Excel. Even this is time robbing.
Who would benefit: All contributors to Wikidata, who need to create similar items in a row.
Proposed solution: Magnus Manske already created Cradle. This is nearly exactly what is needed - problem: after the first few days there are problems with saving the new items. So here would be an input mask for ancient potters and vase painters. Here for a single piece of ancient pottery. This must be imlemented in the normal Wikidata structure. Every user must can create their own masks - as much masks they need for use and reuse.
I believe we need something as "create as" or "create like" having the possibility to duplicate Labels, Descriptions, and Statements from another similar entity in a controlled way without the risk of creating rubbish content. I often do this already now but completely manual, which is taking a lot of time and effort. Geert Van Pamel (WMBE) (talk) 10:56, 4 November 2018 (UTC)[reply]
Another problem is duplicating e.g. the name of a person in all languages. The name of a person generally is language independent. When the name of a person is already entered for one language it must not be overwritten. When the name of a person is unavailable in one language it cannot be searched (in that language). Geert Van Pamel (WMBE) (talk) 10:56, 4 November 2018 (UTC)[reply]
I had exactly the same request. The current stucture is very versatile but not always the most user-friendly nor the most efficient. At least not at the same level of what dedicated data models forms could provide. In example, for alloys, alloying elements have to be specified adding "has part" property then "Chromium" (i.e.) item and then adding the qualifier "Proportion", then adding the numerical value and then adding the unit... Seriously... With a dedicated form you just choose the element and write numerical value. When you have alloys with 10+ elements you save a trendemous amount of time. Not saying that newcomers will immediately understand how to deal with this type of form while they would have no idea on how to do it unless they find the materials project page and read everything. This type of dedicated form has the potential to greatly enhance the contributions to Wikidata by empowering current users and easing the adoption by new users. --Thibdx (talk) 23:54, 4 November 2018 (UTC)[reply]
QuickStatements is an "external" tool which has its own merits, and potential risks; what we want here is something internal to the main Wikidata Web GUI, that allows to create new "similar" data items based on a chosen item profile which lists typical properties with default values. And a constraint violation technique (or warning) to prevent "mass" creation of duplicate items/statements. Geert Van Pamel (WMBE) (talk) 10:12, 8 November 2018 (UTC)[reply]
User:Marcus Cyron, what do you mean with "after the first few days there are problems with saving the new items"?
Hi. As I wrote, there's nothing more behind it. For two days or so, Cradle worked very well, but since then it did not safe the data. You can work on Cradle, put everything on the sheet - but in the moment you wanna safe it, it did not safe. At first it helps to go from Firefox to Chrome - but also two days later I tinh it was also not longer able to safe. And this not only for me. But what Magnus has shown it, that it definetly would work. Marcus Cyron (talk) 06:41, 9 November 2018 (UTC)[reply]
Problem: It is a great experience and big advantage to browse wikidata using the query helper. For the unexperienced user it is difficult to see what qualifier, rank and sources the data have. This makes it difficult to explore the data for users without or with little SPARQL-knowledge.
Who would benefit: Showing the sources in queries would make it easier to see what part of the statements is for example sourced. This would help to estimate the reliability of the statements of the property and may increase the acceptance of the data in other wiki projects. On the other side further use and operations could be made, if for example one can see all the available qualifiers (like "point in time" etc.).
Proposed solution: In the query-builder there is already a button to add a label for the required property. One additional button should add the unit, the rank, all the qualifiers and all the references to the result of the query.
Just a comment that this proposal may be more complex than it seems: the simple queries without qualifiers etc. refer to a different triple structure than the complete queries would, and that transformation may be hard to automate. ArthurPSmith (talk) 16:43, 17 November 2018 (UTC)[reply]
Problem: hard to enter coordinates in wikidata, have to go to external tool and copy and paste
Who would benefit: wikidata users
Proposed solution: popup map next to every coordinate property, to be able to pin on the map, to provide semi automated entry of geocordinates for that item
It would be very convenient. I would also like to add that there should be an ability to pick accuracy of coordinates with accuracy options displayed not as "0.0001" but as "+-5 meters" with accuracy also depicted on map as a square. --Tohaomg (talk) 20:56, 10 November 2018 (UTC)[reply]
Update Dec. 2018: We have added maps now when viewing and editing a statement with a geocoordinate. We don't yet have a picker but I hope this is already a big improvement for you. --Lydia Pintscher (WMDE) (talk) 18:56, 21 December 2018 (UTC)[reply]
Support Especially with the indication of degree of accuracy. I agree that expressing this in terms of distance is much better than in terms of number of decimal places. MartinPoulter (talk) 12:09, 22 November 2018 (UTC)[reply]
Problem: On Wikidata, it is still not possible to add dates with precision better than the day or dates with time zone information, which prevents Wikidata from accurately recording when events occurred; and dates are still incorrectly localized for most languages (e.g. "4 8 1961" in Chinese), which obviously impedes a lot of contributors in understanding what they actually mean. These issues can harm the ability of editors to add data, making them problematic for data consumers as well.
While "data entry is impossible" is self-explanatory, it's probably worth explaining just how complicated and irritating the date formatting issues are. On Wikidata dates can be shown with different precisions, from "day" (the current limit) to a billion years. Each of those precisions has to be translated correctly, and BC dates and AD years before 100 should be handled specially. This doesn't really work right now – "2 January [in] 1 AD" is shown as "1. január 2" in Hungarian (interpreted by readers as first of January in the year 2), and it's obviously even worse without displayed month names. Centuries and decades are also shown haphazardly in several languages because the software doesn't allow for things like grammatical inflection, though this is more of an irritant than an impediment.
Although these are nominally separate issues, fixing either of them would involve changing the way Wikidata's interface handles dates, so it could be more effective for them to be worked on in tandem, and it would avoid duplication of work.
Who would benefit: primarily Wikidata contributors
Proposed solution: fix the irritating UI problems; add functionality which is needed to enable data entry and data storage
More comments:
Phabricator tickets: Selection of some tickets. I have added bold to the ones that seem the most impactful. I'm not expecting all of them to be resolved but it would be nice if work could be done on all of them.
phab:T57755 – Allow time values more precise than day (15 October 2013)
phab:T63909 – Make use of before and after in Time datatype (25 February 2014)
phab:T63958 – Use existing $dateFormats to format dates on Wikidata (26 February 2014)
phab:T95553 – Full stop in messages such as Wikibase-time-precision-century is incorrect in English (9 April 2015)
No tickets yet:
Translate date formats correctly
Correct grammatical inflection for dates (e.g. decades in Hungarian)
Please add other Phabricator tickets if you think they are relevant to this request (although not necessarily those which are children of tasks already linked). Thanks, Jc86035 (talk) 08:38, 30 October 2018 (UTC)[reply]
Addon: Some properties like P150 (contains administrative territorial entity) seem to slow down the opening or scrolling of a page. Add a 'collapsable' (Hide/Show) possibility for properties which list many items --katpatuka (talk) 06:17, 4 November 2018 (UTC)[reply]
@Katpatuka: Do you want to improve the page load time (i.e. something like making statements load "lazily" after the initial page load) or do you want to allow properties to be collapsed? Jc86035 (talk) 06:49, 4 November 2018 (UTC)[reply]
Partial (lazy) loading, or collapsing Statements might lead to a higher risk of duplicate data. I would never recommend it. For the same reason there is no "Statement Add" button at the top of the page; only at the bottom, so users need to scrol down and read existing Statements. I encounter the problem of duplicate data already now on pages with a lot of Statements. Rather I would choose for a logical/structured sequence of properties + alphabetical sorting (e.g. in Aliases or multiple alma mater, professions, functions, contains, etc.). We should always see all statements for one item. To prevent duplicate data I would implement an online constraint checking with an error message before saving the data. But some pseudo-duplicate statements are always possible: e.g. multiple official web sites, multiple VIAF codes, etc. Speeding up page load should always be a point of attention; but even more important is completeness and referential integrity improving the overall data quality. Geert Van Pamel (WMBE) (talk) 14:12, 4 November 2018 (UTC)[reply]
It could be really useful to have a "Wikidata usability initiative" similar to Wikipedia's one. There is more room that what we can imagine for usability improvements on Wikidata. This would greatly empower the contributors. I know that this type of project need a full time team of UX specialists. It needs a specific funding. --Thibdx (talk) 00:14, 5 November 2018 (UTC)[reply]
Unfortunately, our team will not be able to work on this proposal because it wants to address too many things that it should have really been their own proposals. Even if we didn't work on any other proposal, we couldn't possibly finish this in a year. MaxSem (WMF) (talk) 00:38, 15 November 2018 (UTC)[reply]
@MaxSem (WMF): I've only linked to eleven tickets, excluding the Epic ones (which I was not expecting to actually be worked on, and it would obviously be impossible to create all the datatypes Wikidata will ever need). If I were to remove the tickets that are not bold-formatted and the "no tickets yet" points, or even just the Epic ones, would it be small enough? Jc86035 (talk) 06:03, 15 November 2018 (UTC)[reply]
@MaxSem (WMF): By "date-related issues", are you referring to the time datatype issues (i.e. adding seconds precision and time zones), the date display issues, or both? I have amended the proposal so that only date-related issues are listed, so it should already be a bit smaller than some other proposals which haven't been archived. Jc86035 (talk) 10:22, 16 November 2018 (UTC)[reply]
@MaxSem (WMF): Since voting opens in less than five hours and I won't be staying up all night, I will be moving this proposal back myself. If it is still too much then I think it would be better to remove the parts of the proposal which pertain to adding hour/second/minute precision than to archive the proposal outright. Jc86035 (talk) 15:10, 16 November 2018 (UTC)[reply]
Eh some of those tickets are actually related so that it's possible that there's a synergy effect in reducing workload that they might not be as much as they seems. C933103 (talk) 06:16, 15 November 2018 (UTC)[reply]
Allowing date/times more precise than 1 day will have to make some provision to distinguish all the existing dates, which in reality are in local time (despite what documentation says), from dates created after the implementation, which would need a time zone. Jc3s5h (talk) 11:25, 19 November 2018 (UTC)[reply]
Support, however I would like to use this opportunity to express my disappointment against the limited ability of the community tech team which lead to the rejection of many aspects of this proposal and also many other proposals. Especially with the amount of donation WMF have been gathering from users each year. C933103 (talk) 06:43, 17 November 2018 (UTC)[reply]
Support Leiem (talk) 05:42, 17 November 2018 (UTC)
Neutral A single reference on Wikidata may contain more than one property-value pair and all of them can be added at once. Enumerating all of them (if not all, which one? the first/last one?) in the edit summary may be undesired. Matěj Suchánek (talk) 10:33, 25 November 2018 (UTC)
Oppose I think that we should find a way to deprecate P2959 instead. --Liuxinyu970226 (talk) 04:18, 17 November 2018 (UTC)
Comment @Thibdx: I already have a simple scrapy script that dumps ISO data into a CSV file. The time consuming part is not having a model for ISO standards, and not having an easy and efficient way to write data back into Wikidata (one edit per item with multiple statements, not Pywikibot's one edit per minor change). You can copy and have a look at the spider (especially the xpath rules) at [1]. Dhx1 (talk) 12:46, 19 November 2018 (UTC)
or 
) is more clear that the use of italics. --ValterVB (talk) 21:13, 17 November 2018 (UTC)
Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)
