Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Also see status updates to keep up-to-date on important things around Wikidata.
Requests for deletions can be made here.
Merging instructions can be found here.

IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2017/08.






for permissions

for deletions


for deletion

for comment

and imports


a query



Nonsense imported from Geonames[edit]

Thanks to the bot filling the Cebuano Wikipedia (Q837615) with all the items in geonames, and the bot importing all the pages from ceb to here, we now have a lot of nonsense items here. Just my latest picks from looking around Thailand items - Mae Hong Son (Q35440991) and Mae Hong Son (Q35441002) claim to be about a stream in Thailand. But for both the coordinates are in Laos, and there nothing but jungle there, not even a rivulet to be seen in Google Earth. There is a small river with that name in Thailand however which I now added manually (Mae Hong Son River (Q35513098)). Another one - Khuan Khaeng (Q31686472) and Khuan Khaeng (Q31372043) seem to be two peaks of the same hill, in this case the duplication was already done by the GNS-UFI database from which geonames imported them. But the problem - due to the inaccurate coordinates the bot gave the hill an elevation of 94 m, but looking at Google Maps it seems to be about 330 m. To make it worse - the bot who imported that statement did not even add a imported from (P143) reference, so it impossible to see how the bogus heights came here. I am sure this is only the tip of the iceberg, so I worry our database has been screwed up with bogus data now :-( Ahoerstemeier (talk) 14:43, 8 August 2017 (UTC)

There is a dedicated project on svwiki: sv:Wikipediadiskussion:Projekt alla platser-städning to handle this. Users like Kitayama (talkcontribslogs) and Taxelson (talkcontribslogs) have made thousands of deletions to clean up the mess. It looks far worse for cebwiki, very little cleanup is done there, and the botrun has edited that project much longer. -- Innocent bystander (talk) 15:28, 8 August 2017 (UTC)
If its already known that this bot creates so many nonsense articles, why do we still import them here before giving them at least a basic check for validity? Ahoerstemeier (talk) 15:34, 8 August 2017 (UTC)
At a minimum, articles that get deleted at svwiki could have their equivalent deleted from here and, if possible, from cebwiki as well.
--- Jura 16:27, 8 August 2017 (UTC)
The deleted pages are easy to find, but many articles on svwiki are instead merged and redirected, without us noticing where and why. Sometimes the item could stay as fulfilling notability here. Other times, they should be deleted since we do not want items about glitches in the GeoNames database. -- Innocent bystander (talk) 19:01, 8 August 2017 (UTC)
It is better to have deprecated value(s) to avoid re-entry of fake objects.
Question is how many of such items we could allow.
Geonames should remove items at their side, then we would remove external ids. d1g (talk) 20:36, 8 August 2017 (UTC)
Geonames is kind of a Wiki as well - I was able to delete those two wrong river entries there. Ahoerstemeier (talk) 21:00, 8 August 2017 (UTC)
@Ahoerstemeier: And in a wiki you can be reverted, as I have been, so watch out! -- Innocent bystander (talk) 03:48, 9 August 2017 (UTC)

The problem mentioned here is really a disaster, eventually. I am losing hours every month trying to fix a tiny part of the damage this bot has created and keeps creating. It is almost impossible to work on mountains in Canada and Australia for instance, because of all the Wikimedia duplicated page (Q17362920) it has generated along internal borders – summits in two provinces, territories or States at a time have, for some reason, been created twice. And again this is a very specific part of the issue, that in fact keeps growing right now. I have noticed this week that hell has just come recently to American protected areas. I am currently merging hundreds of items on refuges because in cebuano it was so important for them to read machine-written stuff on migratory birds of Virginia and the like. Thank you if you can stop this for good. Thierry Caro (talk) 04:39, 9 August 2017 (UTC)

Maybe a new P31 value for anything that hadn't been confirmed with other sources would be a solution. It can be set with preferred rank and avoids that people keep getting these items. Otherwise, it's indeed hard to avoid that these are re-created.
--- Jura 04:59, 9 August 2017 (UTC)
A mountain can have several summits and we can have one item for each, but GeoNames is not a good enough source for that kind of information. -- Innocent bystander (talk) 06:13, 9 August 2017 (UTC)

These items exist in ceb: and sv: and I guess they are created in other Wikipedias manually at different rates, as geographical article coverage is improve. So, I don't think we should delete them here. I think we need to set a guideline about how to maintenance all these Geonames items. We need a way to state in items which ones were reviewed and are OK and which ones are wrong (removing wrong statements or set them as "unknown value"). Some statistics pages about done/removed/todo status would help too (bot generated) to see the progress. There are different subclass of incorrect info (height, coordinates, place names, country, etc). All the applied corrections should be moved to Geonames, so their database is improved and we don't get again wrong data. Any needed changes in ceb: and sv: articles should be applied there too, and if we delete full wrong items, ceb: and sv: should delete them too. It is a hard task, but we as a community must do it soon or later. We could use the visualization capabilities of Wikidata Query Service (maps) to make easier to work on this task. About the alleged wrong river info, we should check they aren't subterranean or historical rivers, so they aren't shown in maps or satellite images (two possibilities I just imagined). Emijrp (talk) 10:39, 9 August 2017 (UTC)

One reason I can see has causes "duplicate" rivers, but also lakes, islands and groups of islands and many more, is that the name of the river has been written in several places of one or several maps. It look like GeoNames has scraped names from maps and put them in their database, not always checking for duplicates or identified what exactly the name is describing. I have many times complained about the quality of the "populated place"-items in GeoNames. GeoNames is not a good enough source to tell if a populated place exists in real life or not. Many times these populated places are instead administrative units. Many populated places share the name of an administrative unit, but far from always. -- Innocent bystander (talk) 16:32, 9 August 2017 (UTC)
  • I don't think we should rely on cebwiki/svwiki/Geonames to delete items before we remove items from what appears to be valid ones at Wikidata. Given the errors found with these entries in general, I don't think we can assimilate anything that hasn't been otherwise referenced as valid.
    --- Jura 07:23, 10 August 2017 (UTC)
A big part of the geonames items are in fact from the GEOnet Names Server (Q1194038) database, which by itself is far more reliable - but still has some duplicates because what they did for many countries was scraping all names from the maps. At least for rivers I haven't noticed an duplicates in there so far, they were all introduced by geonames themselves; for mountain ranges I have seen a few dupes in GNS as well. Ahoerstemeier (talk) 08:13, 10 August 2017 (UTC)
Maybe we just need to move a model where we add these as names for a feature and not as features with that name.
--- Jura 08:22, 10 August 2017 (UTC)

To demonstrate how much work is demanded. User:Kitayama has on svwiki for 36 days made clean up in bot created articles only related to Sweden. Lsjbot never came to Sweden on svwiki. The bot stopped before it came there. But there were still thousands of pages with links to things related to the small country of Sweden. Only to clean up those took one user 36 days, and that on svwiki alone. How much time it would take here and on cebwiki, I do not know. -- Innocent bystander (talk) 06:52, 14 August 2017 (UTC)

  • Personally, I'm much in favor of adding P31=Q35779580 with preferred rank to any Lsjbot-entry that doesn't any references. As items get completed, we can remove it.
    --- Jura 07:31, 14 August 2017 (UTC)

Can we stop this nonsense[edit]

I am fed up with the continuous idea that other parties like GeoNames are problematic while in reality it is our own intransigence to cooperate that is largely to blame. Take GeoNames, they are interested in cooperating with us. At the time we closed the door on them "because their data was not good enough". Now we have a situation that is substantially worse. Because of this intransigence, the data was imported anyway in several Wikipedias. There is no cooperation and the current proposals makes things worse.

So what we should do instead is linking to the GeoNames database and keep track of the changes that are happening there as well. Once we start collaborating, we can track the changes at Wikidata and compare them with what exists at the Wikipedias. We should work with LSJBOT and not actively discourage him to cooperate with us. We should do better because we are supposed to be a community that cares about data and know about data. Thanks, GerardM (talk) 09:09, 14 August 2017 (UTC)

Plan moving forward[edit]

How should be go about improving the situation? Beyond big words, I think we need specific steps that allow us to identify the quality of each item.
--- Jura 08:17, 15 August 2017 (UTC)

Well, I had a plan to download the Q34-part of GeoNames and compare what I found there with how it is used on Wikidata/pedia. I started doing it as a part of evaluating the quality of GeoNames before the Lsjbot-project started. I quit at some point, probably because I only have 24 hours a day, and some of that time is used for sleeping, family, job and other things in life. I guess it would be a good idea to start doing that again. -- Innocent bystander (talk) 09:32, 15 August 2017 (UTC)
No big words, just some common sense. First, quality of each item is often binary so that approach does not help us. It is not the only way to approach both quality and cooperation. The first thing we do is to agree on what we share that is the same. Then we follow up with the shared information that differs in detail. This is where we want to find out either way what is correct. Systemic differences are identified in this way as well.
All the time results are shared with our partner in cooperation..
In the case of GeoNames, we have a situation that is not in the best interest of both Wikidata, GeoNames and Wikimedia. The first thing to accomplish is that we have GeoNames identifiers for all the items that are associated through Wikipedias with GeoNames. Then we compare the values with GeoNames and what we are informed about from the Wikipedias. In the cooperation with GeoNames, the information in the Wikipedias are secondorary as there are no methods for the continuous verification and validation of differences.
This brings me to my main point. The LSJbot used static information from GeoNames to produce texts in several Wikipedias. When we import the data in Wikidata and allow for the caching of generated texts in stead of the saving of generated texts, we allow for the import of data "unverified" at our end and still provide the best information.
The notion that every item has to be correct is a fallacy and it has brought us where we are. No cooperation, no improvement and a deficient service to the Wikipedias. Thanks, GerardM (talk) 09:32, 15 August 2017 (UTC)

Approach : comparison by country[edit]

To quote Innocent bystander: "Well, I had a plan to download the Q34-part of GeoNames and compare what I found there with how it is used on Wikidata/pedia."

I think that could work. At some point you will end up with things that are (a) unmatched, (b) Ljs-only texts, (c) things that match other references (preferably on items), and (d) things that integrate with other Wikipedia articles. (c) and (d) shouldn't be an issue.
--- Jura 09:45, 15 August 2017 (UTC)

One problem is that I have good reputation here and know how to convince others here. But I do not have what is needed to convince GeoNames that this does not exists in real life. From the maps they have used as source, it looks like it exits, but I know that it doesn't. There exists something here with this name in this here, but it is not what GeoNames says it is. My changes to the GeoNames database has this far been reverted. -- Innocent bystander (talk) 09:55, 15 August 2017 (UTC)
  • I don't think that we need to be perfectly in sync with Geonames nor that users at Wikidata should be asked to edit Geonames directly. Otherwise one could just build a dynamic link to their database. If there is status here that identifies an item as (b) or maybe (former b) that could be sufficient.
    --- Jura 10:04, 15 August 2017 (UTC)

Approach : settlements and municipalities[edit]

Another nonsense spam by ceb wikipedia is the duplication of most human settlement placenmanes in Germany (and in many other countries). At de.wikipedia and in most other wikipedias there is good reason to have the municipality and the main (often only) settlement in that municipality of the same name in one article. Any intelligent human would always do this. Not the ceb GeoNames bots. Hence, we have thousands and thousands of useless Wikidata items about that clutter our database. Personally, I'd prefer to have all Wikidata items deleted if there are no other than bot generated articles behind it AND no "human" interaction in the version history. --Anvilaquarius (talk) 10:08, 16 August 2017 (UTC)

You do not get it. Nonsense .. any intelligent human .. Conflating the consequence of our actions with the project the data comes from. I prefer us to work together and not insult others. Thanks, GerardM (talk) 15:09, 16 August 2017 (UTC)
No, you don't get it. Bots aren't human and hence cannot be insulted. But they are also not human and hence should not be allowed to conquer Wikimedia projects by spamming. --Anvilaquarius (talk) 15:41, 18 August 2017 (UTC)
  • There are two things: (a) which ones should have items and (b) for which Wikipedia can (should/must/could) write articles.
    As municipalities can change over time, I don't think it's a good idea to limit oneself to municipalities for (a). The problem arises when we have several items for identically named settlements at similar (rounded) coordinates with no other references. For these it may be good idea to focus on a single one.
    (b) is really an editorial decision up to each Wikipedia. Focusing on municipalities has the disadvantage that one has to merge these articles continuously (depending on the country).
    --- Jura 09:40, 17 August 2017 (UTC)
  • @GerardM: it's not just human settlements that have been duplicated, but other types of mapped entities, at least as far as I can figure. I ran into this a while ago with the import from svwiki (and now with cebwiki links) for "Victoria Park" in New South Wales, Australia. I don't know if this is all of them, but we have at least Victoria Park (Q21935747), Victoria Park (Q21935739), Victoria Park (Q21935740), Victoria Park (Q21935749), Victoria Park (Q21935743) and Victoria Park (Q21935783) all generated from geonames. I think these are all duplicates of Victoria Park Nature Reserve (Q7926935) - at least that's the only "Victoria Park" I can find via Google Maps in New South Wales. Mapping the locations cited in the svwiki and cebwiki entries with Google Maps shows the locations to be pretty clearly not parks (either residential/commercial parts of small towns, or next to a road in the middle of nowhere.) How do you or anybody else propose we get this all fixed? Will geonames actually clean up their records at all? How do we prove to them these are wrong? ArthurPSmith (talk) 16:13, 18 August 2017 (UTC)
We have our own reasons for what we do but our approach has been a disaster. We decided not to cooperate and we shut the door on any cooperation. We knew at the time that the data would be used for the generation of articles and now we suffer the consequences. We will not import those articles they said .. the silly buggers. So now we have we have the worst situation possible. We do not collaborate with GeoNames, they know that some of their data is not that great and are interested to work with us and at the same time all their shit is in several Wikipedias and we do not know how to fix it.
Your notion that they need to be proven that something is right or wrong, they have common sense and accept when an argument is well presented. What we lack is trust and we do not deserve it at this time. The question is: how do we mark Wikipedia articles imported from GeoNames as problematic, how do we link them to GeoNames and how do we point to correct information. This is how we solve trust, indicate mayhem and build for improvements. Thanks, GerardM (talk) 07:15, 19 August 2017 (UTC)
The main problem here is not that we have duplicates of human settlements and municipalities. Because those two things are two very different concepts. It is the mixing of these two concepts on Wikipedia that confuses it for us. The "municipality of X" is often much larger than "settlement of X". They do not have the same area, they do not have the same population and they do not have the same history. No Swedish municipality is older than 46 years, but we have settlements that are over 10,000 years old. It is semantically a nightmare to mix these two concepts. In the text of an article at Wikipedia, you do not have that problem.
The real problem with the Lsjbot/GeoNames-items about settlements in these cases, is not that they are duplicates. It is that we do not know if the settlements exists at all. They came into the GeoNames database by finding a name on the map. GeoNames or Lsjbot have never secured that these names really belongs to a settlement. -- Innocent bystander (talk) 08:14, 20 August 2017 (UTC)
The real problem is that we failed to collaborate. Thanks, GerardM (talk) 09:14, 20 August 2017 (UTC)
And that can be derived from that Wikidata initially was introduced to Wikipedia as a repository for Interwiki. We never should have involved interwiki into this project! -- Innocent bystander (talk) 09:43, 20 August 2017 (UTC)
The relevance of Wikidata is based in cooperation. Thanks to the interwiki links Wikidata was relevant from day one. Thanks, GerardM (talk) 09:56, 20 August 2017 (UTC)
  • Innocent bystander: adding the P31-value suggested above would identify these as well.
    --- Jura 08:38, 21 August 2017 (UTC)

Restrict merging rights to autoconfirmed users[edit]

Hi, here at Wikimania several contributors were talking about merging issues. Merging is a process that requires some knowledge of how Wikidata works, and as the help page states in bold, users must be absolutely certain that the two items are the same. This results in merging errors, most of them by newcomers. As it can be tricky to revert, especially if one or both the merged items was massively used as a value in statements in other items, I think it would be better to restrict merging rights to autoconfirmed users. What do you think of it? @Lea Lacroix (WMDE): would a vote on this page be enough to activate this restriction or is a full RfC needed? -Ash Crow (talk) 23:08, 10 August 2017 (UTC)

Maybe at some point we don't need to make as many merges. So it would make sense that merge would be less necessary. But this is also depends on how often things outside Wikidata change.
On other hard, merge is hidden already... Maybe we should hide it even more to avoid confusion for newcomers. GA candidate.svg Weak support
We have a bot to replace indirect items with direct links, but not an unmerge bot right now. d1g (talk) 23:56, 10 August 2017 (UTC)

Pictogram voting comment.svg Comment The gadget could be set up so that only autoconfirmed users can use it. Getting autoconfirmed is a low bar, so gives us about a week, and a low number of edits, so seems reasonable approach.  — billinghurst sDrewth 02:45, 11 August 2017 (UTC)

Symbol support vote.svg Support Looks fair enough to me. Pamputt (talk) 11:56, 11 August 2017 (UTC)
Symbol support vote.svg Support I simply agree. I have similar proposal in past (Wikidata:Project_chat/Archive/2016/05#Mergers_limitation) and nothing substantial changed since then.--Jklamo (talk) 12:32, 11 August 2017 (UTC)
Symbol support vote.svg Support I also support this restriction. ArthurPSmith (talk) 12:44, 11 August 2017 (UTC)
Symbol support vote.svg Support -- Maxlath (talk) 12:54, 11 August 2017 (UTC)
Symbol oppose vote.svg Oppose it might be good to restrict, but there is no demonstration of what does it help. What is the rate of false VS correct mergers by autoconfirmed users, vs the same rate by not autoconfirmed users? The simply answer of those inside the club, seems to be restrict, restrict, restrict. But are those that are inside the club, the editors that commit significantly less errors? Does the rate change after one becomes and autoconfirmed user? Are there other options on reducing wrong mergers? How many wrong mergers are there ? Is there any policy on when something should be restricted? 13:00, 11 August 2017 (UTC)
I can understand that statistics would be useful, though I would like to reflect upon the proposal in a different way. We know that editing WD requires some knowledge of WD and the wikis and it is particularly the case with merges. Having a bad merge is highly problematic where it goes unnoticed, so emphasising the complexity and a slightly raised level of competence is not a bad thing.  — billinghurst sDrewth 13:21, 11 August 2017 (UTC)
  • Symbol support vote.svg Support, users should have some basic understanding of Wikidata before doing such actions. Stryn (talk) 17:45, 11 August 2017 (UTC)
    • Stryn - how is that ensured by allowing autoconfirmed users still to do it and blocking only not autoconfirmed users? Does the proposal achieve what you wish for? And why should "some basic understanding of Wikidata" be of any help to prevent wrong merges? 17:47, 11 August 2017 (UTC)
      • Of course it does. I think a user with 50 edits knows more about Wikidata than a user who makes their first edit here and it's merging. And anyone can make mistakes, it's not always about the edit count, but I believe newbies (non-autoconfirmed here) can make more mistakes. Stryn (talk) 17:52, 11 August 2017 (UTC)
  • Symbol support vote.svg Support Seem resonable. --Fralambert (talk) 17:58, 11 August 2017 (UTC)
  • Symbol support vote.svg Support Strakhov (talk) 03:59, 12 August 2017 (UTC)
  • I Symbol support vote.svg Support binding this right to the (auto)confirmed group, as well as item-redirect right. We should have a dedicated page where newbies can report possible merges. Update to Help:Merge and MediaWiki:Wikibase-error-sitelink-already-used is also essential. Note that users who will loose the rights won't be able to enable and use Merge.js. Matěj Suchánek (talk) 08:16, 12 August 2017 (UTC)
  • Symbol support vote.svg Support I would additional like the function to be included in the default Wikidata package, without a user having to go to the gadget page to enable the feature. ChristianKl (talk) 19:45, 12 August 2017 (UTC)
  • Pictogram voting comment.svg Comment The merge tool shouldn't be as hidden as it is - I recently had to explain to an experienced Wikimedian (but a relatively new Wikidataian) how to find it! Thanks. Mike Peel (talk) 00:15, 13 August 2017 (UTC)
    we are not talking about hiding or unhiding the tool, just restricting its usage for users' the very initial set of days of their account creation. It would still sit as a gadget. If you believe that the tool is hidden, what is your expectation of where it could be better seen? It already shows as the top gadget, and it shows on Help:Merge.  — billinghurst sDrewth 09:25, 13 August 2017 (UTC)
    I was replying to @D1gggg's comment above saying "On other hard, merge is hidden already... Maybe we should hide it even more to avoid confusion for newcomers." Personally, I think the gadget should be turned on by default. Thanks. Mike Peel (talk) 23:11, 13 August 2017 (UTC)
  • I personally don't support this, but if this is needed, please firstly restrict it to registered users.--GZWDer (talk) 12:27, 13 August 2017 (UTC)
    Isn't that a given? Anonymous users are unable to run scripts as best as I know it; they don't have gadgets — billinghurst sDrewth 14:53, 13 August 2017 (UTC)
    Addendum: Symbol oppose vote.svg Oppose unless a message that introduce them to the dedicated page for merge requests is shown when a merge by adding sitelink using client add link widget is blocked.--GZWDer (talk) 09:26, 14 August 2017 (UTC)
  • I just saw this anonymous user moving svwiki sitelinks from some items to another, while they should merge them (if not all - most of them; I didn't checked all items), and I have a feeling that they will ignore any invitation to register and use a gadget/tool to perform merges. --XXN, 01:04, 14 August 2017 (UTC)
Not many edits BTH, If it were hundreds or thousands, then gadget would save time. d1g (talk) 02:17, 14 August 2017 (UTC)
Symbol support vote.svg Support this can be (de-facto only?) one of exception of Wikipedia:IPs are human too (Q13164301), @GZWDer: I'd love to say that anyone who're hating log in, or are not possible to login citation needed (Q3544030) should request for IPBE rather than using puppet IPs. --Liuxinyu970226 (talk) 15:36, 14 August 2017 (UTC)
Symbol support vote.svg Support Sensitive issue with the potential of damage with a lot of cleanup. --Hedwig in Washington (talk) 03:03, 15 August 2017 (UTC)
Pictogram voting comment.svg Comment I haven't looked into other people's mergers recently, but are problems really due to not-autoconfirmed users merging?
--- Jura 10:09, 17 August 2017 (UTC)


I created two lists based on unique identifier (Q6545185)

and edited several items that had a claim instanceOf, but the items are instances of ID systems, not instances of IDs. There are some items about IDs (instanceOf UID). Also several National Identity Card claimed to be instanceOf UID, but should be classes and should not have regex format attached because they are ID cards not strings. Whether individual strings, e.g. AFG (Q12626453) are instanceOf UID is out of my interest, my main concern was, that items like ISBN are subclassOf UID and not instanceOf UID.

A further observation, there are several lists for properties

Would it be possible that a bot creates main namespace items for each "external-id"-property? That would grow Wikidata:List of classes of identifiers.

Last but not least, there is a bug with Listeria, if one wants to list Wikidata property (P1687) then the Q-item with the same number as the P-item is shown, e.g. for Alberta Register of Historic Places identifier (Q19832913) it shows as Wikidata property (P1687) New Hampshire (Q759) instead of Alberta Register of Historic Places ID (P759). 03:44, 11 August 2017 (UTC)

  • So what's the point to create these lists of identifiers? What's the point to create ID items?
  • We need to talk about Wikidata:Identifier. I see a need for a page with that title, but in its current condition it should better be deleted.
  • Listeria is a tool by User:Magnus Manske. There is a public repository where you can file bug reports if you think something is broken. Magnus is busy, however, so sometimes it takes a while until he shows a reaction.
MisterSynergy (talk) 05:11, 11 August 2017 (UTC)
MisterSynergy "So what's the point to create these lists of identifiers?" - There is no "the point", but there are purposes of the lists,
  1. sort out the current mis-classifications of identifiers in Wikidata (e.g. subclassOf vs instanceOf)
  2. track inconsistent property usage, e.g. country (P17) vs applies to territorial jurisdiction (P1001), issued by (P2378) vs operator (P137)
  3. demonstrate what information is already stored in Wikidata main namespace - or how much is missing, when comparing with the 1945 properties "external-id"
"What's the point to create ID items?" - There is no "the point", but there are several purposes,
  1. connect Wikipedia articles, like at International Standard Name Identifier (Q423048)
  2. to correctly link from a property (e.g. ISNI (P213)) using subject item of this property (P1629) to the main name space - if there is no ID item, one cannot link correctly, and currently P213 stores a lot of false claims
  3. to make the data that Wikidata already stores in properties available for SPARQL retrieval via the item namespace
"We need to talk about Wikidata:Identifier" - that page has a talk page, use it! "I see a need for a page with that title" - Good, it is there, why not say "Thanks" to the creator? "but in its current condition it should better be deleted." - Explain why, especially using WD policies and considering that you just said "I see a need for a page with that title" - Why delete instead of ammend? What do you have mind to be there? 12:44, 11 August 2017 (UTC)
Frankly, I do not understand what you are doing or planning to do, and this is reflected by your contributions, your comments on this page, and by your new pages in Wikidata namespace as well. My best assumption is that you are a pretty inexperienced user who is not used to the habits here and not aware of the consequences of their own activity. Your apparent reluctance to create and use an account does not permit you to develop any track record. I’d like to ask you to slow down a lot, and discuss your plans before you change anything on a large scale on property or item pages. Beginners seldom manage to work with an acceptably low error rate if they immediately try to be a major player.
The identifier page does not contain anything that appears useful, thus a deletion would probably be the best for a fresh start by experts. Regards, MisterSynergy (talk) 13:32, 11 August 2017 (UTC)
  1. "Frankly, I do not understand what you are doing" - That is your limitation! Try to fix!
  2. "Beginners" - I am not a beginner, I work with identifiers for more than a decade and as demonstrated have some knowledge about P31/P279 that registered user ArthurPSmith does not have
  3. "seldom manage to work with an acceptably low error rate" - show the errors, the error rate and say what is "acceptably low" to you
  4. "if they immediately try to be a major player." - I don't try to be a major player - maybe I am, but I don't try to. 14:02, 11 August 2017 (UTC)

IP user modifying unique identifier (Q6545185) related items[edit]

This IP user seems to have made a large number of changes to P31/P279 statements regarding our unique identifiers, including some modifications of properties. I don't believe they make sense, and don't understand why an unidentified (new?) user of this sort thinks they can override decisions on our subclass hierarchy made by many previous users here. I believe all their changes should be reverted as they don't make sense to me. unique identifier (Q6545185) has all along been a class whose instances are specific identifier systems, NOT the actual id's of objects within those systems - this can easily be seen from the "Examples" listing in the enwiki sitelink for Q6545185. Those "examples" are instances, not subclasses, of "unique identifier", and I think that's been clear from the way those relationships have generally been applied within wikidata. ArthurPSmith (talk) 13:06, 11 August 2017 (UTC)

ArthurPSmith - "I don't believe they make sense" - then show, using reasoning, and not using attack on the user.
Semantics are broken and you should probably be blocked from editing P31/P279 until you can demonstrate your knowledge improved. BTW: "This IP user seems to have made a large number of changes to P31/P279 statements regarding our unique identifiers" - Do you really play OWN here? Do you regard the identifiers to belong to you and your friends? Why do you have ID lists in user space: User:ArthurPSmith/Identifiers. Why not in a project? You want to assert some kind of control? 13:22, 11 August 2017 (UTC)
did you just edit my comment and your response here? Here's what I wrote to respond to you before your edit interfered: You are confused about the meaning of unique identifier (Q6545185). Given where wikidata is, there was naturally some confusion here as well (the country codes case is a good example). Nevertheless, thinking that something that is an instance of "unique identifier" is the actual code for identifying a specific entity is completely wrongheaded. What could "uniqueness" possibly mean if we are talking about a single entity? It is inherently nonsensical. If you look at en:Unique identifier (and its reference en:Identifier you will see that all the examples listed (*instances*) are things like ISBN, ISSN, ISNI, ORCID, etc, which are systems for uniquely identifying entities with specific codes. ISO 3166-1 alpha-2 code (Q1140221) should have been instance of (P31) country code (Q906278), not a subclass. As to my expertise on the issue of class relationships, perhaps some others here could note the work I've done on this in the past. Just as a sample, I did some considerable editing of Help:BMP and wrote a number of the pages under Wikidata:WikiProject Ontology. Whereas, given your continued instance on using an IP address, it's not clear what background you have at all. ArthurPSmith (talk) 17:21, 11 August 2017 (UTC)
as to what was going on at User:ArthurPSmith/Identifiers - this was at an early point in the external-id conversion project, to decide which string properties qualified as legitimate unique identifiers that would be useful as external id's. See Wikidata:Identifier migration for the actual main work on this, and thanks to Lydia and the developers for making the migrations happen. My page was just intended as a temporary reference point on what was going on with various identifiers. There are lots of similar user pages with occasionally gathered stats of this sort. I'm leaving this one up just for historical purposes. At least it does demonstrate that I've been involved with identifiers on wikidata for some time now. ArthurPSmith (talk) 17:34, 11 August 2017 (UTC)
ArthurPSmith If I changed any of your edits, then it must have been in an edit conflict, without a notice for such a conflict seen here. Please stop your personal attacks "You are confused about the meaning of unique identifier (Q6545185)" - I can claim the same about you. That does not lead us anywhere. Can you please say how you would like the claims to be, including for individual code elements like 10048 (Q4546087), cre (Q12656548), AFG (Q12626453). Is "AFG" a UID? If not, what is it? I didn't change all IDs that are now subclassOf UID, there were already some, which was the reason I started working on it. SPARQL failed to show all when using P31 and failed when using P279. It should be consistent.
"If you look at en:Unique identifier (and its reference en:Identifier you will see that all the examples listed (*instances*) are things like ISBN, ISSN, ISNI, ORCID, etc, which are systems for uniquely identifying entities with specific codes." - Exactly, they are systems, maybe instances of systems. But they are classes of UIDs. en:Identifier does not claim they are instances. 17:39, 11 August 2017 (UTC)
AFG (Q12626453) is an instance of international vehicle registration code (Q154015) that in turn should be an instance of country code, which is a subclass of unique identifier (Q6545185). Class relationships can be hard to think about with respect to any abstract concept, but I think here it is relatively clear. The postal code case is interesting however - many things have the same postal code, and the code within a given country is not a "unique identifier" of anything without also specifying the country. I don't think it belongs under "unique identifier" at all, that is, all that a zip code (for example) identifies is the area identified by the zip code, which is somewhat tautological - and which may also change over time. So I think 10048 (Q4546087) can be instance of (P31) ZIP code (Q136208), sure, but what relationships ZIP code (Q136208) should have otherwise are not clear to me - in the end it should be an instance of identifier, but not necessarily of unique identifier (Q6545185). ArthurPSmith (talk) 17:53, 11 August 2017 (UTC)
ArthurPSmith, thanks for your reply. (US) ZIP code is a UID to identify a (US) ZIP code area (geographic region, but the extension can change). An ISO country code identifies a country (legal entity) which claims to have certain rights over a geographic region. There are different kinds of postal IDs in some countries, e.g. 01 identifies a Postleitregion, (, no idea if there is a name for the area where codes start with "0". There is always the thing that is identified and the identifier. There are IDs for physical objects (humans, cars, ...) and IDs for non-physical objects. "GB", "DE", "FR" are identifiers. Maybe they are instances or they are classes of ISO 3166-1 alpha-2 code (Q1140221). What you said "AFG (Q12626453) is an instance of international vehicle registration code (Q154015) that in turn should be an instance of country code" would mean that AFG (Q12626453) is not an instance of a country code, because that would only be inherited from international vehicle registration code (Q154015) if international vehicle registration code (Q154015) would be a subclass of country code. Then AFG (Q12626453) is not a UID. "GB", "DE", "FR" would not be UIDs. So there are these things:
  1. UID
  2. specific UID systems (e.g. ISO 3166-1 alpha-2 code, ISO 639-3 language code)
  3. the codes of a system (DE, FR, GB; deu, eng, fra) : 1) subclass or instance of UID ("FR is a UID for the country named 'France'"), 2) subclass or instance of ISO 3166-1 alpha-2 code ("FR is a UID for the country named 'France'"), 3) "DE, FR, GB are UIDs, country codes, 2-letter country codes, ISO 3166-1 alpha-2 country codes"
  4. some classes with no specific UIDs, e.g. "country code", or "article identifier", or "language identifier"
On a page about "FR" it should be sufficient to state the relation to "ISO 3166-1 alpha-2 country code" and then to inherit all the rest that is attached via subclassOf, so that "FR" would be a UID, ID, 2-letter string. If one adds "UID system", e.g. "ISO 3166-1 alpha-2 code is an instance of a UID system", then much is solved. "country code" and "2-letter country code" would not be an "instance of a UID system" but just some classes to group the systems. I would even go one step further and say that "FR" just is a class, and when I write it down on a paper then it is instance of the country code 'FR'. To have items about instances of UIDs (like on my paper), should be rare in Wikidata. 19:40, 11 August 2017 (UTC)

County letter (Q10571932)[edit]

User:Innocent bystander claimed [1] that County letter (Q10571932) is an instance of country code (Q906278). The description says "alphabetic or numeric geographical codes that represent countries and dependent areas". But County letter (Q10571932) has nothing to do with identifying a country or dependent area. But it is only meant to identify members of a set of country subdivisions, namely county of Sweden (Q200547).

And if it is an instanceOf UID, then what are "AB", "C", "D"? InstanceOf an instanceOf UID? Semantics broken. 18:04, 11 August 2017 (UTC)

First user that made that claim was User:JakobVoss (Jakob Voß (Q15303972) - all the education, the degrees and the work at VGZ didn't prevent that claim from being made by him). But why did User:Innocent bystander re-insert the claim? 18:33, 11 August 2017 (UTC)

It depends on how you define "dependent areas". If a "subdivision of Sweden" is such "dependent area", the claim is right. Otherwise County letter (Q10571932) and country code (Q906278) only share a common superclass. -- JakobVoss (talk) 19:44, 11 August 2017 (UTC)
JakobVoss, wouldn't Wikidata follow what reliable sources define a "dependent area" to be, en lieu of me doing so? For a start: en:Dependent territory. If one just goes by the words "dependent" and "area" then any area may qualify because any depends on something. And "country code" would be called "area code". But there is a reason why "country" is inside the term. Re "Otherwise County letter (Q10571932) and country code (Q906278) only share a common superclass" - that is not correct. First, all things share a common superclass, here it is: entity (Q35120). Second, the two do not "only share a common superclass", but share several. 00:56, 12 August 2017 (UTC)
From Swedish article it says for car plates.
Not relevant to ATE or countries. d1g (talk) 01:17, 12 August 2017 (UTC)
d1g, there are different ways to define ATE, you may look at it in Soviet/Russian context. A Country could also be a ATE - it is an entity, it is defined for administration, and it has to do with territory, thus adminsitrative territorial entity. European Union, Russia, Central European Time Zone, Kaliningrad Region, Moscow City (the federal subject), could all be ATEs. Country is just one ATE class. For some ATE it is debated if they are countries, e.g. Kosovo, Transnistria, South Ossetia, Abkhazia, Nakhitshevan, Palestine. And then there are ATEs that are not countries, but sometimes seen as outside countries, that's what usually is meant by "dependent area" (American Samoa, Hong Kong, Macao, Gibraltar), the term that JakobVoss wanted to redefine. I see no reliable source for the edits by User:Innocent bystander and JakobVoss that define the counties of Sweden as "countries" or "dependent areas".
User:JakobVoss did not yet comment on 'And if it [Sweden county code] is an instanceOf UID, then what are "AB", "C", "D"?' 12:49, 12 August 2017 (UTC)
No problem, please assume good faith! I just created administrative territorial entity identifier (Q36205316) for special classes of unique identifier (Q6545185) with identify any kind of areas (countries, counties, etc.). -- JakobVoss (talk) 19:46, 12 August 2017 (UTC)

Postal code[edit]

ZIP code[edit]

    • How can 10048 (Q4546087) be P31 ZIP code (Q136208) and therefore P31 unique identifier (Q6545185)
    • P31 is not a transitive property, "and therefore" is wrong.
    • Q4546087 can have P279 with value of "sequence of characters" or similar. d1g (talk) 06:03, 12 August 2017 (UTC)
d1g ZIP code (Q136208) subclass of unique identifier (Q6545185) and therefore transitive and therefore the therefore was correct. 13:18, 12 August 2017 (UTC)
unique identifier has values, 10048 (Q4546087) has no values/instances and not identifier at all, but a ZIP code
Undo your changes to Q136208! d1g (talk) 13:29, 12 August 2017 (UTC)
d1g, of course ZIP codes have instances. Have you never seen Soviet/Russian postal codes printed on letters? 14:03, 12 August 2017 (UTC)
Apparently, we had such oversight for a long time. d1g (talk) 13:31, 12 August 2017 (UTC)

@Mbch331: US ZIP codes are now human readable data and no longer strings, or UIDs, thanks to D1gggg's edit. 14:12, 12 August 2017 (UTC)


Eircode (Q6070781) now human readable data and no longer string, or UID, thanks to User:D1gggg's [2] 14:19, 12 August 2017 (UTC)

Youtube channel ID[edit]

@ArthurPSmith: some thoughts on YouTube channel ID (Q35907496):
Instances of Q35907496 are unlikely to be modeled as separate items.
It must be P31 "identifier" (YouTube has only one version of channel identifiers)
It could be P279 "sequence of letters"
Changes by @ don't capture this. d1g (talk) 01:44, 12 August 2017 (UTC)
Each single channel id should be instance of (P31)  YouTube channel ID (Q35907496), even though we will never have an item about a specific channel id (we might have an item about a channel, but not about the id). So YouTube channel ID (Q35907496)subclass of (P279)  identifier. And subclass of (P279)  sequence of letters is totally wrong as it's not just letters, also numbers and some special characters. Mbch331 (talk) 06:03, 12 August 2017 (UTC)
Individual identifiers aren't modeled using items.
Why one need to create item "UCcOkA2Xmk1valTOWSyKyp4g"? What it should state?..
is totally wrong as it's not just letters, also numbers and some special characters
I wasn't in mood to type every trivial detail. d1g (talk) 06:27, 12 August 2017 (UTC)
Of course there won't be an item for an individual channel id, but that still doesn't make that YouTube channel ID (Q35907496)instance of (P31)  identifier true. It's about concepts. Not because something is the lowest level possible on Wikidata, it automatically requires a P31 statement. Sometimes the lowest level only needs a P279 statement. Mbch331 (talk) 12:11, 12 August 2017 (UTC)
I don't understand your comments: "Of course there won't be an item for an individual channel id" is opposite "Each single channel id should be instance of (P31)  YouTube channel ID (Q35907496)"
Your statements seem nothing to do with what i said as for now... d1g (talk) 12:32, 12 August 2017 (UTC)
d1g, why is that opposite? Only because there are no items about YT channel IDs does not mean the YT channel IDs are not IDs. 13:16, 12 August 2017 (UTC)
P31 youtubechannelID
Who need to make such statements? d1g (talk) 13:23, 12 August 2017 (UTC)
d1g, "Who need to make such statements?" - what do you mean? 14:01, 12 August 2017 (UTC)

List of issues with identifiers[edit]

Wikidata:List of classes of unique identifiers[edit]

{ {Wikidata list
|sparql=SELECT ?item WHERE {  ?item wdt:P279* wd:Q6545185 } 
} }

returns 251 items. Included are several specific code elements from ISO 639-3, e.g. "aze". How can IDs be separated from ID systems? Should the systems get an additional P31? 14:40, 11 August 2017 (UTC)

Voting on removal of inconsistencies related to identifiers[edit]

Shall the inconsistencies in the usage of subclass of (P279) VS instance of (P31), country (P17) VS applies to territorial jurisdiction (P1001), issued by (P2378) VS operator (P137), and format as a regular expression (P1793) be removed?

ISO 639-1 code (P218) ISO 639-3 code (P220) should be used at Arabic (Q13955)
I don't know if we should do anything about items like ISO 639-3 kodai/ara (Q12656547) d1g (talk) 02:28, 12 August 2017 (UTC)
d1g 1) the items exist because there are connected pages in Wikipedia. 2) languoids are not physical objects, they are defined by different people at different ppoints in time differently. How many things in a language have to be change to constitute a new language? ISO came around and defined some languoids, 'ara' is macrolanguage consisting of several individual languages. Other languoid ID systems may not have something like 'ara'. Wikidata should only state what is stated in reliable sources. Maybe the item for 'ara' could be redefined as "the languoid identified by ISO 639 'ara'". So, the 'ara'-item would not be instanceOf/subclassOf UID, but subclassOf ISO 639 defined languoid. d1g, User:ArthurPSmith, what do you think? 13:06, 12 August 2017 (UTC)
Symbol oppose vote oversat.svg Strong oppose insane suggestions to create items for "tt0120338" "tt0088846" and use P31/P279 below. d1g (talk) 15:20, 13 August 2017 (UTC)
d1g where was it suggested to create items for "tt0120338" "tt0088846"? The item identified by tt0120338 exists: "Titanic (Q44578)", so does exists for "tt0088846" the item Brazil (Q25057). 16:49, 13 August 2017 (UTC)

