Hey everyone!
We have a first version of the quantities datatype available for testing now on test.wikidata.org. It still has a few rough edges that we need to fix before we can enable it on Wikidata but I wanted to give you a chance to test it now already and help find issues early.
Here's a test property using the quantities datatype: https://test.wikidata.org/wiki/Property:P63
Cheers Lydia
A few points:
* Population should not be negative, would be nice if you can define a min or max value in the property * it's possible to enter 42.23 * if entering 23,42 the result is only 23 * if I try to enter "twenty three" there is no hint that only numbers are accepted * someone should try to add a string via the api
Lukas
Am Fr 22.11.2013 00:01, schrieb Lydia Pintscher:
Hey everyone!
We have a first version of the quantities datatype available for testing now on test.wikidata.org. It still has a few rough edges that we need to fix before we can enable it on Wikidata but I wanted to give you a chance to test it now already and help find issues early.
Here's a test property using the quantities datatype: https://test.wikidata.org/wiki/Property:P63
Cheers Lydia
Perhaps automated constraint checking would be simpler to set up?
We have this for some properties already:
http://www.wikidata.org/wiki/Property_talk:P21
For population, for example, the check could be "is greater than or equal to 0, is a whole number"
Andrew.
On 22 November 2013 10:37, Lukas Benedix benedix@zedat.fu-berlin.de wrote:
A few points:
- Population should not be negative, would be nice if you can define a
min or max value in the property
- it's possible to enter 42.23
- if entering 23,42 the result is only 23
- if I try to enter "twenty three" there is no hint that only numbers
are accepted
- someone should try to add a string via the api
Lukas
Am Fr 22.11.2013 00:01, schrieb Lydia Pintscher:
Hey everyone!
We have a first version of the quantities datatype available for testing now on test.wikidata.org. It still has a few rough edges that we need to fix before we can enable it on Wikidata but I wanted to give you a chance to test it now already and help find issues early.
Here's a test property using the quantities datatype: https://test.wikidata.org/wiki/Property:P63
Cheers Lydia
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
As far as I know this is done by bots and not by the wikibase extension. Am I right with that?
Lukas
Am Fr 22.11.2013 13:46, schrieb Andrew Gray:
Perhaps automated constraint checking would be simpler to set up?
We have this for some properties already:
http://www.wikidata.org/wiki/Property_talk:P21
For population, for example, the check could be "is greater than or equal to 0, is a whole number"
Andrew.
On 22 November 2013 10:37, Lukas Benedix benedix@zedat.fu-berlin.de wrote:
A few points:
- Population should not be negative, would be nice if you can define a
min or max value in the property
- it's possible to enter 42.23
- if entering 23,42 the result is only 23
- if I try to enter "twenty three" there is no hint that only numbers
are accepted
- someone should try to add a string via the api
Lukas
Am Fr 22.11.2013 00:01, schrieb Lydia Pintscher:
Hey everyone!
We have a first version of the quantities datatype available for testing now on test.wikidata.org. It still has a few rough edges that we need to fix before we can enable it on Wikidata but I wanted to give you a chance to test it now already and help find issues early.
Here's a test property using the quantities datatype: https://test.wikidata.org/wiki/Property:P63
Cheers Lydia
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
You are correct.
John
On Friday, 22 November 2013, Lukas Benedix wrote:
As far as I know this is done by bots and not by the wikibase extension. Am I right with that?
Lukas
Am Fr 22.11.2013 13:46, schrieb Andrew Gray:
Perhaps automated constraint checking would be simpler to set up?
We have this for some properties already:
http://www.wikidata.org/wiki/Property_talk:P21
For population, for example, the check could be "is greater than or equal to 0, is a whole number"
Andrew.
On 22 November 2013 10:37, Lukas Benedix <benedix@zedat.fu-berlin.dejavascript:;>
wrote:
A few points:
- Population should not be negative, would be nice if you can define a
min or max value in the property
- it's possible to enter 42.23
- if entering 23,42 the result is only 23
- if I try to enter "twenty three" there is no hint that only numbers
are accepted
- someone should try to add a string via the api
Lukas
Am Fr 22.11.2013 00:01, schrieb Lydia Pintscher:
Hey everyone!
We have a first version of the quantities datatype available for testing now on test.wikidata.org. It still has a few rough edges that we need to fix before we can enable it on Wikidata but I wanted to give you a chance to test it now already and help find issues early.
Here's a test property using the quantities datatype: https://test.wikidata.org/wiki/Property:P63
Cheers Lydia
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikidata-l
--
The problem I see with this practice is that a user doesn't get any feedback that he is entering 'invalid' values.
Lukas
Am Fr 22.11.2013 16:19, schrieb John Lewis:
You are correct.
John
On Friday, 22 November 2013, Lukas Benedix wrote:
As far as I know this is done by bots and not by the wikibase extension. Am I right with that? Lukas Am Fr 22.11.2013 13:46, schrieb Andrew Gray: > Perhaps automated constraint checking would be simpler to set up? > > We have this for some properties already: > > http://www.wikidata.org/wiki/Property_talk:P21 > > For population, for example, the check could be "is greater than or > equal to 0, is a whole number" > > Andrew. > > On 22 November 2013 10:37, Lukas Benedix <benedix@zedat.fu-berlin.de <javascript:;>> wrote: >> A few points: >> >> * Population should not be negative, would be nice if you can define a >> min or max value in the property >> * it's possible to enter 42.23 >> * if entering 23,42 the result is only 23 >> * if I try to enter "twenty three" there is no hint that only numbers >> are accepted >> * someone should try to add a string via the api >> >> Lukas >> >> >> Am Fr 22.11.2013 00:01, schrieb Lydia Pintscher: >>> Hey everyone! >>> >>> We have a first version of the quantities datatype available for >>> testing now on test.wikidata.org <http://test.wikidata.org>. It still has a few rough edges that >>> we need to fix before we can enable it on Wikidata but I wanted to >>> give you a chance to test it now already and help find issues early. >>> >>> Here's a test property using the quantities datatype: >>> https://test.wikidata.org/wiki/Property:P63 >>> >>> >>> Cheers >>> Lydia >>> >> >> _______________________________________________ >> Wikidata-l mailing list >> Wikidata-l@lists.wikimedia.org <javascript:;> >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l > > _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <javascript:;> 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
On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix 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
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 wrote:
On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix 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 https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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.dewrote:
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 wrote:
On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix 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 https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing listWikidata-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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.dewrote:
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
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 wrote:
On Fri, Nov 22, 2013 at 4:11 PM, Lukas Benedix 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 https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing listWikidata-l@lists.wikimedia.orghttps://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 listWikidata-l@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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
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
Am 25.11.2013 06:45, schrieb Daniel A. R. Werner:
I can see two solutions to have this implemented: -A: Gadgets with hard coded property specific rules. Very Wikidata specific solution.
Eek.
-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 think the correct way to do this would be to allow Claims on Properties. That would basically be a generic, machine readable version of the constraint templates currently placed on the Property Talk pages. https://bugzilla.wikimedia.org/show_bug.cgi?id=49554
The question is then how the software would know how to interpret the properties used in these constraints. Could just be configurable URIs, mapping them to ValueValidators - not pretty, but practical.
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.
I think that parsing, validation and formatting should all be controlled by the backend. That improves consistency, avoids redundant code and I think the performance hit would be acceptable. https://bugzilla.wikimedia.org/show_bug.cgi?id=49186
-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.
This basically means making WikidataDataTypeBuilders work based on user defined constraints (using claims on the Property entity).
I agree that this should not be done in the first iteration of Quantity support, but we should discuss it and then decide whether we put it on the road map.
-- daniel
As long as it is possible to override it. There are all kinds of strange corner cases that we need to accommodate. For instance in elections to the Senate of the Republic of Ireland ( https://en.wikipedia.org/wiki/Seanad_%C3%89ireann the votes are calculated to 3 decimal places!
On Mon, Nov 25, 2013 at 11:36 AM, Daniel Kinzler < daniel.kinzler@wikimedia.de> wrote:
Am 25.11.2013 06:45, schrieb Daniel A. R. Werner:
I can see two solutions to have this implemented: -A: Gadgets with hard coded property specific rules. Very Wikidata
specific
solution.
Eek.
-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 think the correct way to do this would be to allow Claims on Properties. That would basically be a generic, machine readable version of the constraint templates currently placed on the Property Talk pages. https://bugzilla.wikimedia.org/show_bug.cgi?id=49554
The question is then how the software would know how to interpret the properties used in these constraints. Could just be configurable URIs, mapping them to ValueValidators - not pretty, but practical.
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.
I think that parsing, validation and formatting should all be controlled by the backend. That improves consistency, avoids redundant code and I think the performance hit would be acceptable. https://bugzilla.wikimedia.org/show_bug.cgi?id=49186
-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.
This basically means making WikidataDataTypeBuilders work based on user defined constraints (using claims on the Property entity).
I agree that this should not be done in the first iteration of Quantity support, but we should discuss it and then decide whether we put it on the road map.
-- daniel
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 25.11.2013 13:51, schrieb Joe Filceolaire:
As long as it is possible to override it. There are all kinds of strange corner cases that we need to accommodate. For instance in elections to the Senate of the Republic of Ireland (https://en.wikipedia.org/wiki/Seanad_%C3%89ireann the votes are calculated to 3 decimal places!
So, we are talking about hints, not contraints? Not sure I'd want that in the backend... Some JS looking at claims on the properties page might be best for that, not sure.
Such "constraint" claims could have qualifiers that mark them as being "soft" vs. "hard" constraints.
-- daniel
On Fri, Nov 22, 2013 at 10:52 PM, Denny Vrandečić vrandecic@gmail.com wrote:
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?
We will start with no constraints. I will not have the team spent time on this without us even knowing how much of an issue it is going to be and what kinds of constraints we need in the software if any.
Cheers Lydia
What are the plans to improve the user experience? Especially for fields where the input type is checked somehow.
Error messages a la "An error occurred while trying to perform save and because of this, your changes could not be completed." don't really help when I try to enter a URL to a property called "image". And clicking on details to find "Malformed input: http://foobar.org/image.png" is not better.
Lukas
Am Mo 25.11.2013 17:22, schrieb Lydia Pintscher:
On Fri, Nov 22, 2013 at 10:52 PM, Denny Vrandečić vrandecic@gmail.com wrote:
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?
We will start with no constraints. I will not have the team spent time on this without us even knowing how much of an issue it is going to be and what kinds of constraints we need in the software if any.
Cheers Lydia
On Mon, Nov 25, 2013 at 5:31 PM, Lukas Benedix benedix@zedat.fu-berlin.de wrote:
What are the plans to improve the user experience? Especially for fields where the input type is checked somehow.
Error messages a la "An error occurred while trying to perform save and because of this, your changes could not be completed." don't really help when I try to enter a URL to a property called "image". And clicking on details to find "Malformed input: http://foobar.org/image.png" is not better.
The plan is to improve them ;-) Sorry I don't know what kind of reply you are looking for. Help on the coding side welcome.
Cheers Lydia
The plan is to improve them ;-) Sorry I don't know what kind of reply
you are looking for. Help on the coding side welcome.
If you're looking for a "how" answer, maybe the message should say what exactly is expected as input ("correct input expected" do not count :).
Am 22.11.2013 11:37, schrieb Lukas Benedix:
A few points:
- Population should not be negative, would be nice if you can define a
min or max value in the property
User-defined constraints are a pretty big and complex issue. I agree that it would be nice, but it's something to be carefully discussed and designed.
- it's possible to enter 42.23
Sure, as it should be. Quantities are not restricted to integer values.
- if entering 23,42 the result is only 23
That's odd, that should result in 2342- the comma would be ignored as a "thousands separator".
Localized input (e.g. using "," as the decimal separator if the user interface is set to German) is not supported yet, but should definitely be implemented.
- if I try to enter "twenty three" there is no hint that only numbers
are accepted
I agree that the error messages could be more helpful, and should be made more visible.
-- daniel