I believe that having the system allow to define constraints on properties would result in a better user experience and could be seen as a means towards higher quality of content with less bot cleanups necessary. Users would immediately know whats wrong with their input (e.g. no negative numbers allowed). There are too many bot edits on Wikidata in general, this would just be one means to cut them down a little.
I can see two solutions to have this implemented: -A: Gadgets with hard coded property specific rules. Very Wikidata specific solution. -B: A generic constraint definition system for properties. No Wikidata specific JavaScript required but Wikidata specific rules on the properties would be defined by the community.
I would much rather prefer the second solution. And there are two ways to have that as well: -B1: Getting the JavaScript UI to read those property constraints before the Snak value gets sent to the backend for real, evaluating the value against the constraints, eventually notifying the user with a message instead of sending the value to the backend. -B2: Having this integrated on backend level.
(B1 Could be considered a clean non-wikidata specific solution of solution A above)
I would prefer B2 since it would concern changes done directly via the API as well. Either way, this would be quite some work to be implemented, so I don't think we will see this any time soon.
Cheers, Daniel
23. November 2013 11:13:05, Lukas Benedix:
I never said that it should not be possible to enter 'invalid' values.
On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix <benedix@zedat.fu-berlin.de mailto:benedix@zedat.fu-berlin.de> wrote:
The problem I see with this practice is that a user doesn't get any
feedback
that he is entering 'invalid' values.
Btw. the notification should not look like this: http://lbenedix.monoceres.uberspace.de/screenshots/8dqpasghc3_2013-11-23_11....
Am Sa 23.11.2013 02:42, schrieb Denny Vrandečić:
Wait, you're changing the discussion from 'the software should not allow it' to 'there should be a popup telling you...'.
The latter can be implemented by the community as additional JavaScript (I am not saying if this is a good idea. I am not a big fan of popups). The former is what I strongly advise against.
On Fri, Nov 22, 2013 at 5:27 PM, Lukas Benedix <benedix@zedat.fu-berlin.de mailto:benedix@zedat.fu-berlin.de> wrote:
Is it limiting your freedom, if a little popup comes up and tells you "maybe you should enter a positive integer here... if you insist on 123.45 press save, but the bots will come and revert your edit" Like a speed limit that is not limiting your freedom to speed, but maybe it reminds you to the consequences... Am Fr 22.11.2013 22:52, schrieb Denny Vrandečić:So instead better to limit your freedom to express yourself in the first place. I'd take the bot. At least in the history of the article it is recorded that it was tried to enter 123.45 for a population, and we can later figure out what was happening. Why not wait and see if this is really a problem? I wonder how many such mistakes will ever be entered, besides "jokes" and vandalism. And the latter is easier to catch if we don't require the pranksters to use data that sounds correct. Do we have any indication that contributors are being supported by a system that doesn't let them enter negative numbers for populations? On Fri, Nov 22, 2013 at 1:46 PM, Lukas Benedix <benedix@zedat.fu-berlin.de <mailto:benedix@zedat.fu-berlin.de>> wrote: I don't want to feel like John Connor... hunted by a bot that comes after my edits and reverts them only because I entered 123.45 for a property that should be an integer. Am Fr 22.11.2013 21:56, schrieb Denny Vrandečić:It is either obvious that they should be entering only integers or positive numbers, in which case such feedback isn't helpful, or it might end up being too restrictive again. Who tells me that a system like this won't get used in order to force cities to have a population of an integer bigger than 10,000? I understand the wish and desire to restrict user input, but I would like to remind everyone that Wikidata comes from the wiki side, which adheres more to the 'let's gather input and then verify it' than the 'let's make everyone give us correct input in the first place' side. On Fri, Nov 22, 2013 at 11:24 AM, Helder . <helder.wiki@gmail.com <mailto:helder.wiki@gmail.com>> wrote: On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix <benedix@zedat.fu-berlin.de <mailto:benedix@zedat.fu-berlin.de>> wrote: > The problem I see with this practice is that a user doesn't get any feedback > that he is entering 'invalid' values. +1 Helder _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l