human-readable data (Q28777989) OR machine-readable data (Q6723621) on UID items[edit]

@Innocent bystander, GerardM, Mbch331, JakobVoss, ArthurPSmith: User:D1gggg now inserts randomly(?) subclassOf human-readable data (Q28777989) OR subclassOf machine-readable data (Q6723621) on UID items [3]. Maybe the statements are correct, but wouldn't it make more sense to classify all the UIDs with something more specific like unique identifier (Q6545185) or a subclass of the latter? human-readable data OR machine-readable data is very unspecific. 14:40, 12 August 2017 (UTC)

@Ogoorcs: User:D1gggg turned your specific classification as "Internet Movie Database title ID" subclassOf "UID" into only "Internet Movie Database title ID" subclassOf "string" [4] . Yes, a IMDB title ID is a string, but a specific type of string, namely a UID. Waht do you think? 15:16, 12 August 2017 (UTC)

Internet Movie Database title ID (Q28777282) is rather an instance of unique identifier (Q6545185) (or some of its subclasses). Individual parts of Internet Movie Database title ID (Q28777282) are strings but the whole is an identifier system. In most cases it makes no sense to make statements about individual identifiers, at least before lexical label items are supported in Wikidata. -- JakobVoss (talk) 07:52, 13 August 2017 (UTC)
Pictogram voting comment.svg Comment we shouldn't put too much effort to explain "unique identifier" is a system of values.
They were given explanation multiple times above, but they continue to drag everyone in community rather than accounting what what was suggested. d1g (talk) 08:10, 13 August 2017 (UTC)
JakobVoss - "Internet Movie Database title ID (Q28777282) is rather an instance of unique identifier (Q6545185)" - how that? "tt0120338" and "tt0088846" are Internet Movie Database title ID (Q28777282), there are many of these, that belong to the class IMDB id, subclass of creative work ID, subclass of ID. "DE" is a UID for a country, namely a country code. "FR", "GB" too. What is the class they belong to? ISO 3166-1 alpha-2 code, subclass of country code, subclass of UID. 13:54, 13 August 2017 (UTC)
@ I think it is correct to say that ImDB title IDs are instances of "UID"s and of course of strings. I don't see conflicts in these statements. To me, best choice is "subclass of" "UID" -> qualifier: "consists of" "string".--Ogoorcs (talk) 23:45, 13 August 2017 (UTC)
@Ogoorcs: anyone with 1 day of experience with databases wouldn't define unique identifiers as strings: "a specific type of string, namely a UID" - such statement show all profanity
unique identifiers aren't about strings but
  1. about uniqueness of values
  2. about identification system associated with values (ara is meaningless without coding system)
