Wikidata:Property proposal/maintenance tag

this should be fixed / maintenance tag

Originally proposed at Wikidata:Property proposal/Generic

Not done

Description	relevant maintenance issue for this entity or statement (create a new item for the issue if an appropriate one does not exist)
Data type	Item
Example 1	Thriller (Q380825) → [new item for "this item incorrectly conflates a music track and a composition"@en]
Example 2	[some statement] → [new item for "this statement may be factually incorrect"@en; or Template:Dubious (Q5618578)]
Example 3	Love, Simon (Q29169280) → [new item for "this item for a creative work does not have all release/publication dates"@en]
Example 4	I Will Always Love You (Q666856) → [new items for "this item's singles chronology or singles chronologies should be in qualifiers to P179 statements on an item for the single"@en, "this item incorrectly conflates a music track and a composition"@en, "this item incorrectly conflates multiple music tracks (live recordings, remixes and cover versions should have their own items)"@en, "this item combines data for different creative works, which should be separated into distinct items"@en, "this item incorrectly conflates a song/track with its music video"@en, and "this item incorrectly conflates a music track with a single (singles are regarded like albums even if they only have one track)"@en]
Example 5	American Idiot (Q151714) → [new items for "this item has data which applies only to individual versions or editions of this creative work, which should be separated into different items" and "items should exist for this item's versions or editions"@en]

Motivation

(Inspired by Geertivp's comment at m:Community Wishlist Survey 2019/Wikidata/Improvements to the reliability of Wikidata.)

It is not possible to manually add maintenance tags like Wikipedia's "citation needed" tags. A standard way to add issues to items and statements (e.g. "this item needs to be updated" or "this statement (date/geocoordinate) could be made more precise" or "this item for a creative work does not have all release/publication dates") would be very helpful. Property constraints cannot substitute for all of those issues.

Currently the only realistic way to get input for some odd issue is to post on the project chat, and if no one replies the issue will be forgotten in the archives; and for some tasks (e.g. example 1) it is currently much, much easier to automatically add a maintenance tag than it is to automatically fix the problem. It may also be difficult for Wikipedia editors to know how to correct information that is transcluded to articles.

This property would be analogous to OpenStreetMap's "fixme" key. I have proposed the "item" datatype rather than the "string" datatype because this way it will be easier to manage and translate issues. Jc86035 (talk) 11:15, 4 November 2018 (UTC)[reply]

(If a script or gadget is indeed written for registered Wikipedia editors to add these statements directly from infoboxes, I would favour having the tool post custom/other issues at a centralized page, rather than create a new property with datatype string for issues which aren't in the list of options.) Jc86035 (talk) 16:28, 6 November 2018 (UTC)[reply]

Discussion

Weak support I understand your point, but wouldn't it be better to just fix it or write it in the talk page. Can't queries be used to find out which items lack statements? Germartin1 (talk) 16:44, 4 November 2018 (UTC)[reply]
The idea behind the "fix-me button" is that the person that sees the faulty/doubtful entry does not necessarily/easily know the correct value for the Statement without substantial analysis. Just being able to hightlight the potential quality problem can invite other, more capable, users to fix the problem (either edit or delete after analysis of finding additional sources). Also the Reasonator or the Wikipedia infobox filling algorithm could further ignore doubtful information. Geertivp (talk) 17:24, 4 November 2018 (UTC)[reply]
Strong support Just the other day I was thinking how nice it would be if Wikidata had a "citation needed" mechanism, and was even contemplating a property proposal for that! You could add this as a qualifier to a particular statement to indicate it needed a supporting citation (or some other issue fixed), I assume? The examples you have are for more general issues at the entire entity level where it could be a regular statement. ArthurPSmith (talk) 23:14, 4 November 2018 (UTC)[reply]
@ArthurPSmith: Yes; it's just that I haven't noticed any statements recently where this would be appropriate and which I didn't fix. There are probably lots of small islands where the coordinates aren't accurate enough to indicate which island the item is actually about, for instance, but I haven't gone searching for them. Jc86035 (talk) 18:36, 5 November 2018 (UTC)[reply]

Citation needed doesn't really need a new property though--we just need to use something like the item for mainspace [citation needed] or make one and to put that in the reference list for a particular claim. So this isn't all that strong a case for a tag like this. --Izno (talk) 15:46, 6 November 2018 (UTC)[reply]
@Izno: I don't think it should go in the reference list. If an existing property is used in references, then a bunch of items have to be checked for by the Wikidata-related Lua modules and their statements removed from the reference list, which makes it more difficult to transclude sources and filter unsourced statements. (And if the new property is used in references, then the new property… also has to be checked for by the Lua modules.) Jc86035 (talk) 16:23, 6 November 2018 (UTC)[reply]
Yeah that's probably a decent reason not to deal with it in references. Qualifiers? Might be cool for e.g. a Lua module on a wiki to see the Q number that is assigned to citation needed and say "oh, that's a citation needed: I should display my template for citation needed". --Izno (talk) 18:44, 6 November 2018 (UTC)[reply]
Support Wostr (talk) 23:47, 5 November 2018 (UTC)[reply]
Conflating can be a rough case to deal with since you need to add multiple items possibly (which are the conflating ones?). So maybe that should get its own property "conflates" or similar? --Izno (talk) 01:46, 6 November 2018 (UTC)[reply]
@Izno: I'm not sure how useful it would be, other than as a subproperty of this one; and maybe that would overcomplicate the use of this property. Usually (as far as I'm aware) if an item's sitelinks discuss two or more topics (e.g. audio/composition, library/building, taxon/species, word/concept, work/book, locality/district/government, group/people) then either the item should only be about one of those things, or there should be items or lexemes created to represent the individual topics. Jc86035 (talk) 14:27, 6 November 2018 (UTC)[reply]
Support Jheald (talk) 09:06, 6 November 2018 (UTC)[reply]
Oppose given the proposed scope: marking items as incomplete just seems nonsense. See notably sample 3= Q29169280 → [new item for "this item for a creative work does not have all release/publication dates"]). --- Jura 18:56, 6 November 2018 (UTC)[reply]
- @Jura1: Where was this proposed to be used for "marking items as incomplete"? All wikidata items will always be incomplete, so that really wouldn't be a useful label. This is for specific problems that can be seen but can't be immediately solved. ArthurPSmith (talk) 19:42, 6 November 2018 (UTC)[reply]
  - Have look at sample 3 and similar items. Then, maybe compare with the number of publications dates found at other sources. The suggested reason applies to most if not all film items. Merely tagging stuff isn't really helpful. --- Jura 19:48, 6 November 2018 (UTC)[reply]
    - If it's not useful then people won't use it for that, but this doesn't seem like "nonsense" to me - for that example the list of publication dates could be known to be complete or incomplete and it certainly makes sense to have a way to denote that specific fact directly on the item. ArthurPSmith (talk) 19:33, 7 November 2018 (UTC)[reply]
      - Here you just supported a proposal that does that. Marking items as complete or incomplete is probably something that is needed, but I don't think we should start adding tons of statements marking items or some of their statements as incomplete. This can be done with constraints. --- Jura 08:59, 8 November 2018 (UTC)[reply]
