Hi Lydia & all,
As promised before, I have collected a list of suggestions of what I noticed myself or others have noticed to be unhandy or something that would be great to be improved. The suggestions and ideas have not been searched for in Phabricator (as that is still difficult), so it is possible that some of the points are already in Phabricator or is already worked on. The suggestions are *not* sorted by importance, but tried to be grouped by subject/area.
I have tried to describe them as clear as possible, some with examples. Maybe some of them can be connected with Phabricator tasks.
I hope these ideas will help improve Wikidata to make the use of it better and easier.
Thanks! Romaine
*A. General*
A1. loading: large item pages with much statements and sitelinks are too heavy to load. For example items about countries, like Q30 (USA), make my (up-to-date) browser freeze (not responding) before it is loaded.
A2. missing labels: show on more places that the shown label of an item is not in the language of the user, but that the English version of the page is shown. (In the statements section it is shown that the label is not available in the language of the user, but is in English. Such is recommended to do on more places.) Like in the contributions page, there it is not shown that the shown label is in English instead of the language of the user.
A3. overview: make the overview of pages more compact (read: less white space, resulting in less annoying scrolling and having a full overview of all statements at once), or have a gadget/skin who can do that. If 10 statements have been added to a page, too much scrolling is needed because most of the page is empty with white. The labels & descriptions section has been made more compact recently. However, full labels of statements have to be shown in future as well.
A4. search: make it easier to search in the fields of other languages, especially when no label and/or description is given to an item, but also in other cases. (Regularly a subject is more known by the name in the other language than in the language set for the user.)
A5. search: make it possible to switch of searching in statements section (or something like that), because searching for example for "Gemini" gives too much noise. Each page that has as statement something with (in this example) Gemini, pops up in the search and makes it difficult to find the right item.
A6. search: make it possible to easily search for where a specific property with a specific Q or input is used. Like filling in P717:032 or P131:Q3150.
A7. tool request: tool to give an overview (table) of all items with a certain property (or Q, or label, etc.), and in a second column being able to set to show a specific statement (if added) to each of the rows. Example: municipalities in Brazil (Q3184121). In the fist column all pages with P31:Q3184121 (instance of: municipality of Brazil). In the second column being able to set P17 (country). A third column being able to set P131 (located in the administrative territorial entity). It should be possible to sort the overview (table) by column, so that it is possible to group all municipalities by state (and if none added empty, so these missing ones can be fixed).
It should also be possible to import data from an external source to match the items on Wikidata with the external source (and to see where the differences are). Example: it would be great to be able to match the municipality names of Brazil with data from an external source. Like for example population numbers, height of the town, km², ID code, and so on.
A8. tool request: having a list of items with coordinates but no country added, and a tool that gives a suggestion based on the coordinates in which country this subject is situated, a map of the coordinate on the country and buttons to confirm/reject the country. (Likewise WikiData Game)
*B. Labels/descriptions section*
B1. labels in other languages: make it possible (again) to see the full label in other languages, instead of only a part ending with ... . Especially with long labels we should not press edit and do something clumsy to be able to read the full label Example: less than half of the label is visible: https://www.wikidata.org/wiki/Q18032311?uselang=de Or: https://www.wikidata.org/wiki/Q18032986
B2. missing labels/descriptions: make it possible to have one click in an empty field ("No label defined yet" or "No description defined yet") to edit that field (and making that section full edibale), without having to press [ edit ] on top first.
B3. confusion: I still keep having that I click in the title field to add a title to an item in my language. (Maybe something so solve in combination with B2.)
B4. other languages: maker it easier to change fields for other languages which are not set in my preferences. Maybe this can be done by a second collapsible box, so that "In more languages" shows the languages a user has set in his preferences, and in the collapsible part of "All languages" (new part) all other languages can be changed. (instead of not so handy label lister)
B5. auto adding: make it possible to add the name of the person or the scientific name of species to all of those languages with the same alphabet/script. Example: https://www.wikidata.org/wiki/Q7298502 -> The name of this genus is for many languages the same and results in the same label for all of these languages.
*C. Statements section*
C1. order: make it possible to set a certain order of how statements are shown. Example: someone who adds often Commons categories if those are missing, that that user can set that Commons is shown first on every item. (And second Commons gallery, third ..., etc.) Having to search for a statement that varies on what position it is shown is really annoying after some items.
C2. order: make it possible to alphabetize the order of the statements (like a wikitable).
C3. duplicate: give a notice with selecting the right property, when a certain property is already used on that item.
C4. suggester: if no statements have been added, the suggester should suggest P31 (instance of) and P373 (Commons category) as those two are (almost?) always needed or possible and are generic.
C5. suggester: if I select a certain property as statement, and I start typing the first character(s) of the name of the subject, the suggester should actually suggest something that matches with the property. This is especially wanted with the use of P17 (country). Example: if I want to add the statement that a certain subject is located in country (P17) Albania, and I type an A, the suggester should give me first actual names of countries that start with an A instead of starting with A (letter of the alphabet), ampere, etc. If other suggestions are given when no (known) country names begin with the characters typed in the field it is fine, but please start first with actual names of countries that begin with the A, etc.
C6. suggester: better suggestions requested. Example: when I have added as statement P31:Q62832 (instance of: observatory), the next suggestion for a property should be P717 (Minor Planet Center observatory code).
C7. feature/gadget request: having one or more buttons on a page to repeat the one of the last 5 actions I have done on another page, like adding [ country: US ], or just [ country: ]. This would be especially handy for statements, but maybe elsewhere too.
C8. character sensitive: make characters not sensitive for diacritics https://en.wikipedia.org/wiki/Diacritic, ligatures https://en.wikipedia.org/wiki/Typographic_ligature, dashes (-), etc. Maybe this suggestion does not count for some other languages, but in Dutch the a and the ã (as example, also ä á à â etc) are considered to be the same character. For many words it is not always clear if it is written with or without diacritic. For example: is it Sao Paulo or São Paulo in Dutch? Also with or without a dash, example: Sint Maarten or Sint-Maarten. The second one (with -) is how we normally write it but the island name is without - is the official name. This issue concerns thousands of pages, but if we type it with or without a diacritic/ligature/dash/etc while it should be with it, or the other way round, the suggester does not suggest it.
C9. missing statements: give a notice on items which statements are missing. On the talk pages of properties (example P717 https://www.wikidata.org/wiki/Property_talk:P717) it is stated with what statements a property must be combined. If on an item a notice is shown or invitation is given to add the missing statements, it would make it easier to have more items more complete.
C10. quick adding: have a tool/pop-up/etc to be able to add quickly the country to an item based on a suggestion.
*D. Sitelinks section*
D1. language codes: if someone adds a language code in the field to add a new sitelink to an item, please interpret this actual as a language code. Users are used to use the language code and then add the sitelink. The language code is more common for many users: it is used in the url of the wiki, it is used with local interwikis, users have set in their preferences to show the language code only, have preferences to show the *In other languages* section on Wikipedia in their own language, and more. Users are used to use the language code, and this works also fast. Also the name of the language a language code is belonging to, differs for each language. Users often only add the language code and then press tab to go to the next field, but then get the wrong language. Examples: If you add "es" for Spanish to add a page on a Spanish language wiki, however the language suggester gives first the suggestion "Esperanto" (eo) and not "Spanish" (es). (Also español is normally alphabetized before Esperanto!) If you add "ro" for Romanian to add a page on a Romanian language wiki, however the language suggester gives first the suggestion "Romani" (rmy) and not "Romanian" (ro). If you add "ru" for Russian to add a page on a Russian language wiki, however the language suggester gives first the suggestion "Runa Simi" (qu), second "rumantsch" (rm) and not "Russian" (ru).
D2. language suggester localisation: have the language suggester using the language a user has set in his own preferences. Many users are multilingual, but not everywhere in the world people speak/write in English well.
D3. adding new sitelink: on the Dutch Wikipedia multiple times various users have indicated that they find themselves unable to add a new sitelink when they wrote an article, as they experience this section too difficult to use. Even while multiple other users have helped and explained this to them. Maybe this is because 1. users need to squeeze in a code and 2. the field to add the actual pagename is too few remarkable, users do not see where to add the sitelink..
D4. faster saving: make saving faster, long list of interwikis slow down adding an interwiki very much. Now it seems the software checks if any field has been changed, every row. Saving can maybe go faster when only those fields are checked where the cursor has been. This is also something that consumes much time in the labels and descriptions section if someone has 3+ languages set in his preferences. (In the previous version of the labels and descriptions section the alias fields coloured white when the cursor was put in that field.)
D5. easier Commons selection: make it easier to add a new Commons sitelink to the section *Other sites. *
*E. Outside Wikidata*
E1. Commons: show on Commons somewhere when a category, gallery page, institution page, template, file etc is used in a statement on Wikidata. If a page is renamed or deleted, this must be changed on Wikidata as well, but noticing where a page is used is not easy. If an image is linked in a statement on Wikidata, on the image page this is shown. Somehow this should also be implemented for categories, gallery pages, institution pages, templates, and others. This should be added to pages like Special:WhatLinksHere, Special:MovePage, Special:GlobalUsage
E2. Wikipedia/other wikis: develop an extension, that communities can enable, that shows on the bottom of articles, in the style of the category box, an automatic box with all the identifiers used for authority control https://www.wikidata.org/wiki/Q18614948 to replace templates like https://www.wikidata.org/wiki/Q5153934.
As an example of a step towards E1 ("outside Wikidata"), the list might remember the code-snippet that the DJ wrote for Commons,
https://commons.wikimedia.org/wiki/User:TheDJ/wdcat.js
If you add importScript('User:TheDJ/wdcat.js'); to your common.js file on Commons, then whenever you go to a Commons category that is the target of a P373 on Wikidata, it adds a link to the page that goes to Reasonator for the corresponding article-like Wikidata item.
It's something I've found very useful, eg working through the BBC YourPaintings list of painters on Mix'n'Match, and the corresponding tracking pages linked from https://en.wikipedia.org/wiki/Wikipedia:GLAM/Your_paintings/header to see what article-like Wikidata item (if any) a Commons category may relate to.
-- James.
On 02/04/2015 14:41, Romaine Wiki wrote:
[snip]
*E. Outside Wikidata*
E1. Commons: show on Commons somewhere when a category, gallery page, institution page, template, file etc is used in a statement on Wikidata. If a page is renamed or deleted, this must be changed on Wikidata as well, but noticing where a page is used is not easy. If an image is linked in a statement on Wikidata, on the image page this is shown. Somehow this should also be implemented for categories, gallery pages, institution pages, templates, and others. This should be added to pages like Special:WhatLinksHere, Special:MovePage, Special:GlobalUsage
E2. Wikipedia/other wikis: develop an extension, that communities can enable, that shows on the bottom of articles, in the style of the category box, an automatic box with all the identifiers used for authority control https://www.wikidata.org/wiki/Q18614948 to replace templates like https://www.wikidata.org/wiki/Q5153934.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hey Romain :)
Wow. That is a long list. Thanks a lot for taking the time to write it all up. Find my comments below.
Cheers Lydia
On Thu, Apr 2, 2015 at 3:41 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
Hi Lydia & all,
As promised before, I have collected a list of suggestions of what I noticed myself or others have noticed to be unhandy or something that would be great to be improved. The suggestions and ideas have not been searched for in Phabricator (as that is still difficult), so it is possible that some of the points are already in Phabricator or is already worked on. The suggestions are not sorted by importance, but tried to be grouped by subject/area.
I have tried to describe them as clear as possible, some with examples. Maybe some of them can be connected with Phabricator tasks.
I hope these ideas will help improve Wikidata to make the use of it better and easier.
Thanks! Romaine
A. General
A1. loading: large item pages with much statements and sitelinks are too heavy to load. For example items about countries, like Q30 (USA), make my (up-to-date) browser freeze (not responding) before it is loaded.
We've considerably improved loading times over the past 5 months. With the next deployment it should again improve some more. We'll keep pushing on this but it has taken a bit less priority after the improvements we've made until now.
A2. missing labels: show on more places that the shown label of an item is not in the language of the user, but that the English version of the page is shown. (In the statements section it is shown that the label is not available in the language of the user, but is in English. Such is recommended to do on more places.) Like in the contributions page, there it is not shown that the shown label is in English instead of the language of the user.
Noted. Adrian was working on this recently. Not finished yet though.
A3. overview: make the overview of pages more compact (read: less white space, resulting in less annoying scrolling and having a full overview of all statements at once), or have a gadget/skin who can do that. If 10 statements have been added to a page, too much scrolling is needed because most of the page is empty with white. The labels & descriptions section has been made more compact recently. However, full labels of statements have to be shown in future as well.
We'll be working on this as part of the redesign of the statements section. One big piece will be separating out the identifiers as discussed over the last days on this list.
A4. search: make it easier to search in the fields of other languages, especially when no label and/or description is given to an item, but also in other cases. (Regularly a subject is more known by the name in the other language than in the language set for the user.)
https://phabricator.wikimedia.org/T76150 should get us a long way here.
A5. search: make it possible to switch of searching in statements section (or something like that), because searching for example for "Gemini" gives too much noise. Each page that has as statement something with (in this example) Gemini, pops up in the search and makes it difficult to find the right item.
Ok.
A6. search: make it possible to easily search for where a specific property with a specific Q or input is used. Like filling in P717:032 or P131:Q3150.
That'd be queries we are working on.
A7. tool request: tool to give an overview (table) of all items with a certain property (or Q, or label, etc.), and in a second column being able to set to show a specific statement (if added) to each of the rows. Example: municipalities in Brazil (Q3184121). In the fist column all pages with P31:Q3184121 (instance of: municipality of Brazil). In the second column being able to set P17 (country). A third column being able to set P131 (located in the administrative territorial entity). It should be possible to sort the overview (table) by column, so that it is possible to group all municipalities by state (and if none added empty, so these missing ones can be fixed).
That might already be possible with one of Magnus tools? Maybe someone else knows.
It should also be possible to import data from an external source to match the items on Wikidata with the external source (and to see where the differences are). Example: it would be great to be able to match the municipality names of Brazil with data from an external source. Like for example population numbers, height of the town, km², ID code, and so on.
That is what a team of students is working on right now: checks against 3rd party databases.
A8. tool request: having a list of items with coordinates but no country added, and a tool that gives a suggestion based on the coordinates in which country this subject is situated, a map of the coordinate on the country and buttons to confirm/reject the country. (Likewise WikiData Game)
Ok. Probably not going to be done by the dev team but maybe someone else wants to pick it up :)
B. Labels/descriptions section
B1. labels in other languages: make it possible (again) to see the full label in other languages, instead of only a part ending with ... . Especially with long labels we should not press edit and do something clumsy to be able to read the full label Example: less than half of the label is visible: https://www.wikidata.org/wiki/Q18032311?uselang=de Or: https://www.wikidata.org/wiki/Q18032986
Yes. Should get better with next deployment.
B2. missing labels/descriptions: make it possible to have one click in an empty field ("No label defined yet" or "No description defined yet") to edit that field (and making that section full edibale), without having to press [ edit ] on top first.
Ok.
B3. confusion: I still keep having that I click in the title field to add a title to an item in my language. (Maybe something so solve in combination with B2.)
Noted. I realize there is still some usability issue there.
B4. other languages: maker it easier to change fields for other languages which are not set in my preferences. Maybe this can be done by a second collapsible box, so that "In more languages" shows the languages a user has set in his preferences, and in the collapsible part of "All languages" (new part) all other languages can be changed. (instead of not so handy label lister)
I think this is covered by https://phabricator.wikimedia.org/T92759
B5. auto adding: make it possible to add the name of the person or the scientific name of species to all of those languages with the same alphabet/script. Example: https://www.wikidata.org/wiki/Q7298502 -> The name of this genus is for many languages the same and results in the same label for all of these languages.
Ok. I am undecided if this should be built into Wikibase or a gadget. I am leaning towards the latter.
C. Statements section
C1. order: make it possible to set a certain order of how statements are shown. Example: someone who adds often Commons categories if those are missing, that that user can set that Commons is shown first on every item. (And second Commons gallery, third ..., etc.) Having to search for a statement that varies on what position it is shown is really annoying after some items.
That's a big one to tackle. There are a lot of open questions that we will need to tackle. I am hesitant to make this user-dependent. That'd imho be better done in a gadget. But I do want us to make pages more easily scannable and so on. Separating out identifiers will help here but there's more we can do. We just have to find a way to do it without compromising some of the other core principles of Wikidata like the software not knowing about classes.
C2. order: make it possible to alphabetize the order of the statements (like a wikitable).
Hmmm. Is alphabetical really a useful sort order for statements? If you know the labels by heart it can help obviously but for most people it probably wouldn't be too helpful? My feeling is we're serving everyone better with a more useful ordering.
C3. duplicate: give a notice with selecting the right property, when a certain property is already used on that item.
That's a good idea.
C4. suggester: if no statements have been added, the suggester should suggest P31 (instance of) and P373 (Commons category) as those two are (almost?) always needed or possible and are generic.
I think we've also fixed this one for the next deployment.
C5. suggester: if I select a certain property as statement, and I start typing the first character(s) of the name of the subject, the suggester should actually suggest something that matches with the property. This is especially wanted with the use of P17 (country). Example: if I want to add the statement that a certain subject is located in country (P17) Albania, and I type an A, the suggester should give me first actual names of countries that start with an A instead of starting with A (letter of the alphabet), ampere, etc. If other suggestions are given when no (known) country names begin with the characters typed in the field it is fine, but please start first with actual names of countries that begin with the A, etc.
We should have something like that indeed. It'll require quite some expansion on the work the students team did last year I believe.
C6. suggester: better suggestions requested. Example: when I have added as statement P31:Q62832 (instance of: observatory), the next suggestion for a property should be P717 (Minor Planet Center observatory code).
That should become better automatically as more statements are added to Wikidata.
C7. feature/gadget request: having one or more buttons on a page to repeat the one of the last 5 actions I have done on another page, like adding [ country: US ], or just [ country: ]. This would be especially handy for statements, but maybe elsewhere too.
That should indeed be a gadget I believe.
C8. character sensitive: make characters not sensitive for diacritics, ligatures, dashes (-), etc. Maybe this suggestion does not count for some other languages, but in Dutch the a and the ã (as example, also ä á à â etc) are considered to be the same character. For many words it is not always clear if it is written with or without diacritic. For example: is it Sao Paulo or São Paulo in Dutch? Also with or without a dash, example: Sint Maarten or Sint-Maarten. The second one (with -) is how we normally write it but the island name is without - is the official name. This issue concerns thousands of pages, but if we type it with or without a diacritic/ligature/dash/etc while it should be with it, or the other way round, the suggester does not suggest it.
Makes sense yeah.
C9. missing statements: give a notice on items which statements are missing. On the talk pages of properties (example P717) it is stated with what statements a property must be combined. If on an item a notice is shown or invitation is given to add the missing statements, it would make it easier to have more items more complete.
After we've overhauled the statement section we could for example add a section at the bottom showing the top 3 suggestions that you already get when clicking edit. This would make it more visible.
C10. quick adding: have a tool/pop-up/etc to be able to add quickly the country to an item based on a suggestion.
That'd go into a gadget.
D. Sitelinks section
D1. language codes: if someone adds a language code in the field to add a new sitelink to an item, please interpret this actual as a language code. Users are used to use the language code and then add the sitelink. The language code is more common for many users: it is used in the url of the wiki, it is used with local interwikis, users have set in their preferences to show the language code only, have preferences to show the In other languages section on Wikipedia in their own language, and more. Users are used to use the language code, and this works also fast. Also the name of the language a language code is belonging to, differs for each language. Users often only add the language code and then press tab to go to the next field, but then get the wrong language. Examples: If you add "es" for Spanish to add a page on a Spanish language wiki, however the language suggester gives first the suggestion "Esperanto" (eo) and not "Spanish" (es). (Also español is normally alphabetized before Esperanto!) If you add "ro" for Romanian to add a page on a Romanian language wiki, however the language suggester gives first the suggestion "Romani" (rmy) and not "Romanian" (ro). If you add "ru" for Russian to add a page on a Russian language wiki, however the language suggester gives first the suggestion "Runa Simi" (qu), second "rumantsch" (rm) and not "Russian" (ru).
Thanks. Will look into it.
D2. language suggester localisation: have the language suggester using the language a user has set in his own preferences. Many users are multilingual, but not everywhere in the world people speak/write in English well.
I'll have to look into it more. The issue here is that language != site. For example we have Commons, simple and Wikidata in there.
D3. adding new sitelink: on the Dutch Wikipedia multiple times various users have indicated that they find themselves unable to add a new sitelink when they wrote an article, as they experience this section too difficult to use. Even while multiple other users have helped and explained this to them. Maybe this is because 1. users need to squeeze in a code and 2. the field to add the actual pagename is too few remarkable, users do not see where to add the sitelink..
That's not good. I will investigate more.
D4. faster saving: make saving faster, long list of interwikis slow down adding an interwiki very much. Now it seems the software checks if any field has been changed, every row. Saving can maybe go faster when only those fields are checked where the cursor has been. This is also something that consumes much time in the labels and descriptions section if someone has 3+ languages set in his preferences. (In the previous version of the labels and descriptions section the alias fields coloured white when the cursor was put in that field.)
Making that faster is on my list but other things take priority (statement section redesign, queries, unit support, better watchlist integration).
D5. easier Commons selection: make it easier to add a new Commons sitelink to the section Other sites.
I assume the issue is that one needs to know that Commons is an option. Will look into it more. Maybe for this section suggestions can work.
E. Outside Wikidata
E1. Commons: show on Commons somewhere when a category, gallery page, institution page, template, file etc is used in a statement on Wikidata. If a page is renamed or deleted, this must be changed on Wikidata as well, but noticing where a page is used is not easy. If an image is linked in a statement on Wikidata, on the image page this is shown. Somehow this should also be implemented for categories, gallery pages, institution pages, templates, and others. This should be added to pages like Special:WhatLinksHere, Special:MovePage, Special:GlobalUsage
Makes sense. I think this is something best tracked by a bot at this point.
E2. Wikipedia/other wikis: develop an extension, that communities can enable, that shows on the bottom of articles, in the style of the category box, an automatic box with all the identifiers used for authority control to replace templates like https://www.wikidata.org/wiki/Q5153934.
Sounds like a nice project for a hackathon :)
Thanks again for taking the time to write all this down.
Cheers Lydia
Hoi,
A8. tool request: having a list of items with coordinates but no country added, and a tool that gives a suggestion based on the coordinates in
which
country this subject is situated, a map of the coordinate on the country
and
buttons to confirm/reject the country. (Likewise WikiData Game)
Ok. Probably not going to be done by the dev team but maybe someone else wants to pick it up :)
It does not make sense to couple coordinates with countries... The battle of Stalingrad for instance was firmly in the USSR and not in modern day Russia. Thanks, GerardM
Hi,
On 05-04-15 16:10, Gerard Meijssen wrote:
It does not make sense to couple coordinates with countries... The battle of Stalingrad for instance was firmly in the USSR and not in modern day Russia.
Why not? Every Place has a history that can't be evaded. The beautiful part of Linked Data is these little graphs one gets when joining data on defined properties. For instance joining data based on coordinates would provide an insight into the history of a certain Place.
The battle of Stalingrad is an event that has taken Place at Stalingrad, which is now Wolgograd, both have the same coordinates. There are even more places at these coordinates :-)
Cheers, Roland
Hoi, Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the battle of Stalingrad with modern day Russia is wrong on so many levels. At the time it was Stalingrad, hence the name. It will never be the battle of Wolgograd. Thanks, GerardM
On 7 April 2015 at 23:27, Roland Cornelissen metamatter.nl@gmail.com wrote:
Hi,
On 05-04-15 16:10, Gerard Meijssen wrote:
It does not make sense to couple coordinates with countries... The battle of Stalingrad for instance was firmly in the USSR and not in modern day Russia.
Why not? Every Place has a history that can't be evaded. The beautiful part of Linked Data is these little graphs one gets when joining data on defined properties. For instance joining data based on coordinates would provide an insight into the history of a certain Place.
The battle of Stalingrad is an event that has taken Place at Stalingrad, which is now Wolgograd, both have the same coordinates. There are even more places at these coordinates :-)
Cheers, Roland
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
2015-04-09 8:29 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the battle of Stalingrad with modern day Russia is wrong on so many levels. At the time it was Stalingrad, hence the name. It will never be the battle of Wolgograd.
I believe that you should have a "Not applicable" button to click for these cases.
C
Hoi, The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world war. My point is that we should not forget this. The battle of Uhud was not in Saudi Arabia either... Thanks, GerardM
On 13 April 2015 at 12:10, Cristian Consonni kikkocristian@gmail.com wrote:
2015-04-09 8:29 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the
battle
of Stalingrad with modern day Russia is wrong on so many levels. At the
time
it was Stalingrad, hence the name. It will never be the battle of
Wolgograd.
I believe that you should have a "Not applicable" button to click for these cases.
C
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
2015-04-13 14:00 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world war. My point is that we should not forget this. The battle of Uhud was not in Saudi Arabia either...
Ok, but I think that having a system that, for examples, cross checks dates and presents "URSS" as a possibility would be much more complicated to build.
I think that the Wikidata game (or a similar game-like system) can not address all possible complicated scenarios, and thus there will always be some cases that should be handled directly editing Wikidata.
I was following Magnus here, in the post where he introduces the Wikidata Game[1]: «So what’s the approach here? I feel the crucial issue for gamification is breaking complicated processes down into simple actions, which themselves are just manifest decisions – “A”, “B”, or “I don’t want to decide this now!”.
[...]
Of course, this simplification misses a lot of “fine-tuning” – what if you are asked to decide the gender of an item that has been accidentally tagged as “person”? What if the gender of this person is something other than “male” or “female”? Handling all these special cases would, of course, be possible – but it would destroy the simplicity of the three-button interface. The games always leave you a “way out” – when in doubt, skip the decision. Someone else will take care of it, eventually, probably on Wikidata proper.»
With this premise, I think that Romaine's proposal for a game is absolutely doable and a good idea.
C
Of course there will always be some things too complicated to be reasonably expressed in Wikidata, or hard to process by software.
But in the case of historical datas, we better have to think of a common and practical representation and ways for tools to process datas, because this is totally a WIkipedia common usecase :) There is already tools to draw wars in a map and chronological datas.
2015-04-13 14:54 GMT+02:00 Cristian Consonni kikkocristian@gmail.com:
2015-04-13 14:00 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world
war.
My point is that we should not forget this. The battle of Uhud was not in Saudi Arabia either...
Ok, but I think that having a system that, for examples, cross checks dates and presents "URSS" as a possibility would be much more complicated to build.
I think that the Wikidata game (or a similar game-like system) can not address all possible complicated scenarios, and thus there will always be some cases that should be handled directly editing Wikidata.
I was following Magnus here, in the post where he introduces the Wikidata Game[1]: «So what’s the approach here? I feel the crucial issue for gamification is breaking complicated processes down into simple actions, which themselves are just manifest decisions – “A”, “B”, or “I don’t want to decide this now!”.
[...]
Of course, this simplification misses a lot of “fine-tuning” – what if you are asked to decide the gender of an item that has been accidentally tagged as “person”? What if the gender of this person is something other than “male” or “female”? Handling all these special cases would, of course, be possible – but it would destroy the simplicity of the three-button interface. The games always leave you a “way out” – when in doubt, skip the decision. Someone else will take care of it, eventually, probably on Wikidata proper.»
With this premise, I think that Romaine's proposal for a game is absolutely doable and a good idea.
C
[1] http://magnusmanske.de/wordpress/?p=203
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
2015-04-13 14:54 GMT+02:00 Cristian Consonni kikkocristian@gmail.com:
With this premise, I think that Romaine's proposal for a game is absolutely doable and a good idea.
I want to clarify, I mean that I agree with Gerard that the best indication for "country" for "Battle of Stalingrad" is URSS, I simply say that a game should keep it simple (so in this case, either the system is able to infer URSS as a possibility to present to the user or otherwise the user should (be instructed to) say "not sure").
I am much less convinced about the "citizenship" violations. Even if I believe that citizenship is a concept introduced with the modern nation-state, for a variety of reasons this is anyway applied to people that have lived before that state(at least in is modern form) was established.
For example, Galileo Galilei is reported as an error but all the biggest Wikipedias (and some others that I am able to read) state that Galileo Galilei was Italian (catalan Wikipedia says that he was Tuscan in the artcle, but caegorizes him in the category "Físics italians" (Italian pysicists) and "Astrònoms italians" (Italian astronomers). On the other hand, the use of the name "Italia" to indicate at least a portion of present-day Italy goes back in history and there are mentions in documents from at least 42 b.C. (and possibly this will be the same for most Europe).
C
This is an example of a more general problem, I think - "country" is treated as an indefinite concept, which breaks down for historic people as well. To take Magnus's example, Wikidata records that Henry VIII was a citizen of the UK, which would no doubt have surprised him (https://www.wikidata.org/wiki/Q38370).
Perhaps what we want is to figure out some way that "country" (P17) and "citizenship" (P27) can have robust constraints based on date of birth/death or on date of an event, so that - for example - anyone who is reported as having citizenship of the UK has to have been born before or died after 1707. For something like the battle, the constraint would be that the event has to have happened while the P17 country was in existence.
I don't know if we can do anything this sophisticated with the current constraints system - perhaps it would have to be organised on a country-by-country basis, one report for the UK, then the USSR, and so on as we define the cases. Perhaps something to look at doing a year down the line, when we've imported a lot of data we can fix ;-)
Andrew.
On 13 April 2015 at 13:00, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world war. My point is that we should not forget this. The battle of Uhud was not in Saudi Arabia either... Thanks, GerardM
On 13 April 2015 at 12:10, Cristian Consonni kikkocristian@gmail.com wrote:
2015-04-09 8:29 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the battle of Stalingrad with modern day Russia is wrong on so many levels. At the time it was Stalingrad, hence the name. It will never be the battle of Wolgograd.
I believe that you should have a "Not applicable" button to click for these cases.
C
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
Well, getting a list of "violations" per country would not be hard, given the dates. There are, for example, >2,300 UK citizens who died 1706 or earlier: https://tools.wmflabs.org/autolist/?language=en&project=wikipedia&ca...
It would be possible to generate a daily constraint violation report for more such conditions, given a list of valid data ranges (e,g, "Q145 / 1701 / now" for UK). I'd volunteer, if someone makes a machine-readable list (table?) on a wiki page :-)
A more fine-tuned bot could actually auto-replace some, if the "new" country is the same or larger as the "old" one. But given the numbers, it is probably not necessary to toy with such forces (we can fix a few thousand "by hand" once; new entries should be low in numbers).
On Mon, Apr 13, 2015 at 2:22 PM Andrew Gray andrew.gray@dunelm.org.uk wrote:
This is an example of a more general problem, I think - "country" is treated as an indefinite concept, which breaks down for historic people as well. To take Magnus's example, Wikidata records that Henry VIII was a citizen of the UK, which would no doubt have surprised him (https://www.wikidata.org/wiki/Q38370).
Perhaps what we want is to figure out some way that "country" (P17) and "citizenship" (P27) can have robust constraints based on date of birth/death or on date of an event, so that - for example - anyone who is reported as having citizenship of the UK has to have been born before or died after 1707. For something like the battle, the constraint would be that the event has to have happened while the P17 country was in existence.
I don't know if we can do anything this sophisticated with the current constraints system - perhaps it would have to be organised on a country-by-country basis, one report for the UK, then the USSR, and so on as we define the cases. Perhaps something to look at doing a year down the line, when we've imported a lot of data we can fix ;-)
Andrew.
On 13 April 2015 at 13:00, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world
war.
My point is that we should not forget this. The battle of Uhud was not in Saudi Arabia either... Thanks, GerardM
On 13 April 2015 at 12:10, Cristian Consonni kikkocristian@gmail.com wrote:
2015-04-09 8:29 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the battle of Stalingrad with modern day Russia is wrong on so many levels. At
the
time it was Stalingrad, hence the name. It will never be the battle of Wolgograd.
I believe that you should have a "Not applicable" button to click for these cases.
C
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
--
- Andrew Gray andrew.gray@dunelm.org.uk
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Huh, just when I sent this mail, I realized that there is a database with nation dates, it's called Wikidata...
So I present: https://tools.wmflabs.org/wikidata-todo/wrong_nationality.html
Have fun!
On Mon, Apr 13, 2015 at 3:43 PM Magnus Manske magnusmanske@googlemail.com wrote:
Well, getting a list of "violations" per country would not be hard, given the dates. There are, for example, >2,300 UK citizens who died 1706 or earlier:
https://tools.wmflabs.org/autolist/?language=en&project=wikipedia&ca...
It would be possible to generate a daily constraint violation report for more such conditions, given a list of valid data ranges (e,g, "Q145 / 1701 / now" for UK). I'd volunteer, if someone makes a machine-readable list (table?) on a wiki page :-)
A more fine-tuned bot could actually auto-replace some, if the "new" country is the same or larger as the "old" one. But given the numbers, it is probably not necessary to toy with such forces (we can fix a few thousand "by hand" once; new entries should be low in numbers).
On Mon, Apr 13, 2015 at 2:22 PM Andrew Gray andrew.gray@dunelm.org.uk wrote:
This is an example of a more general problem, I think - "country" is treated as an indefinite concept, which breaks down for historic people as well. To take Magnus's example, Wikidata records that Henry VIII was a citizen of the UK, which would no doubt have surprised him (https://www.wikidata.org/wiki/Q38370).
Perhaps what we want is to figure out some way that "country" (P17) and "citizenship" (P27) can have robust constraints based on date of birth/death or on date of an event, so that - for example - anyone who is reported as having citizenship of the UK has to have been born before or died after 1707. For something like the battle, the constraint would be that the event has to have happened while the P17 country was in existence.
I don't know if we can do anything this sophisticated with the current constraints system - perhaps it would have to be organised on a country-by-country basis, one report for the UK, then the USSR, and so on as we define the cases. Perhaps something to look at doing a year down the line, when we've imported a lot of data we can fix ;-)
Andrew.
On 13 April 2015 at 13:00, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The point is very much that the battle WAS in the USSR. It is not "not applicable" it is one of the most important battles in the second world
war.
My point is that we should not forget this. The battle of Uhud was not
in
Saudi Arabia either... Thanks, GerardM
On 13 April 2015 at 12:10, Cristian Consonni kikkocristian@gmail.com wrote:
2015-04-09 8:29 GMT+02:00 Gerard Meijssen gerard.meijssen@gmail.com:
Because the battle of Stalingrad as a battle was not fought by modern day Russia, it was fought by the USSR and Nazi Germany. Associating the battle of Stalingrad with modern day Russia is wrong on so many levels. At
the
time it was Stalingrad, hence the name. It will never be the battle of Wolgograd.
I believe that you should have a "Not applicable" button to click for these cases.
C
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
--
- Andrew Gray andrew.gray@dunelm.org.uk
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
2015-04-13 18:46 GMT+02:00 Magnus Manske magnusmanske@googlemail.com:
So I present: https://tools.wmflabs.org/wikidata-todo/wrong_nationality.html
All links to Wikidata are missing the "/wiki/" part.
C
Hi,
On 05-04-15 16:10, Gerard Meijssen wrote:
It does not make sense to couple coordinates with countries... The battle of Stalingrad for instance was firmly in the USSR and not in modern day Russia.
Why not? Every Place has a history that can't be evaded. The beautiful part of Linked Data is these little graphs one gets when joining data on defined properties. For instance joining data based on coordinates would provide an insight into the history of a certain Place.
The battle of Stalingrad is an event that has taken Place at Stalingrad, which is now Wolgograd, both have the same coordinates. There are even more places at these coordinates :-)
Cheers, Roland
Any chance you could put this list up on the wiki? Perhaps in your user space. It'd be interesting to see these issues end up being tracked in Phabricator and hopefully fixed. :)
Yours,
-- Tom Morris http://tommorris.org/