d1g (talk) 02:31, 14 August 2017 (UTC)
@D1gggg: Follow me here. Instances of IMDb Title ID (i.e. an IMDb Title ID as 'tt0088846', since this string is a member of IMDb Title ID class) are instances of strings ('tt0088846' is an alphanumeric string) and of course they are instances of UIDs (because 'tt0088846' identify one and only one movie), so correct statements for IMDb Title IDs are subclass of: string and subclass of: UID as per "subclass of" property definition. Beware, I'm not saying we should give 'tt0088846' an entry on its own! All I've written was supposed to push those statements, no others. --Ogoorcs (talk) 12:54, 22 August 2017 (UTC)
Any individual identifier such as "ara" is meaningless without a coding system. Who wrote this and what does it mean?
Individual identifiers such as country code "DE" or IMDb "tt0120338" should not be stored as Wikidata items but used as values with the corresponding Wikidata properties. Exceptions should be treated as exceptions, instead of argument to make them the norm. -- JakobVoss (talk) 09:17, 14 August 2017 (UTC)
@D1gggg: I have not said that UIDs are strings, but that IMDb title IDs are and it is good to specify it because many things can be UIDs at this world. Please, read better, stay calm and don't take for granted others' knowledge. --Ogoorcs (talk) 14:35, 19 August 2017 (UTC)
@User:Ogoorcs: you said "I think it is correct to say that ImDB title IDs are instances of "UID"s and of course of strings. I don't see conflicts in these statements".
Conflict is quite oblivious.
tt0088846 is not a unique identifier them-self, but a value of unique identifier (IMDB).
Values of UID could be (and often are) random.
The only application of tt0088846-as-instances-of-IMDB is OCR and even for this one could select all values of IMDb ID (P345). d1g (talk) 14:51, 19 August 2017 (UTC)
@D1gggg: I'm sorry, this uselessly overly complicated and messy way of exchanging messages has again proven horrible and difficult to follow. It appears I've written under the wrong message, since it seems to me that you think I'm arguing to what JakobVoss said. I think it is better to continue our discussion above. --Ogoorcs (talk) 12:54, 22 August 2017 (UTC)