Comment Secondly, another problem with the above is that it combines questions about the validity of statements with structural issues. We already have ranks (and some properties) that are meant to deal with the first ones and I don't think this should be mixed into this problem as well. --- Jura 08:59, 8 November 2018 (UTC)[reply]

Notified participants of WikiProject property constraints@Ivan A. Krestinin:

Comment thirdly, I think part of the above maintenance issues already surface with standard or complex property constraints. The first are being made available on query server. As such, I don't think they should be repeated as statements. I'm curious what the participants of WikiProject Property Constraints think about it. --- Jura 08:59, 8 November 2018 (UTC)[reply]
@Jura1: For some of those issues I have actually used property constraints on the related identifiers (e.g. MusicBrainz release group ID (P436)), but it can be ambiguous as to exactly why the constraint is there, and sometimes complex constraints are required (i.e. no one is going to know about the issue because the constraint doesn't show up on the item).

I don't think combining those types of issues into one property would be problematic. Many Wikipedias use one master template or CSS class to make all of their page issue templates, for instance, and Wikidata doesn't need to have a distinction between inline issue templates and page issue templates. Jc86035 (talk) 09:18, 8 November 2018 (UTC)[reply]
Oppose per Jura1; further thoughts: (1) those claims would be about the item itself, not about the entity described by the item; (2) we don’t keep up with covi list maintenance, and this one would be probably much worse as the targeted fixes are typically much more complex than constraint violations; (3) even fixme items with lengthy descriptive labels are often unsuitable to exactly describe the problem, so users might be confused, rather than motivated to fix something; (4) tagging with templates on item talk pages seems more appropriate. —MisterSynergy (talk) 09:27, 8 November 2018 (UTC)[reply]
@MisterSynergy: I think using item talk pages would be a reasonable alternative, but it might not be very useful unless the issues are shown on the item itself with a gadget or script. Jc86035 (talk) 09:33, 8 November 2018 (UTC)[reply]
I do not think that random item page visitors would contribute to fix the tagged problems to any measurable extent. Unlike Wikipedias, our data users (readers) do not typically browse items in a browser where they could see the tags. You would have to collect the tags anyway, and list them on a maintenance page akin to Ivan's covi lists. Petscan can perfectly do this with template tags on item talk pages, and this can also be automatically transferred to a suitable wiki page by bot. —MisterSynergy (talk) 09:44, 8 November 2018 (UTC)[reply]
@MisterSynergy: Also, the "create a talk page" approach for statements might result in issues that are never marked as resolved even after the statement's correction, and would be much harder to transclude to Wikipedias which might want to know that the data being used is potentially bad.

While random people visiting Wikidata items probably don't contribute measurably, I wonder what would happen if a Wikipedia decided to start automatically displaying "citation needed" tags for all unreferenced statements in Wikidata infoboxes. Presumably the same visibility would also be helpful for specific issues. (I assume that Wikipedias might prefer that situation over having more aesthetically pleasing but citation-less and unverified infobox data?)

(in reply to your point 1) I think it's reasonable to have a meta-property for items, since there are already meta-properties for properties (and permanent duplicated item (P2959) is arguably also a meta-property). Jc86035 (talk) 09:56, 8 November 2018 (UTC)[reply]
(1) The problem of forgotten tags exists for a statement-based approach as well. (2) From my experience, mainly at dewiki, Wikipedias tend to avoid using any (potentially) “problematic” statement at all; many even ignore all unreferenced statements; I don’t think we can or should expose such rather complex problems to Wikipedia readers on a large scale. (3) I don’t like most of the other meta statement properties as well; this one seems particularly dangerous. (4, new) We would need to define policies how to deal with controversial tags; at Wikipedias, editors fight a lot about the question whether a particular tag (template) is appropriate in a page or not; I’m glad we don’t have this yet at Wikidata. —MisterSynergy (talk) 17:22, 8 November 2018 (UTC)[reply]

@MisterSynergy: Using item talk pages works if the issue is a problem with the item as a whole, but it doesn't help to identify individual statements that might be problematic - unless you can think of a way to do that with a template? I can imagine a template highlighting specific properties that should be checked more carefully, for example. Also I haven't ever run across an item with such a template in Wikidata, are there some existing examples? ArthurPSmith (talk) 15:29, 8 November 2018 (UTC)[reply]
As far as I know, we do not have this yet in Wikidata. A statement-based approach might work for items and statements, but not for qualifiers and references, and probably also not well for ranking and snaktype issues. —MisterSynergy (talk) 17:22, 8 November 2018 (UTC)[reply]
Strong support for the big challenge of Wikidata mapping external concepts. In Sweden I start seeing the problem when external concept should be matched that doesnt have mapping relation type (P4390) SKOS exact match (Q39893449). Then we inside Wikidata needs to define

what kind of SKOS relationship an object inside Wikidata should have with the external domain e.g. close match (Q39893184),related match (Q39894604),broad match (Q39894595), narrow match (Q39893967)
should Wikidata have this concept
point out that there is a discussion somewhere e.g. on our "own" Phabricator platform e.g. or any other platform ongoing
having a property ==> that those "issues" could easy be part of Wikidata:WikiProject_property_constraints

I feel this is a complex process and we need to have more examples/ discussions internally and als externally to start understand how this need to be done. Marking objects were we see this challenge is an excellent start. We can today see a challenge what we inside WIkidata map as a church and the Swedish National heritage creates 2 objects for a church: One is just the building and the other is a container object for all objects next to the church. I guess in Wikipedia a church is a church but when we tries to match more specialist domains we will see that we maybe doesnt have the same granularity...and I guess WIkidata as a World wide site we will meet a lot of challenges....

I would also like to be able to combine this with a Phabricator ticket number... so issues/discussions can be tracked - Salgo60 (talk) 09:58, 8 November 2018 (UTC)[reply]

Support We are already tagging some issues like instance of (P31)statement with Gregorian date earlier than 1584 (Q26961029), but it would be better to have designated property for this. --Jarekt (talk) 13:16, 8 November 2018 (UTC)[reply]
Wait I think the general concept makes sense but we need to have more discussion about the optimal name. I also agree that incompletion shouldn't be ground for adding this tag. ChristianKl ❪✉❫ 19:13, 8 November 2018 (UTC)[reply]
- I think we should define some kind of workflow/tools to be used as this is complex. I created an EPIC T202530 "Feedback processes and tools for data-providers" to gather questions/thoughts like this in e.g. user stories - Salgo60 (talk) 09:44, 9 November 2018 (UTC)[reply]
@ChristianKl: Why not? For some items, particularly if there is to be a complex import for a subset of items which can't be defined through a trivial SPARQL query and which are edited frequently, it may be useful to temporarily add a tag to an item, regardless of whether or not the tag indicates incompletion. The name should be agreed upon, although perhaps it would be useful to have that discussion in a more visible place, since there is consensus for the property but the discussion has stalled. Jc86035 (talk) 16:48, 16 November 2018 (UTC)[reply]
If you can define such a query you can simply have a page with the list of items that have a particular incompletion. I don't see why such a list isn't doing the job. Anybody who actually looks at the item will be able to see themsevles that it's incomplete.ChristianKl ❪✉❫ 17:35, 17 November 2018 (UTC)[reply]
Oppose Why do we have to work twice when once is enough: if a simple error is found, just correct it instead of letting other persons doing the job. If there is a complex case and no easy way can be found to fix the problem I prefer to delete the statements or blank the item. Snipre (talk) 07:02, 26 February 2019 (UTC)[reply]
Oppose Better complete the gappy items. Nomen ad hoc (talk) 20:33, 2 July 2019 (UTC).[reply]