Identifier classification tree[edit] 22:29, 12 August 2017 (UTC)

P155 and P156 qualifier constraint[edit]

Hello. Does the community agree with that changes? [5], [6] (@Lockal:)

Are we allowed to use those properties as statements and not as qualifiers (I know there are the exceptions of rare cases)? Now we mostly used them not as qualifiers.

Previous discussions:

I don't have an opinion or a suggestion. I just want to use them correctly.

Xaris333 (talk) 11:55, 11 August 2017 (UTC)

I guess nobody interest for this subject either... Although there are discussions that decided to use them as a qualifier, a user remove the constraint only by his own opinion, thousands of users add them as statements and nobody cares about that. So thats wikidata. Since in most items the properties are as statements, we just continue with that... We have a big problem with wikidata in general. And since the wiki is growing, the mess and the problems are growing too. Αnarchy... Well, nothing is going to change, so I will just continue add them as I believe. No one take enough serious the decisions that are taking in wikidata, so everyone is doing what ever he wants... Xaris333 (talk) 18:10, 11 August 2017 (UTC)

sorry, I was going to say something (I wasn't even aware of the qualifier constraint, and I've used these properties before) but I wasn't sure what to add. I don't think there's reason to despair here, or even be discouraged - sometimes a single property can be useful in different contexts and I think this is a case of that. Probably we should focus on relatively narrow areas and do what makes sense to us, and then try to reach consensus where the areas overlap, more than trying to enforce something top-down? ArthurPSmith (talk) 18:17, 11 August 2017 (UTC)
There were discussions and decisions about using them as qualifiers. What's the point if anyone can change those decisions without asking the community? What's the point if we don't have the willing to correct things? I know that every decision can change, but through a discussion. Now, I am just seeing a property that the community decided to use it a as a qualifier, most of the users use it as a statement, a user just removed the constraint and life go on... And I think that this apply to many other properties... Do we have rules? And if we have, does anyone follows the rules? Xaris333 (talk) 18:30, 11 August 2017 (UTC)
well we may see quite a bit of this sort of thing going forward now that constraints actually have a UI effect (before the last month or so, any constraint violations were hidden on report pages). Most constraints make sense. But a constraint that has been widely violated probably doesn't. However, perhaps we should try to get people to discuss on the property talk page before removing a constraint like this at least... ArthurPSmith (talk) 18:49, 11 August 2017 (UTC)
Another discussion: Topic:Tv00hex7b7bwpd4t. TLDR: introducing this constraint generated 266060 violations without any algorithmic solution. --Lockal (talk) 19:30, 11 August 2017 (UTC)
Pictogram voting comment.svg Comment 2 first changes make sense, because
1. sometimes next/previous links are not ambiguous and
2. they refer to whole items, rather than individual statements
So usage as qualifiers isn't necessary d1g (talk) 00:27, 12 August 2017 (UTC)
How can that be? Previous and following are relative concepts that depend on a point or item of relevance. If something precedes or follows something there always needs to be a context, it cannot happen in isolation. Philip > Anne > Andrew > Edward ... children of QE2; Philip > Andrew > Edward ... male children of QE2. Album releases of a band, etc. Years 1996 follows 1995 (previous year) and 1992 (previous leap year). Book published might follow the author's previous work; the author's previous non-fiction work; the publisher's previous work; the illustrator's previous work; and so on. There has to be context, so I am interested in your examples where you see that P155/P156 do not have a context.  — billinghurst sDrewth 05:33, 12 August 2017 (UTC)
Anything. Models of cars. d1g (talk) 05:52, 12 August 2017 (UTC)
A model of car has context, it doesn't exist in isolation, the models are of a brand. Australian Holden Commodore is the brand, and it has multiple models since the 1980s. Holden has also built other cars and models. Also a certain model could be built in one country then they change place of manufacture, so if your were looking to track the models built in a country or at a plant, if you put an overarching P155/156, aren't you confusing that if you wish to track other components.  — billinghurst sDrewth 06:00, 12 August 2017 (UTC)
We don't need to use any qualifiers in most cases: Ford Model A (Q1167651) Ford Model A (Q515001) d1g (talk) 06:10, 12 August 2017 (UTC)
Looks like something that can be qualified, and doesn't run contrary to guidance.  — billinghurst sDrewth 15:11, 12 August 2017 (UTC)
@billinghurst: South Pole Telescope (Q1513315) follows (P155) Antarctic Submillimeter Telescope and Remote Observatory (Q4771004) - I'm not sure how that would be qualified? Thanks. Mike Peel (talk) 00:11, 13 August 2017 (UTC)
On what basis does it follow?  — billinghurst sDrewth 06:50, 13 August 2017 (UTC)
In the telescopes I think its make sense to use replaces (P1365) and replaced by (P1366). The one item replaced or replaced by the other. Is not a series. Xaris333 (talk) 06:59, 13 August 2017 (UTC)
Aah, replaced by makes more sense. I didn't know we had those properties, thanks! Mike Peel (talk) 22:48, 13 August 2017 (UTC)
Anything. TV seasons. d1g (talk) 06:56, 13 August 2017 (UTC)
Anything. Ceremonies and events. d1g (talk) 06:58, 13 August 2017 (UTC)

So, we are going to use them also as statements? Not all user agree to use them as qualifiers only. Xaris333 (talk) 09:23, 12 August 2017 (UTC)

I disagree quite strongly with the decision to remove the constraints without discussion. I think the constraints should be re-added, and only removed if a discussion on the property talk page results in consensus to remove. --Yair rand (talk) 20:57, 14 August 2017 (UTC)
I have re-added them 3 days ago. I agree with you. Xaris333 (talk) 21:43, 14 August 2017 (UTC)
In the event the qualifier constraint remains, we should determine which properties P155 and P156 should qualify. part of (P361) and series (P179) are the most obvious two that come to mind. (I don't want to bother Maarten by suggesting instance of (P31)). Mahir256 (talk) 05:56, 15 August 2017 (UTC)

anti-war activist is not an occupation[edit]

@GerardM: has added occupation (P106) anti-war activist (Q36193099) to a whole series of articles, claiming that Wikipedia says these individuals' occupation was "anti-war activist". Aside from the fact that "anti-war activist" is not an occupation, the text he claims is in the articles appears to only be a category, and appears nowhere within the text of the articles examined. Either the information must be removed as being incorrect, or it must be corrected in some way. Is there a way to correct the information? If so, does someone have a bot that could run through all instances using the correct property for this qualifier? Certainly occupation (P106) is wrong, but GerardM has refused to agree. --EncycloPetey (talk) 20:29, 13 August 2017 (UTC)

"'anti-war activist' is not an occupation" For some value of "occupation" (occupation (Q12737077) is defined, in English, as "any activity of a person (hobby, work, pastime...)")). I think it is very easy to occupy one's time with anti-war activism. Perhaps you meant "'anti-war activist' is not a paid job". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:41, 13 August 2017 (UTC)
Did you look at the various ways occupation (P106) is defined and explained in all languages, or just seize upon a single one in English? occupation (P106) is for paid employment. --EncycloPetey (talk) 20:59, 13 August 2017 (UTC)


Yes, but since this discussion is in English, that's what I quoted. Here you go:

  • ast = cualquier actividá d'una persona (pasatiempu, trabayu, deporte, etc.)
  • bg = всяка продължителна дейност на човек (хоби, свободно време, работа, професионален спорт и др.)
  • bn = একজন ব্যক্তির কোনো কার্যকলাপ (শখ, কাজ, আহ্লাদ, পেশাদারী খেলা...)
  • ca = qualsevol activitat d'una persona (afició, treball, passatemps, esport professional etc.)
  • da = persons aktivitet, f.eks. hobby, arbejde, sport, ...
  • de = jede dauerhafte Aktivität eines Menschen (Hobby, Freizeit, Beruf etc.)
  • es = cualquier actividad de una persona (hobby, trabajo, deporte profesional, etc.)
  • et = igasugune inimese tegevus, nt hobi, töö, meelelahutus jne.
  • eu = pertsona baten edozein jarduera (zaletasuna, lana, denbora-pasa, lanbidezko kirola...)
  • fr = toute occupation d'une personne: passe-temps, travail, sport professionnel...

and that's just the first screen in the Labelister gadget, other than English. I also note from the item's early history that an attempt to merge it with job (Q192581) was reverted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:31, 14 August 2017 (UTC)

+1. "Occupation" =/= "paid work" by our definition. - PKM (talk) 20:46, 13 August 2017 (UTC)
  • Pictogram voting comment.svg Comment In English the generally acknowledged modern interpretation of "occupation" is for paid employment, or at least solid part of a career. It is would be useful to be able to have better granularity. We have many British clergyman, and gentry and peers of various realms who did the highest quality amateur research outside of their financial income. Similarly, daughters and wives of politicians, peers, etc. who did much social work funded by family or inheritance. Do we wish to differentiate between how users supported themselves in the world, compared to their claim to renown.  — billinghurst sDrewth 00:15, 14 August 2017 (UTC)
I recently did edits to modern payed workers, all modern professions should be sub classes of employee (Q703534).
E.g. barber surgeon (Q781850) is not linked to Q703534 d1g (talk) 02:00, 14 August 2017 (UTC)
@billinghurst: That would be a vocation (Q829183) or avocation (Q1267055), depending on how we choose to define them. I do not know whether we have a property tied to either of these. --EncycloPetey (talk) 02:10, 14 August 2017 (UTC)
We have approved by (P790) for example d1g (talk) 02:13, 14 August 2017 (UTC)
Employee as a superclass for modern occupations? Really so everybody who has such an occupation is not self employed.. REALLY? Thanks, GerardM (talk) 03:59, 14 August 2017 (UTC)
  1. I don't think we should stress about "real one-man company" or "contractor" nuances.
  2. Self-employed don't get money from the air.
  3. It must be legal form (P1454), not primitive instance of (P31) subclass of (P279) d1g (talk) 04:18, 14 August 2017 (UTC)
This we "should not" is exactly why the whole class system is a quagmire. It cannot be explained it is absolutely helpful and unhelpful at the same time. GerardM (talk) 04:24, 14 August 2017 (UTC)
4 classes should be enough to cover all profit-related activities, shadow economy and illegal activities if have interest to have them together.
service worker (Q33394442), farm worker (Q33394254), manual worker (Q33394058), white-collar worker (Q368758)
Maybe we should include Q781850, but then we should agree to state "end date"=unknown to a profession or similar. d1g (talk) 05:09, 14 August 2017 (UTC)
@GerardM: pay attention to d1g (talk) 05:20, 14 August 2017 (UTC)
and that tells me what? You did not make your point. Thanks, GerardM (talk) 06:56, 14 August 2017 (UTC)
@GerardM: we should use affiliation (P1416) (and P1454) to identify if they they are organization of member of organization and other ways
You said "so everybody who has such an occupation is not self employed" but we shouldn't make such conclusions based on P31/P279.
P31 should answer very fundamental questions, not what you raise d1g (talk) 08:05, 14 August 2017 (UTC)

We could use movement (P135) (though anti-war is more a political movement than philosophical; should we correct this property definition to explicitly allow political movements?). For example, I added it to Heather Heyer (Q36338039) with value anti-racism (Q582965). Anyway, if one person has been an anti-war activist, I think we should add "activist"/"political activist" as occupation. Emijrp (talk) 08:47, 14 August 2017 (UTC)

There are plenty of occupations that are no occupation at all. Poet for instance.. There are plenty of sportspeople who are known for their sport but do not make any money out of it. Affiliation is another non starter imho because poets have no affiliation either. Occupation is used as an indicator for the activities someone is known for, what occupies their attention not really their profession. Thanks, GerardM (talk) 09:14, 14 August 2017 (UTC)
Fully agree with GerardM, and that was my point with reference to renown. How we mention and remember people is not necessarily their occupation, eg. Octavia Hill (Q437462) or John Monash (Q2731333) or Francis Ledwidge (Q1387970). How do we intend to capture that?  — billinghurst sDrewth 12:38, 14 August 2017 (UTC)
I say again, that what we may need is a property for avocation (Q1267055), which is a "calling" that is not usually a paid position, such as missionary, sportsperson, artist, activist, etc. It is true that Olympic athletes and state poets are not usually given a salary for their position, but the position is still supported financially by the state. In a sense, they are paid, just not salaried. --EncycloPetey (talk) 13:17, 14 August 2017 (UTC)
@GerardM, billinghurst: The problem with your approach is that as for now occupation (P106) is not defined as an activity someone is known for, but as any activity of the person, which is far to broad and can include waking up in the morning, brushing one's teeth, putting on shoes, using swear-words or paying income-taxes. The only restriction as for now is that there has to be a corresponding item for the activity (which can necessarily be created) and that the statement should provide the source of the information (which meanwhile nobody takes seriously). Such a broad definition renders the data virtually useless. The fact that Wikidata editors (mostly) act reasonable and don't add statements in the whole range allowed by the definition doesn't solve the problem, just covers it temporarily, so that it surfaces later after growing to an unmanageable amount. And meanwhile brings other problems like one editor restricting himself arbitrarily on "activities one is known for", other one on "activities one makes his living with", and yet another one on "long-term or regularly repeated activities", "activities of one's own accord" a.s.o., who will engage in endless and hopeless discussions, whether a particular activity should be included or not.--Shlomo (talk) 09:28, 15 August 2017 (UTC)

We also have the problem that "Anti-war activist" implies the person was against all war of any kind, which is not always the case. Some anti-war activists oppose a particular war or cause, but support other wars or causes. Aristophanes, for example very vocally opposed the Peloponessian War in his plays, while praising the wars that had been fought against Persia. He only opposed war with neighbor Sparta, not war against foreign invaders. So @GerardM: how would we indicate that? --EncycloPetey (talk) 13:17, 14 August 2017 (UTC)

I do not indicate that, current category structures do indicate that. Thanks, GerardM (talk) 13:38, 14 August 2017 (UTC)
@EncycloPetey: This has nothing to do with the discussed problem of occupation (P106), this is just lack o sufficiently particularised definition of anti-war activist (Q36193099). As for now I can't see any statement, label, description or even discussion that implies, that this item should be used for "anti-any-war activist" only and not for "anti-some-particular-war(s) activist". As soon as this is clarified (which should be done on item's talk page), we can look for a solution for Aristophanes or other ones (using qualifiers, splitting items, whatever). But we'll still be facing the question, whether "anti/pro-anything-activism" is considered occupation as understood in occupation (P106), or we should better use political ideology (P1142), political alignment (P1387) or anything else.--Shlomo (talk) 07:15, 15 August 2017 (UTC)

Limit edits to English language label of properties to logged-in users?[edit]

Looking at edits by anons of the last 30 days, it seems that most edits are either vandalism, vandalism reversal or people mistaking the property label for the value to be entered. The few edits that could actually be considered appropriate didn't persist either.

I'd suggest that we try to set up an edit filter that blocks anonymous edits to English labels on properties.
--- Jura 10:48, 14 August 2017 (UTC)

We could at least try this 2 weeks or a month GA candidate.svg Weak support d1g (talk) 11:19, 14 August 2017 (UTC)
Symbol oppose vote.svg Oppose for a single language (support if applied generally). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 14 August 2017 (UTC)
Why is that?
--- Jura 13:30, 14 August 2017 (UTC)
@Pigsonthewing: I have not seen random IPs editing any language other than English by mistake, so I cannot see why we should protect other languages. New logged in users, yes, but not IPs. - -- Innocent bystander (talk) 05:25, 16 August 2017 (UTC)

Merge request[edit]

I am not too familiar with Wikidata and not at all with its tools, so I hesitate to possibly do harm by messing with the tools. But could someone possibly merge Category:Hamilton, New York (Q20088954) and Hamilton (Q3460721)? They appear to be identical. Thank you so much! --Stilfehler (talk) 11:52, 14 August 2017 (UTC)

We don't merge wikimedia categories with their corresponding topics, they are considered different.  — billinghurst sDrewth 12:06, 14 August 2017 (UTC)
Thank you, I wasn't aware that there was a difference. --Stilfehler (talk) 12:25, 14 August 2017 (UTC)
@Stilfehler: I have added a topic's main category (P910) to the latter item, using the former item as a value. This is how we link Wikimedia categories to their subjects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 14 August 2017 (UTC)
I created a page [7] and am failing to connect this page to [8]. It both would share a Wikidata ID, the link to Commons would appear automatically - this is my primary goal. --Stilfehler (talk) 13:00, 14 August 2017 (UTC)
Use Commons category (P373). Matěj Suchánek (talk) 15:32, 15 August 2017 (UTC)
P373 doesn't create interwiki links on Commons, it's better to use the 'Other sites' sitelink to Commons instead. Thanks. Mike Peel (talk) 17:48, 15 August 2017 (UTC)
But that won't work in this case Mike Peel as the link is used in the category, so need to use an active means to pull link to the CommonsCat using WikiBase.  — billinghurst sDrewth 06:01, 16 August 2017 (UTC)

Wikidata IDs in Openstreetmap[edit]

Openstreetmap has had a "Wikidata" key for years, but still most items use a wikipedia key rather than the Wikidata key. This is much less useful. A Wikidata key would be so much more useful.

I recall reading somewhere that mappers were reluctant to bot-fix this, because sometimes Wikipedia articles do not exactly match the linked Wikidata item. Unless I am missing something huge, this is essentially bullshit.

Can anyone with OSM connections push for the simple move of converting Wikipedia links to Wikidata links ?

Ok sorry for the probably fruitless rant, but it's frustrating to see that things that should be so simple are going along so slowly. --Zolo (talk) 19:03, 14 August 2017 (UTC)

well, having some experience trying to convert wikipedia links from another dataset into wikidata links, the actual problem is most likely that the wikipedia link is to a page that *contains* information about the linked item, but isn't exactly about the linked item. For example an OSM entry for a particular building might point to a wikipedia link for the company that operates out of the building, not to the building itself. ArthurPSmith (talk) 19:34, 14 August 2017 (UTC)
Thanks for the input. It does not seem to apply to OpenStreetMap, or at least, it's not supposed to. Per doc [9]
You may tag secondary attributes of the feature by preceding the wikipedia key with the name of the attribute, separated by a colon (:). The value of such a key would be the same as the normal wikipedia key, but referring to the appropriate wikipedia page. For example, operator:wikipedia=en:McDonald's on a McDonald's fast food unit (but don't forget to also tag operator=McDonald's, because the former tag doesn't replace the latter). 
only provide links to articles which are 'about the feature'. A link from St Paul's Cathedral in London to an article about St Paul's Cathedral on Wikipedia is fine. A link from a bus depot to the company that operates it is not.
I should admit it cites the following (that 'applies to almost no case'), that more or less contradicts the above requirement:
One example where it is appropriate to provide additional explicit links to articles in secondary languages is where the subject is included in an article on a broader subject in the secondary language, for example to the English article which the particular museum in France while French wikipedia has only wikipedia:fr=Monuments et sites de Paris. In another example the structure of subjects in articles cannot be matched 1:1 with interlanguage links (or maybe there are several articles for the same object). In these circumstances use the format wikipedia:lang=page title for the secondary languages.
In any case, that seems like a secondary concern. Would seem much more productive to just upload all Wikidata ids and clean up the few problematic cases afterwards. --Zolo (talk) 20:24, 14 August 2017 (UTC)
Wouldn't it be possible to match OSM node types to Wikidata classes, so that a bot could convert Wikipedia links to Wikidata ids only in the case where the node type and the item type match? We already have OpenStreetMap tag or key (P1282) that could be used for that. Intuitively, that would already cover a decent number of cases, and would be pretty safe. But I can imagine there are cases where the type mismatch is spurious and the Wikidata id should be added anyway. − Pintoch (talk) 09:25, 15 August 2017 (UTC)
My knowlege of OSM is rather shallow, but I think wikipedia|wikidata links should rather go to shapes or ways than nodes. That's also where I have usually seen them (I don't know how to get real states about that).
I suppose we could try a filter by class, but what I see is OpenStreetMap tag or key (P1282) are not subclasses of geographic entites, so that seems rather hard to use [10]. Anyway, if a Wikidata link in OSM is wrong, chances are the Wikipedia link is wrong as well and should be deleted anyway. --Zolo (talk) 10:15, 15 August 2017 (UTC)
"push for the simple move of converting Wikipedia links to Wikidata links": You are far from the first person to ever suggest this to the OSM community. But for many reasons, the OSM community is very wary of massive bot editing and will reject any such proposal if the result is less than 99.9% correct. For example, there are many OSM objects that point to a Wikipedia disambiguation page instead of to an actual article (because things move around in Wikipedia). So blindly adding a Wikidata tag pointing to a Wikimedia disambiguation page Wikidata item is a huge no-no even if it would result in relatively few false-positives. Of course a bot can learn to avoid auto-tagging disambiguation pages but that is just one example; there are potentially many other possible problems. As far as I can tell, the current OSM consensus is to let mappers update/add the Wikidata tag slowly but surely instead of letting a bot do the job.
Anyway, here are two posting to the main OSM mailing list by User:Yurik (senior software engineer at the Wikimedia Foundation) to help add Wikidata tags to OSM objects: [11] and [12]. So there's already an ongoing effort to essentially do what you want. You should also read his OSM Wiki page about OSM–Wikidata questions to get an overview of the many problems of further interlinking OSM and Wikidata. —seav (talk) 00:12, 18 August 2017 (UTC)
I realize [13] has not been mentioned in this thread yet. It is a great app, give it a try! − Pintoch (talk) 06:09, 18 August 2017 (UTC)

I described my efforts to merge OSM and Wikidata in the same SPARQL database. As seav mentioned, linking to disambigs is one of the problems, so my service helps find it with a query (still requires manual fixing), as well as many other similar queries. Any help to actually fix the data is welcome. At some point, I hope it integrates into MapRoulette challenges as well. --Yurik (talk) 16:50, 18 August 2017 (UTC)

@Pintoch, Seav, Yurik: ok thanks. The thing is those wrong links are basically already there in the form of wrong Wikipedia links. If the OSM community could agree that the wikipedia key is obsolete, we could upload all Wikidata links, and then clean them up using Yurik's tool. It would not really add new errors (except when the wikipedia sitelink is wrong, but that's not catchable through Sparql anyway). It seems a lot simpler than dealing with Wikidata keys + Wikipedia keys | candidate Wikidata keys. But of course, that supposes that the OSM would agree with drop maintenance the Wikipedia key in favor of the Wikidata key. But obviously that implies that the OSM community agrees to focus on Wikidata instead of Wikipedia.
Well I suppose that with tools like things can go a bit faster, until now I was using Wikidata ids I need directly through the map, and that's painfully slow. FYI, frwiki is now using the OSM wikidata link to get the geoshape in the infobox, like in fr:Château de Southsea. --Zolo (talk) 15:46, 20 August 2017 (UTC)

Removal of labels by bots[edit]

Within the last days I observed the deletion of all labels of an id by bots. For instance it was done for Q14201291 by PLbot. Q14201291 is now a redirect to the id Q11904043 which represents a disambiguation page to different geographical sites all named أبو صير (variant أبوصير but the same). Unfortunately most of the users cannot speak Arabic that's why we are using transcripted Latin lemmas. But they differ by language using language-dependent writings like Abusir, Abu Sir, Abū Ṣīr, Abousir, Абусир and so on. Normally these labels should have both the same meaning and spelling.

These disambiguation ids will help to find the same lemma in languages with non-Latin letters and different Latin writings. It makes no sense to have a separate id for all writing variants.

I do not know/understand why bots delete these labels solely because of slight differences in writing. --RolandUnger (talk) 11:59, 15 August 2017 (UTC)

The Wikidata way to find these locations would be rather than visit a disambiguation page elsewhere.
--- Jura 12:14, 15 August 2017 (UTC)
@RolandUnger: If you don't want to have separate items for all writing variants, what do you suggest to do with no label (Q29390469), no label (Q28965736) and Abusir (Q11904043)? Merge is not possible since each item can only have one sitelink per project. PS. I would appreciate to get notified if my work is discussed here --Pasleim (talk) 12:22, 15 August 2017 (UTC)
Of course it is a problem if you have a wiki with identical articles (independently of standard or disambiguation pages). This is not a problem of Wikidata but a problem of quality control and maintenance at these wikis. With my knowledge of these ids or geographical sites I could merge them all. If a merging is not yet possible because of comprehensive merging of the wiki articles then the property P460 ("said to be the same as") should be set for both ids to find all variants for maintenance. In the case of Abu Sir the problem arose from bots which could not think about different lemma writing for the same thing.
The Reasonator tool is a nice one but not known to the general public and it should help to merge identical Wikidata ids. But if a bot will delete all labels then Reasonator cannot find a duplicate.
Maybe as a proposal: If we have different writings of (geographical) objects then we should have a list of aliases which is valid for all languages to save time to enter them for all languages. --RolandUnger (talk) 15:18, 15 August 2017 (UTC)

Here, I'm an idiot (Yet Another Whinge)[edit]

First time I've needed to update something cached away in Wikidata, and I find I'm an idiot! Nothing about the process, the editing, was at all obvious. How strange that an experienced editor (since 2004 Global Contribs) would have such problems? I succeeded, but it took more than a couple attempts... Why such a mismatch with expectations?

I noticed that the repository info on page en:Blink_(web_engine) was wrong. I even first searched for the maillist conversation that pointed me to the correct information for that factoid. Then got flummoxed at no link in the Infobox text. I don't remember what tidbit finally made me clicked on the "shadow source" for info being Wikidata.

(Hmm, possibly reading the page source, then using incantations to get to en:Template:Infobox, then realizing I needed instead en:Template:Infobox_software, and then finding the description of 'repo' there, and then seeing the mention of "attempts to acquire the repository link from Wikidata." "Beware of the Leopard" time...)

But that is problem one, hinting/reminding people that text may be sourced from somewhere mysterious.

(Hey, the blaring hooting notices hidden at top of the template page that "This template uses the Wikidata property: official website (P856)"
{*{Uses Wikidata|P856}}{{Tracks Wikidata|P856}}
would have told anyone something's afoot with 'repository' (P1324), right? Or perhaps... since that notice has a direct link to here Property:P856, the same kind of shortcut should be placed inline in the template help everyplace it mentions data 'might' come from Wikidata? I mention this because there is no obvious link in that help to Wikidata. Dumb, no?)

I don't know how I finally got to the page here Blink because, again, there is no obvious way to get from "this page may reference wikidata" to the mirroring page here to check if that the wrong information is from here.

But that is problem two, no obvious link to the wikidata 'shadow' page here given a page at :foo: wiki.

So I scroll down to "source code repository" and wonder what to do. Click 'Edit'. Why is 'Save' already checked?!? How do I save the changed data? The popup help says "Enter a value". How? The save link is grayed out! I still don't know - I think I experimentally clicked "Add Qualifier" or "Add Reference" and it just happened.

BTW: what's a 'Qualifier'? What's a 'Reference'? I wandered around and found Wikidata:Glossary#Reference and then scrolled up to see qualifier. But my question was really, how and where do I enter my justification for the change? How do I point someone to the 'proof' the change was reasonable? I still don't know if I did the right/best thing!

But that is problem three, how does one edit this pineapple correctly without everything blowing up?

(What is the best thing to do? How does one say "I know this item value is true because of the information I found at <blah>, be it web, book, newspaper, etc." ?)

A key problem described here is, how do you help strangers to quickly fix that one fact they found wrong in another wiki. They don't *want* to be here. They shouldn't have to jump through fiery hoops. Y'all have reams and reams of help, but that is actually a hindrance for the greatest number of editors, those from somewhere else. (Sorry, the important editors for Wikidata are not the most frequent people here, but rather the infrequent or one-time visitors.) Asking people at Wikidata:Introduction#Where_to_get_started to take a tour on elephant back is really discouraging.

And isn't it strange that a wiki, a set of wikis, somehow makes it quite difficult to navigate to information? Is this perhaps a missed facet for implementation of Wikidata at the "system level"? Poor Ms. U. N. Owen has near no chance to bridge all the gaps in order to remedy the smallest data problem. This is an implementation problem hampering a good idea.

Please take the time I've spent describing my experiences as an indication of how far from 'good' that experience was. There are far too many hurdles to jump now that data 'might' come from Wikidata. Without lowering those hurdles you leave the implementation unfinished, incomplete, and far from practical for your average editor. Shenme (talk) 00:19, 16 August 2017 (UTC)

Hey, look, at en:Blink_(web_engine) in the left sidebar under 'Tools', "Wikidata item" ! How helpfully mysterious to the occasional editor. Shenme (talk)
@Shenme: First: Come here and complain that templates on Wikipedia are poorly designed is not going to give you any sympathies here.
Some helpful soul over there has pointed out a gooder template, how it has listed a more complete set of interrelationships to Wikidata, and how uses of the template even include shortcuts (the pencil icons) next to each imported value in the infobox. All of these go very far towards giving the confused editor things to click on and hope to be unconfused. Shenme (talk) 22:22, 16 August 2017 (UTC)

Secondly: Your experience, as you describe it above, summarize well what I feel about VisualEditor or Flow. It takes some times to learn, and it does not help if you think that the idea behind them were bad from the beginning. (Belive me, WYSIWYG (Q170542) is pure evil!!!) -- Innocent bystander (talk) 06:04, 16 August 2017 (UTC)
(ec) I don't have to time to deal with all your whinges, so I deal with just one. There is a project to allow the editing of data from the wikis more directly in WD with a user interface, it just isn't here yet. The thing about fixing a data point in WD is that it fixes the same data point in each wiki, and that becomes a whole lot quicker and easier to do once. Similarly with centrally stored data, it allows the creation of pages in multiple languages that can at least show data in a contextual language where a wiki is yet to create a specific article. Rome wasn't built in a day.  — billinghurst sDrewth 06:10, 16 August 2017 (UTC)
I very much understood the great promise of centralizing data that should be uniform across the multiple wikis. That is why I went to the trouble of correcting something, here, rather than just jamming it in locally at enwiki.
When Rome conquered, they didn't allow uncertainty about how things would be done from then on. They made sure the rules were painfully obvious. No one ever complained "but we didn't know how to pay our taxes!" It remains the case here that how to submit taxes (or data) is unclear to the average plebeian. Having to travel to Rome, learn passable Latin and obtain favorable omens just to correct your middle name on the last census... Shenme (talk) 22:22, 16 August 2017 (UTC)

@Shenme: thanks for taking the time to point out your challenges in fixing something here. As billinghurst mentioned there is development work ongoing to make it easier to edit wikidata entries directly from wikipedia. However, I think the main point of your complaint was uncertainty in how to source the change you wanted to make which will surely still be a problem for more direct wikidata editing from the language wikipedias. I know Lea Lacroix (WMDE) has been working to get documentation here improved - Lea, should we perhaps focus on a one-pager simple outline for people familiar with regular wikipedia editing, on how to fix one claim with appropriate referencing? ArthurPSmith (talk) 14:17, 16 August 2017 (UTC)
As mentioned above, there are certainly improvements possible at the originating wikis. (I love the pencil icon shortcuts in the mentioned template.) Is it possible a "first visit" here can kick off a popup or page-top link to the quick cookbook recipe "how to make an omelette"? If they've just been dropped here from a wiki page pencil link, and it all looks so different and strange, a friendly smile and quick recipe will be very enticing. Shenme (talk) 22:22, 16 August 2017 (UTC)
Thanks Shenme for your description of the problems. I'm sorry that you encountered such troubles while editing.
About documentation: the first part of the issue is about the infobox on English Wikipedia. I think that the documentation should be improved there. Unfortunately, since each Wikipedia develop their own version(s) of infoboxes, we can't really provide a global documentation. We've been also working on Wikidata:How to use data on Wikimedia projects but it doesn't really help the casual editor, it's more for people who want to create new templates on their wiki. Maybe a simple page about how to edit Wikidata for Wikipedians could help - but again, with the problem of the different infoboxes from a Wikipedia to another.
I tried to reproduce the problem you encountered while trying to modify a link and add a reference, but I couldn't. If you edit Wikidata again and find this issue another time, I'd be glad to know about it so we can track a possible bug. Lea Lacroix (WMDE) (talk) 13:01, 17 August 2017 (UTC)

perceptible object (Q337060)[edit]

Any possible difference between perceptible object (Q337060) and physical object (Q223557) ? d1g (talk) 17:33, 16 August 2017 (UTC)

Yes, one is a philosophical concept (something perceived), and the other is a physical concept (something that has measurable properties). There's lots of overlap, but we seem to have 5 distinct language wikipedias with entries for both, so they are definitely deserving of being distinguished. The German terms "Gegenstand" vs "Körper (Physik)" seem quite distinct. ArthurPSmith (talk) 17:54, 16 August 2017 (UTC)
perceptible object (Q337060) is very similar to object (Q488383) IMO d1g (talk) 18:49, 16 August 2017 (UTC)
Both are different views/concepts about entity (Q35120). --Succu (talk) 20:53, 16 August 2017 (UTC)
Pictogram voting comment.svg Comment If this item because of Aristotle works (0199326002, p 78), then I suggest to use has quality (P1552) for items about senses and what else is meant about "perceptible"
I do exactly this for food products. E.g. taste can be only with specific chemical elements.
Aristotle had no information what was where, so their explanation is almost always without examples (5 senses e.t.c) d1g (talk) 21:35, 16 August 2017 (UTC)
Mind to decipher 0199326002, d1g? --Succu (talk) 21:34, 17 August 2017 (UTC)
ISBN number and page d1g (talk) 08:06, 18 August 2017 (UTC)

Categories for Cities?[edit]

A general question, but a specific example.

Cebu City Q1467 only had the category Q104157 "City in the Philippines". I added Q515 "City" for a top-level description of what it is. Is this the intended approach? Should I have added Q1549591 (big city) instead? Power~enwiki (talk) 19:37, 16 August 2017 (UTC)

For instance of (P31) (it's better to avoid the term category, this can get confused with Wikipedia categories), you should generally use the most specific item available - so city of the Philippines (Q104157) rather than city (Q515). The Philippines one is already a subclass of "city", so there is no need to add both - a properly constructed search will find both items marked with city (Q515) and items marked with any subclass of it.
big city (Q1549591) covers a different aspect of the item to city of the Philippines (Q104157), so it would be reasonable to include both (assuming it is indeed a sufficiently large city).
The one major exception to this is people, who should always simply be instance of (P31):human (Q5), not "woman", "doctor", "Danish person", or any other more specific group. Andrew Gray (talk) 20:29, 16 August 2017 (UTC)
The reason why we don't use "instance of woman" or "instance of doctor" is that we have more precise properties to express these relations: sex or gender (P21), occupation (P106). The same I think about "big city". We have population (P1082) to express how big a city is, so adding big city (Q1549591) in addition to city of the Philippines (Q104157) or city (Q515) seems superfluous to me. --Pasleim (talk) 09:01, 17 August 2017 (UTC)
+1 --Marsupium (talk) 12:07, 17 August 2017 (UTC)
That seems fair! I had assumed that big city (Q1549591) was recommended as it's fairly widely used, but I agree that it seems unnecessary (and a bit arbitrary) given that we can also represent population. I wonder if it's worth removing it in any case where population is listed. Andrew Gray (talk) 20:56, 17 August 2017 (UTC)

Hokusai and the Kai Province (Q17227583) is an instance of what?[edit]

As its first paragraph says, Hokusai and the Kai Province (Q17227583) is a Wikipedia article containing general remarks about the relationship between the painter Katsushika Hokusai (Q5586) and the Kai Province (Q858076).

What is it an instance of?

Thanks! Syced (talk) 10:07, 17 August 2017 (UTC)

Exact reason why facet of (P1269) was created, we don't need P31 here;
Only 2 items should get P31, not 3rd. d1g (talk) 11:01, 17 August 2017 (UTC)
I don't understand what you mean... items should have a instance of (P31)/subclass of (P279) statements... what do you do here ? what are these items ? --Hsarrazin (talk) 13:13, 17 August 2017 (UTC)
we don't need P31 or P279 at Q17227583
only Q5586 and the Q858076 should have P31 or P279 d1g (talk) 13:18, 17 August 2017 (UTC)
I don't understand what you mean... your second answer is no more explicit than the first... I tried to read the discussion on facet of (P1269) but this in not any clearer :((
could you please develop and explicit ? and if you can't, could somebody please explain ?

use of facet of (P1269) property[edit]

@Andrew Gray:
thanks but I still do not understand : AFAIK, all items should have a P31 or P279, and I have never seen any instruction to do something else...
is there a help page, or discussion, or anything explaining the facet of (P1269) property, and how it is to be used ? that's the first time I see it used, and I would like to understand :/
thanks for your help --Hsarrazin (talk) 21:09, 17 August 2017 (UTC)
see examples, most of them don't have P31 or have something else Help:Basic membership properties d1g (talk) 08:30, 18 August 2017 (UTC)
Maybe we should have a class for "Wikipedia article relating two or more concepts" similar to "Wikimedia list article", "Wikimedia disambiguation page", etc. ?? ArthurPSmith (talk) 13:45, 18 August 2017 (UTC)
Symbol support vote.svg Support Mahir256 (talk) 15:15, 18 August 2017 (UTC)
Ok, ✓ Done :) See Wikimedia page relating two or more distinct concepts (Q37152856). ArthurPSmith (talk) 15:32, 18 August 2017 (UTC)
I wonder if it's a good idea to include "Wikimedia" in its label.
--- Jura 08:35, 21 August 2017 (UTC)

Means to flag constraint suggestions and/or variations?[edit]

Do we have a template to apply, or a category to add, where we have suggested on a property talk page for a variation or suggestion for a constraint? Leaving a suggestion sitting on a talk page without a little flag often means it can not be noticed by those with the skills to do so.  — billinghurst sDrewth 05:10, 18 August 2017 (UTC)

means to record location of a plate/illustration within a work, though not through a page number?[edit]

I see in Leuchtenbergia principis. Noble Leuchtenbergia (Q14554954) that the image has been identified as page(s) (P304) then "plate nnnn" which is a constraint violation. I am seeking the community's opinion on how an illustration's location should be identified within a work. We can sometimes put a page number, however, sometimes it will be "opposite p. nnn" or some other identifier that is not a page number though is evident within a work. Do we have an existing means outside of P304 to do this? Thanks.  — billinghurst sDrewth 05:17, 18 August 2017 (UTC)

You could probably use section, verse, or paragraph (P958) with value "plate xx", but I think a new property might be the most elegant solution. - PKM (talk) 20:02, 18 August 2017 (UTC)
Shouldn't mix with page numbers, wait for property
Wikidata:Property proposal/Illustration number or similar d1g (talk) 17:40, 19 August 2017 (UTC)

Wikidata and redirects in Wikipedia[edit]

We have Joest Henne (Q24035983) that is the same person as no label (Q30229797). In sv.Wikiepedia there is an redirect Jost Henne -> Joest Henne. Question What is the correct way to just have "one" Wikidata object i.e. I would like to have my Property Q24035983#P3217 only at one place but maybe in Wikidata indicate that a merge has been done.... - Salgo60 (talk)

The svwiki link to "Jost Henne" should be removed, and Q30229797 merged into Q24035983 - there should be only one wikidata item for this. ArthurPSmith (talk) 13:57, 18 August 2017 (UTC)
(edit conflict)It doesn't make sense to keep two items about the same person. I have → ← Merged them. Thanks for bringing it up. Matěj Suchánek (talk) 13:58, 18 August 2017 (UTC)
@Salgo60: see Help:Merge and also to note the merge tool in the gadgets.  — billinghurst sDrewth 14:13, 18 August 2017 (UTC)

Displayed image in every item[edit]

It would be great that every image inserted in an item as a Property:P18 would also be displayed in the upper right corner so you can even more quickly recognize the object. What do you think? --Janezdrilc (talk) 12:07, 19 August 2017 (UTC)

Have you enabled ImageHeader in your preferences? Matěj Suchánek (talk) 12:39, 19 August 2017 (UTC)
Image doesn't appear when window size is small.
If I zoom out 50% it is always present.
Chromium 60 (~August 2017) d1g (talk) 20:24, 19 August 2017 (UTC)
Interesting. In my case the image needs 80% or less to appear. --Janezdrilc (talk) 22:37, 19 August 2017 (UTC)
I think the image does always appear, but not always in the upper right corner. If you have a more narrow window the image appears in the left column, after all statements and identifiers, but before the links to different projects. I can make the image "disappear" from the right column even if the zoom is 50% or lower if the window is made small enough. This "dynamic layout" of the Wikidata interface (web pages) was very confusing to me on my first visits here. --Larske (talk) 23:49, 19 August 2017 (UTC)

P393 or P1545[edit]

Which one? (or something else?)

(Please don't discuss about P3450). I want to use P393 or P1545 as a qualifier.


P1545 seems more logical to be used. But, honestly, I haven't understood the difference between those two properties.

SELECT ?item
    { ?item wdt:P3450 [] }
    { ?item wdt:P393 [] }

Try it!

SELECT ?item
    { ?item wdt:P3450 [] }
    { ?item wdt:P1545 [] }

Try it!

Xaris333 (talk) 13:53, 19 August 2017 (UTC)

labels from series ordinal (P1545) are more appropriate for events.
Constraint at series ordinal (P1545) can be changed. d1g (talk) 17:59, 19 August 2017 (UTC)
No need to change. I think is better to use it as a qualifier. Xaris333 (talk) 18:28, 19 August 2017 (UTC)

Bonnie & Clyde (cont.)[edit]

Hi I made some changes to Help:Handling sitelinks overlapping multiple items and I think we need more examples of the issue as well as the possible relationships. I only scratched the surface and before I go further I would like invite some participation from domain specialists to add their 2c such as the "fruit/tree" people. I remain as ever convinced that is is a docuumentation issue. Thx. Jane023 (talk) 14:18, 19 August 2017 (UTC)

  • As items are less empty, it should essentially become a non-issue for Wikidata. Either the article is about be same as the statements and it can be linked, or should be on another item.
    For Wikipedias, it's mostly a data access question: which item do they want statements and/or sitelinks from. If a Wikipedia wants any stub link to lists at other languages, it could build a feature that does that.
    --- Jura 08:09, 20 August 2017 (UTC)
Yes I agree. My problem with understanding people who want this is that I have trouble trying to figure out what it is that they believe they *can't* do as it is now. It seems to me that there needs to be more help documentation on both sides; the side of Wikidata (what inter-item links can do for search purposes) and the side of Wikipedia (what an infobox, authority control template or other Wikipedia-side functionality is desired). Jane023 (talk) 11:55, 22 August 2017 (UTC)

Change labels to other languages[edit]

Hello. Because many users are confusing sports season of a sports club (Q1539532) with season of a sports league or competition (Q27020041), please change the labels and/or the descriptions for the languages you know to show that:

  • the first one is used only for seasons of a sports club, not for a season of a sports league
  • the second one is used only for a season of a sports league or cup, not for seasons of a sports club

Thanks. Xaris333 (talk) 00:04, 20 August 2017 (UTC)

Such widely used items like sports season of a sports club (Q1539532) shouldn't be transformed in something else! I suggest restoring the version before 30 July 2017‎ as now there is a total mess: different series of items like 1950 Formula One season (Q68926), Tennis-Bundesliga 2000 (Men) (Q163626), 2002 American Le Mans Series season (Q294472) have sports season of a sports club (Q1539532) in P31... --XXN, 13:59, 20 August 2017 (UTC)
Already in July 2015 the meaning of sports season of a sports club (Q1539532) was specificed to be for sports clubs [14]. In September 2016 then was season of a sports league or competition (Q27020041) created for sports leagues. I don't think that restoring the state of July 2017 will here be helpful. --Pasleim (talk) 14:14, 20 August 2017 (UTC)
I am trying to solve the problem and to correct the statements at the items (I have used any tool I know.). But are almost 50000 items with sports season of a sports club (Q1539532). It's difficult work to find which of them must have season of a sports league or competition (Q27020041) due to the huge number of the items... Xaris333 (talk) 20:45, 20 August 2017 (UTC)

Free books[edit]

Hoi, when organisations have free books available for reading, it makes sense to indicate this in our items for these books. Obviously, when such an organisation we want to know about the authors it knows. My question, how do we indicate in what format a particular books is available at that organisation? Thanks, GerardM (talk) 08:22, 21 August 2017 (UTC)

Bonnie & Clyde problem and links in Wikipedia infoboxes[edit]

There is an wikidata item (ab) for wikipedia articles covering several concepts. To distinguish the individual concepts there is one wikidata item for each (item a and item b). Item a is used as a statement value on several other items. A wikipedia is using the data from these items in its infoboxes. It has only an article connected to item ab (article ab), not to a. Infobox data referring to item a should appear with a link to article ab. How can this be realised?

To have a specific example: There is a current situation involving the items historiography (Q50675) (dealing both with historical works and the discipline of studying the ways of writing history - an example of item ab), item historiography (Q30277550) (dealing with the type of work - an example of item a), Histories (Q746583) (an example of an item with item a as statement value) having "historiography" as its genre, the Spanish wikipedia article Historias (Heródoto) connected to Histories (Q746583) and the Spanish wikipedia article Historiography connected to historiography (Q50675). People from the Spanish wikipedia (e.g. Xabier) want the infobox-entry "historiography" to link to Historiography. The current "solution" is to use historiography (Q50675) as a statement value for genre. But in my opinion this is rather undesirable as historiography (Q50675) does not represent historiography as a genre (alone). - Valentina.Anitnelav (talk) 08:39, 21 August 2017 (UTC)

This is the job of WP to choose the correct WD item, we can't help them when several subjects are mixed together in one article. Once the item is selected then it is access to the data of others items using lua code. You just need to know the Q number of other items and used them when performing data extraction from WD. Snipre (talk) 11:50, 21 August 2017 (UTC)
Hm... What do you mean with "this is the job of WP to choose the correct WD item"? As far as I see the WD-item they "chose" is all right (Histories (Q746583) for Historias (Heródoto)). I also think that they're absolutely fine with the extracted data. All they are missing now is a link to Historiography, or basically a redirect from the non-existent Spanish article for historiography (Q50675) to Historiography. Should they just give up fetching these data from wikidata and should I recommend them to provide the genre-information locally? -Valentina.Anitnelav (talk) 18:37, 21 August 2017 (UTC)
Valentina.Anitnelav My comment is about your general example: an article about a and b, where a has a dedicated item in WD and b too. The choice of item a or item b for article ab is under the responsibility of WP contributors. We can't decide here in WD what is the best solution.
Then if you know the item a and the item b, meaning if you know the Q number of these items, you can extract the data from both items in your article (even if your article is connected to only one item) by using parsing functions described in that page. But nobody can tell from WP which are the Q numbers for a and b: you have to find them yourself and then you can use the parser functions instead of the values in order to always be connected to WD. Snipre (talk) 20:24, 21 August 2017 (UTC)
Thank you for the link, but I fear this is not a solution for the problem (not even in the general form): the problem is not how to fetch data from item a and/or item b to display them on article ab. The problem is how to link from an wikipedia article displaying item a (or its label) in its wikidata-generated infobox via item a to wikipedia article ab. Have a look at De bello Hispaniensi. This item should have a link to Historiography in its infobox (via "Historiografía", fetched from historiography (Q30277550)), but they can't have the link unless changing item De Bello Hispaniensi (Q783927) in their favour (by changing the value of genre (P136) from historiography (Q30277550) to historiography (Q50675)), but this change is rather undesirable for wikidata as historiography (Q50675) is ambiguous and historiography (Q30277550) is the item for the genre. -Valentina.Anitnelav (talk) 21:00, 21 August 2017 (UTC)

My Entry Keeps Getting Blocked?[edit]

Hello, i have attempted to make a wikedata item for my small business and it keeps getting deleted. I get the message that i was making a "promotion only page", i need your help. The only info that i am listing is:

  • address
  • url
  • logo
  • industry
  • etc.

I am only listing the basic info that a business would list, i don't see anything promotional about listing basic contact and location data but i'm not the expert. Can you give advice as to how someone would list the basic info of a small business.  – The preceding unsigned comment was added by (talk • contribs) at 12:01, 21 August 2017‎ (UTC).

When somebody else have noticed your business and thought it is good enough to write an article in Wikipedia about it, then it is time to add an item here about it. -- Innocent bystander (talk) 12:08, 21 August 2017 (UTC)
A Wikipedia article is not a requirement for inclusion in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 21 August 2017 (UTC)
See our policy on notability: WIkidata:Notability, which determines what we do and do not include in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 21 August 2017 (UTC)
@Pigsonthewing: Even if the business-item here potentially can be kept according to our policy, it is not our purpose here to do marketing! -- Innocent bystander (talk) 12:24, 21 August 2017 (UTC)
If they present correct information, then this shouldn't be a problem.
But as a project we could grow a pile of outdated items which few have interest to update (even to set "end date"). Somebody would need to update these item later, some things to consider:
  • isn't short-lived (6 months-2 years)
  • unique for territory (small island)
  • rare industry d1g (talk) 16:13, 21 August 2017 (UTC)
What does that have to do with what I said? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:33, 21 August 2017 (UTC)

Wikidata weekly summary #274[edit]

How to express different alternatives for value-type constraints ?[edit]

What is the correct way to indicate that different acceptable alternatives exist, when specifying a property constraint (P2302) : value type constraint (Q21510865) ?

For example, position held (P39) can take a value that is either

(Sometimes made more precise through attching the qualifier of (P642) to the generic value).

How should one indicate this in the P2302 specification for position held (P39) ?

I tried simply adding subclass of (P279) below instance of (P31) in the statement (diff), to indicate that either is possible, but this is now producing a red error message on Property talk:P39.

Is there a different way to indicate acceptable alternatives ? Jheald (talk) 15:46, 21 August 2017 (UTC)

complex constrains
if you need assistance, leave requests at talk pages or "request a query". d1g (talk) 15:58, 21 August 2017 (UTC)
(ec) A complex constraint would be one way to go, but I'd prefer to use the standard mechanism if possible.
I see that Metamorforme42 (talkcontribslogs) has tried changing the relation required to instance or subclass of (Q30208840) (diff), which looks like it may be the solution needed. Jheald (talk) 16:06, 21 August 2017 (UTC)
Please re-read the phabricator task. Such a constraint is currently not implemented, neither by the daily reports nor the gadget. While experimenting is desirable, I don't think we should change these constraints back and forth just because you attend some work shop the day after tomorrow.
--- Jura 16:22, 21 August 2017 (UTC)
@Jura1: The workshop was the day before yesterday.
IMO it's better to have a statement that accurately expresses the constraint required, even if that value is not currently understood, and so the constraint is not currently implemented; rather than specify a false constraint just because it can be implemented, which causes people to put false statements on the data in order to make false constraint warnings go away.
If necessary, as D1gggg (talkcontribslogs) suggests, we can implement instance or subclass of (Q30208840) as a custom constraint, until the centrally-maintained constraint machinery can take over. Jheald (talk) 16:49, 21 August 2017 (UTC)

I suggest leaving instance or subclass of (Q30208840) on it for the moment, even if the constraint mechanism doesn't currently understand that value, so can't enforce it; and meanwhile add encouragement to so that soon it does get understood and acted on. Jheald (talk) 16:21, 21 August 2017 (UTC)
So @Yair rand:, I just imagined the (entirely appropriate) chain mayor (Q30185) subclass of (P279) public office (Q294414) , subclass of (P279) position (Q4164871) did I ?
And your nonsense of insisting on writing mayor (Q30185) instance of (P31) position (Q4164871) when (i) mayor isn't a position -- it's a class of positions; and (ii) the P279 chain already expresses this.
Fine, let's see what the rest of the community thinks, if you really are determined to persist with this nonsense.
External input requested at Wikidata_talk:WikiProject_Heads_of_state_and_government, essentially as to whether items like mayor (Q30185) are an instance or a subclass. Also items like Mayor of London (Q38931), since you appear to have restored a constraint (diff) that all values for P39 statements need to have a subclass of (P279) set -- which seems completely crazy to me. "Mayor of London" is a position, and there is only one of it. Jheald (talk) 22:46, 21 August 2017 (UTC)

Making mass changes[edit]

I've being doing some clean-up of data on listed buildings and scheduled monuments in the UK in preparation for Wikipedia Loves Monuments UK 2017. The query I've been using identifies buildings whose coordinates are not in the named administrative area. For example, 1, Bridge Street (Q26578136) has the property located in the administrative territorial entity (P131) set to Richmond (Q7330735) (a place in South Yorkshire, England), when it should be Richmond (Q1009324) (a town in North Yorkshire, England).

It's easy enough to make the change in one item using the standard user interface. However, I've found 300+ items that require exactly the same change to the located in the administrative territorial entity (P131) property. Are there any tools/bots/scripts around that would make this sort of repetitive change easier and quicker?

If not, does anyone fancy creating a tool that can manage this sort of change with a batch command file or a bot running in the background? Cheers Robevans123 (talk) 19:41, 21 August 2017 (UTC)

Sounds like you are looking for Petscan. If you query your items with the SPARQL option and log on to Widar, you'll see an input form to batch-edit the items returned by the query. You can add and/or remove claims in a single run. --MisterSynergy (talk) 20:04, 21 August 2017 (UTC)
Thank you - that looks promising - I'll give it a go. Robevans123 (talk) 20:21, 21 August 2017 (UTC)
@Robevans123: I don't know to what extent you may already have met them, but if you have the means to identify large numbers of edits you want to make, two invaluable tools are QuickStatements and QuickStatements 2. Both of these can rapidly create large numbers of statements, as specified from a (spreadsheet-style) set of tab-separated lines. The original QS has the better documentation page; but QS2 has much better previewing of what it's about to do, and also adds the ability to remove statements.
From what you already have, it should easy to create such a set of statements for QS2 to remove, interleaved with a corrected set for QS2 to add.
One thing to note is that the statements are re-created from scratch, so you should look out for any existing references or additional qualifier clauses, as you will need to explicitly include these in the directives for the new statements for QS2 to make.
On a different note, I'm quite excited to see you working on this data. Previously quite a lot of the located in the administrative territorial entity (P131) statements have localised items to only quite a crude level (eg county level, or perhaps district level). But I believe the data generally identifies LBs and scheduled monuments to a parish level. Our coverage of civil parishes in England is now to in the 90%s (or was, the last time I looked, a few months ago). So, if you're cleaning up this data, has it been possible to reflect that potential for better localisation, typically to CP level ? Jheald (talk) 21:38, 21 August 2017 (UTC)
@Jheald: Yes - I've used the original QuickStatements - but had discounted that as only been good to add statements. I had a look at QS2, but didn't realise you can use it to delete statements, and couldn't even work out how to enter statements - where do you enter the commands?! Is the syntax the same? Very frustrated!
Definitely want to refine the listed building/scheduled monument data. Quite a few don't have any located in the administrative territorial entity (P131) statements, and the descriptions leave a lot to be desired. I think I've fixed most of the ones that had England as the admin area... Definitely best to get down to the civil parish level where the data is available.
After fixing a couple of thousand buildings/monuments with incorrect parishes, I've found the coverage of parishes for England looks pretty thorough, and I think most, if not all, listed buildings/monuments are also covered to some extent. Need to do some work on the Welsh data to catch up in both areas! Cheers. Robevans123 (talk) 22:23, 21 August 2017 (UTC)
@Robevans123: Syntax for QS2 is just the same. Click on the "Import commands" tab at the top, then the "Version 1 format" button that appears. An input window will appear, into which you can paste a file of QS1 commands. Starting a line with '-' causes the statement to be removed, rather than added.
I had quite a crack at English CPs earlier this year. But (from when I last looked) there were still about 300 GSS codes not yet identified to a Wikidata item, and about 300 Wikidata items not matchable to GSS codes. Sadly those two sets don't appear to match. Some relevant queries at User:Jheald/todo/UK#Civil_parishes. In Wales it's communities rather than CPs, may not be so far ahead. Jheald (talk) 23:01, 21 August 2017 (UTC)

A Few More Paleontology Questions[edit]

  1. Is information about individual fossil specimens desirable for Wikidata?
  2. Is it possible or desirable to input multiple estimates for some aspect of a fossil specimen or taxon (eg Paleontologist Paul estimated this dinosaur's live weight to be 10 tons but Fossil Hunter Francine estimated it to be 12 tons).
  3. Is there a way to summon or transclude information in Wikidata to Wikipedia (eg could I say in a Wikipedia article "Examplosaurus first evolved during the [wikidataitemfortheageofexamplosaurus]" and have it automatically update with the information from Wikidata?).
  4. Is it possible to specify that the age of a prehistoric animal has a significant range of uncertainty? (eg "Kronosaurus first appeared sometime in the Aptian-Albian range")?

Abyssal (talk) 20:15, 21 August 2017 (UTC)

I changed your request to an ordered list. Now answers:
  1. Not sure if I understand correctly. If you can create items about individual fossil specimens which fulfill the notability criteria, you should in principle be able to do that. If you are unsure whether this is the case, or if we are talking about a really large number of individual fossils, you might want to describe your plans first in more detail here.
  2. You can provide multiple claims for each property, but it would be useful to add serious references according to Help:Sources to each individual claim. It might be useful to work with ranks to perfer one of them over the other (e.g. "most reliable source", "most sources report that value", etc.)
  3. Technically yes (parser functions #property: and #statement:, or Module:Wikidata). However, many communities are somewhat reluctant to allow this.
  4. Properties with quantity data type allow to provide uncertainty intervals by numeric bounds. In case your property expects a Wikibase-Item as value, you might want to use qualifiers such as earliest date (P1319) and latest date (P1326). (I hope that the time values you need are actually possible with these qualifiers).
--MisterSynergy (talk) 20:31, 21 August 2017 (UTC)

Annoying announcement[edit]

I'm user w:de:User:Silvicola of dewiki and personally didn't ever do any work here in Wikidata. Since a couple of days, on every consultation of the notices kicked out to me, I get the same thank you for my 100th edit here in wikidata. Yet I haven't even an account here and every try to enter here with my SUL account parameters did fail. So did every try to create the corresponding account here. (Please note: I'm presently not really interested to do here any work, I just wanted to get somehow rid of this annoyance.) Upon consulting “my” user contributions here, I found a list of exactly 100 lemma moves in dewiki, which seem all to have triggered corresponding action logged here, perhaps due to some script or so.

I can very well sustain one thank you, but a thank you repeated ad nauseam is too much. I still hope that after my next lemma move in the dewiki main namespace, this senseless repetition will end. But in any case, others must have suffered and will suffer from the same insistance. Perhaps one or the other of them might even think at pushing around abusively article name space lemmas in dewiki or on some other wiki simply to bring this stray automatism to an earlier end.

Trigger once upon arrival at the milestone, but don't trigger upon stay at the milestone. --2003:6A:6D45:500:4838:F7B9:C87F:B544 20:37, 21 August 2017 (UTC)

  • When you move a page in a Wikimedia project that is connected to Wikidata, you automatically perform an edit here to update the sitelink -- without being notified about this edit. Exceptions: the moving user does not have a local account at Wikidata, or they are blocked here (both not the case for you).
  • You have a connected SUL account, as far as I understand this result. The fact that you can (implicitly) edit Wikidata supports this finding.
  • Notifications for milestones are very common in many Wikimedia projects, but they are delivered only once and visible until they are marked as read.
  • I don't think that another page move at dewiki would help here.
  • So the problem seems to be that you can't log on to Wikidata for whatever reason, and you thus cannot successfully mark the milestone notification as read. What does is say if you try to log on?
--MisterSynergy (talk) 20:56, 21 August 2017 (UTC)

Eclipses, and how to talk about them[edit]

Hello! It would be a good moment to decide how to express the information about eclipses (magnitude, gamma, starting time, route...) in Wikidata. Maybe we could make a good work with the current one and go backwards using template harvesting! -Theklan (talk) 21:39, 21 August 2017 (UTC)

How about parameter of eclipse (Q37714908) (->magnitude of eclipse (Q1268559), gamma (Q827951), ...)? --Fractaler (talk) 07:23, 22 August 2017 (UTC)
We have a pending property for contact times of eclipses --Pasleim (talk) 07:36, 22 August 2017 (UTC)

Catalogue of the library of the American Philosophical Society[edit]


Je viens de créer le Catalogue of the library of the American Philosophical Society.

  1. Qui veut bien vérifier les données et compléter les informations ?
  2. Mon objectif est de préciser dans un champ que les ouvrages que je saisis sont répertoriés dans ce Catalogue of the library of the American Philosophical Society. En indiquant le numéro de l'ouvrage dans le catalogue original et le lien (c'est un id, je suppose) vers la fiche sur le site du catalogune. Comment dois-je faire cela proprement ?

Je vous remercie pour votre attention. --Ambre Troizat (talk) 11:27, 22 August 2017 (UTC)