Wikidata

Wikidata:Project chat/Archive/2013/12

< Wikidata:Project chat‎ | Archive‎ | 2013
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Proposal to enable abuse filter blocking

If you've been browsing the block log, you'll notice a lot of blocks that came because spambots were triggering Special:AbuseFilter/5. Blocking the addresses has become a rather large chore (because we want to block them as soon as they are identified, since they might later try to evade the filter), and it would of great convenience if the filter could just do the blocking automatically. Technically, because these are all IPs, finite block durations would be required, but can be configured for IPs separately from accounts. The filter has been very accurate, but to further guard against false positives, it would warn before blocking the IP. The change requires community consensus in favor of it.

  • No, the extension itself would block it, but the technical change to enable that functionality needs consensus. See Meta's block log for an example of it in action ("Abuse filter (talk | contribs) blocked...").--Jasper Deng (talk) 22:37, 21 November 2013 (UTC)
    The blocking component has a built in account "AdminBot" that undertakes the blocking. The change that JD is proposing requires the change to the underlying config, so the consensus is required for the bugzilla request to be actioned.  — billinghurst sDrewth 00:53, 22 November 2013 (UTC)

  Comment To note that if there is interest, this wiki can be part of the global abuse filters that are run by stewards. Basically there are a few filters that stewards set that identify spambots, and from meta we identify those and globally llock them straight away. Where there is a specific issue, it also allows stewards to see it, and if necessary, also undertake checkuser.  — billinghurst sDrewth 00:53, 22 November 2013 (UTC)

  •   Support --DangSunM (talk) 02:14, 22 November 2013 (UTC)
  •   Comment Can somebody explain what filter 5 is doing? I cannot read it! -- Lavallen (talk) 08:59, 22 November 2013 (UTC)
  •   Support Why not? --by ReviTalkCMG at 10:30, 22 November 2013 (UTC)
  •   Support original proposal with Rschen's caveat. TCN7JM 23:23, 22 November 2013 (UTC)
  •   Support With Rschen's and Billinghurst's recommentations. — ΛΧΣ21 06:13, 23 November 2013 (UTC)
  •   Oppose (Edited later at 04:10, 25 November 2013 (UTC):   Neutral to weak support if the message clearly warns the user that (s)he will be blocked before it actually does block. This message must be translated on a wiki like Wikidata.) The potential benefits are not worth the risk of discouraging new users. Prefer soft security when feasible. Unless you are receiving an unmanageable amount of spam, I don't see the need for this. I know resistance is futile. This will surely pass. If it does, you should check each filter very carefully and use the following rules:
    1. Any blocking filter that does not match any spam in a week must be disabled, unless there is a very good reason for keeping it (read: LTA, not spambot pattern).
    2. The logs of every blocking filter should be checked regularly for false positives. If a false positive is found, the filter must be immediately disabled and reviewed until it is fixed. No exceptions, even for users who "look like spammers".
    3. The message for blocking filters should be very clear about what happened, should not be discouraging at all, and must provide clear instructions for how to appeal the block and report the filter as incorrect.
Just my 2 cents. Also, global filters should not block. πr2 (t • c) 03:45, 25 November 2013 (UTC)

Block lengths for IPs

Here, we need to also decide on which block length to use. Account blocks will be indefinite (however, we do not plan to use a filter to block accounts anytime soon).--Jasper Deng (talk) 02:54, 28 November 2013 (UTC)

1 month

3 months

Default (indefinite)

Verified statements

Following up a discussion on the books task force, I would like to ask if there would be interest in discussing a system for verifying statements similar to the one used in some en-wp infoboxes (example: w:MPP+). It could be thought as a property automatically added by a gadget (verified by:username as string), or as part of the system (it could take longer). The meaning of such verification would be that a user has checked that statement and source match (not the case of many VIAF statements), and it would help focus efforts. Now there is no way of conveying that a statement has been verified, so we are checking once, twice, or more times the same statement without conveying that we have quality data.--Micru (talk) 12:52, 28 November 2013 (UTC)

Yes, absolutely.--Ymblanter (talk) 13:03, 28 November 2013 (UTC)
A 'checked by' property with a user name as the object would be ideal except that isn't one of the datatypes. String datatype instead? Filceolaire (talk) 14:59, 28 November 2013 (UTC)
Wikidata-link to the user name and the second line the date of checks.--Пробегающий (talk) 15:10, 28 November 2013 (UTC)
Yes, it can be done with a string that links to the userpage as we do with other properties. If someone makes a gadget, it can add "point in time" too. When or if the datatype "mediawiki user" is available, it can be moved easily. I have started the property proposal "checked by".--Micru (talk) 15:29, 28 November 2013 (UTC)
I like the idea, but I would prefer a software solution like in ns:Page in Wikisource. -- Lavallen (talk) 15:37, 28 November 2013 (UTC)
This is a cool idea. We will need some way to identify people anyway for Commons for example. However I am currently not sure if this should be a separate datatype (person) or just use URL. (URL because we will need to link to people on-wiki and off-wiki. --Lydia Pintscher (WMDE) (talk) 16:18, 28 November 2013 (UTC)
Urls are probably OK, but this does not allow to show information from Wikidata about the person from it, as we need internaly an item and we cannot make queries for datas outside Wikidata. If we want to store a name or an occupation, we will need an item, especially if we want to show these informations. Is it really different to create an item an associate the URL to this item ? TomT0m (talk) 17:06, 28 November 2013 (UTC)
Both would work. However keep in mind that for the same thing you'll probably at some point (latest when commons gets real) use this for people here on-wiki as well as outside. Imagine for example a creator property on Commons. Now you could create items for all of them but this seems a bit cumbersome to me. --Lydia Pintscher (WMDE) (talk) 22:42, 29 November 2013 (UTC)
@Lydia Pintscher (WMDE): To me, it's like saying a drop in the ocean is cumbersome :) If we can't manage that without overhead we have big problems imho. Just by seeing the over side, I see plenty of applications, a Wikimedian would not have to put its Babel boxes on any of its personal page, Interwiki in its accounts managed, and some users likes to have a clean personal page to demonstrate their techical skills, it can be a playground to learn Wikidata. We just should have a policy exactly as the user pages : the user is responsible for its Wikidata datas as he is for its personal page. TomT0m (talk) 11:29, 30 November 2013 (UTC)
Hi folks, I'm a strong supporter of this kind of initiatives (@Snipre: can confirm :)) What about storing the datas as statements or qualifier such as Verified by <Wikipedian> or source annotations ? TomT0m (talk) 17:06, 28 November 2013 (UTC)
I will play the role of the bad guy: not really a good thing because the problem exposed by @Micru: is not a problem if the source is correctly stated. This is in my opinion just a way to avoid sourcing correctly. The only situation where this can be useful is when entering statement about identifiers: but for the cases I know like the case of Chemspider, it is possible to source with stated in (P248) and retrieved (P813). For a example look at ethanol (Q153) for the statement about PubChem CID (P662). Snipre (talk) 18:24, 28 November 2013 (UTC)
Not only identifiers, also imported data, and imported sources. In the ideal world we would have all the sources at hand and we could check that the information corresponds with what the source says, but in reality we have many sources imported by users who didn't have access to the source themselves, so this can add extra confidence. "Date retrieved" doesn't add that extra quality seal because on the first sight on PubChem CID (P662) it cannot be seen who retrieved it, a bot parsing or cross-mapping millions of registers and maybe prone to errors or the careful @Snipre:? Additionally, if we had a visual indication that some check has been done (which I doubt it could be done relying only on p813), the effort could be focused on the ones that are still pending.--Micru (talk) 23:56, 28 November 2013 (UTC)
@@Micru: What you are proposing is a new concept: entering data with source without checking them. Until now the principle was that the contributor who enters data is "responsible" of the data he enters and checks them. With your new property you define a new concept: a data is true not when entered with its source but when confirmed by a second user. This the concept of the german wikipedia where each modification has to checked by a confirmed user to be displayed by the system (flagged revision).
I am not oppose to that new principle but this can't be done just with a new property: this is a radical change of the management of the contributions. To be efficient we need an interface which can do the job and a decision of the community. This adds a new level of administration work. Snipre (talk) 11:29, 29 November 2013 (UTC)
TBH, what worries me the most at the moment are bot-imported identifiers. We have plenty of them already and we should take steps to increase the trust on the data so that at least those identifiers can be used confidently *now* by Wikipedias. Why should they switch to Wikidata if the incentive is not high enough or even against it in some cases like the Chembox? The extra effort to validate that data doesn't worry much since we are already doing it, but without keeping track of those efforts. Think too that this effort can be outsourced to wikipedias, where users could have the option to click to add a "checked by" automatically here in Wikidata, thus spreading this info to other Wikipedias.
Even being hard to assess with no statistics (clicks per identifier, corrections, etc), I presume that the sum of the time spent by each individual user checking independently the pages linked is much greater than the time it would take one single user to check the statement and mark it with a gadget as "checked". An integrated flagging system would be ideal, however since that would take development resources and it is not a priority at the moment, I am not sure if there is much use in discussing it now... discussions too waste resources if from the beginning it is clear that they cannot lead to any useful outcome.--Micru (talk) 12:27, 29 November 2013 (UTC)
Just to recall Wikidata is not about Truth ... The only thing in Wikidata itself is the difference between a claim, a statement, and ranks. TomT0m (talk) 12:29, 29 November 2013 (UTC)
@Micru:. Instead of creating a new system why not use the existing system: if you check the identifiers this means you have a source so why not add the source used to check the identifier ?
If you have a CAS number or a PubChem ID why is it not possible to add the source used by you, me or someone else to check that the imported value is correct ? If I use a book, I can put the reference of the book, if I use a website, I can use the URL, if I use an online database, I can use an URL or the item of the database to specify the source use to check: no need of a new property "check by". And finally to measure the progress of the check we can juts delete the "imported from" property each time we check the value. For me the property "imported from" should disappear with the time and the use of this property should be restricted and banned in a near future. I really don't understand the need of a new tool as we have already everything. And in the case of the en:WP with their infobox and their system of "checked" this is just a bad way to avoid to source correctly their data.
And as I worked a little on identifiers, most of them can be extracted automatically from the database website because there are free and open data. We just have to organize the extraction. Snipre (talk) 00:29, 30 November 2013 (UTC)
@Snipre:: I agree that "imported from" should stop being used as a source property, but many people disagree, so most likely it will continue existing unless a distinction is made in Wikidata repo between sources and provenance. If at least the statements that only have "imported from" as a source were displayed as "0 sources" that would be IMHO an advance, since I wouldn't have to click on each source to make sure that "imported from", also known as the "incarnation of sources distrust", is not lurking there.
As for organizing data extraction I think at some point we'll have to document the mappings to external data as it is done now in dbpedia, but for that we would need a similar extraction framework to the one they have... I'm sure @Lydia Pintscher (WMDE): would be glad to hear more requests :P--Micru (talk) 18:39, 30 November 2013 (UTC)
It is quite justified to worry about bot runs. I have just been looking at a few entries which were created twice at the same Wikipedia by different bots. Elsewhere, there were entries which were correctly copied from a database twice (once in the wrong spelling, once in the right spelling). I agree that "imported from" should be deprecated. Personally, if I add a source, I almost invariably will have seen the source but in a Wikipedia anything is possible ... - Brya (talk) 18:01, 30 November 2013 (UTC)
Then it is logical to introduce a new property "responsible link" that will contain a pointer to it to import, but not on a global resource, as in the P143.--Пробегающий (talk) 15:03, 1 December 2013 (UTC)

P131 and sources

We are supposed to use the smallest administrative unit when we add located in the administrative territorial entity (P131), but that is not always easy to add a source for.

The smallest administrative units in Sweden are the parishes. But they will be deprecated any minute, therefor have I used municipalities instead here. Soon will a new division, made up by districts come instead. We do not know exactly how it will look like until 2016.

Until now, have the reports from Statistics Sweden I have been using, not told me anything about which parish the items are located inside. They have only told me about which municipality. Not a big problem, since parishes are deprecated today, as I told above. But how are we supposed to do when a source tells me something is located in a municipality, but the Property asks me to look for an even smaller administrative unit? P131 is often considered as a trivial piece of information that you do not need to add sources for, but in reality, I would disagree in many cases. To know which parish I live in, I have to look into the title (Q13629195), since the border between the parishes here looks like the borders in the area around Baarle-Hertog (Q244959). Maps are good to use, but they are not always reliable. -- Lavallen (talk) 09:10, 29 November 2013 (UTC)

If I got it right, we are waiting for the new administrative division. In this case, I would not any info which is imminent to be changed, and just wait until we can reliable source it.--Ymblanter (talk) 21:05, 29 November 2013 (UTC)
User:Lavallen: I think that would be a good case in which time qualifiers would be helpful. I wouldn't delete the statements working with parishes, but simply give them and end date. --Tobias1984 (talk) 17:18, 30 November 2013 (UTC)
As I said above, I do not have much sources for which place is located in which parish. I only find them in OSM, but only in areas where there are devoted OSM-users.
One problem is also that I do not know which enddate is valid. The parishes became defunct as a govermental geographic division as of 1999, without being replaced by districts until 2016. But they still exists as the smallest organisational division of the Lutheran church of Sweden. From 2000 the Lutheran church have been dramaticly reorganised, and maybe only a third of those parishes still exists. -- Lavallen (talk) 09:45, 1 December 2013 (UTC)

Items of "project pages" and "project pages" of Wikidata

Wikidata items collect also "project pages" as templates and categories of Wikipedia, Wikivoyage and Commons (at now available). What about Wikidata templates and categories? For example Template:Archive box (Q5828032) collects the interlinks of archive box templates of 71 Wikipedia and 2 Wikivoyage projects, but not our own template. In these cases could be useful add also Wikidata project pages? --Paperoastro (talk) 12:02, 1 December 2013 (UTC)

bugzilla:55570 and Wikidata:Contact_the_development_team/Archive/2013/10#Links to Wikidata pages in items. Matěj Suchánek (talk) 12:22, 1 December 2013 (UTC)
Thanks! --Paperoastro (talk) 14:56, 1 December 2013 (UTC)

Notability and Commons categories

Wikidata:Notability says that an entity is eligible for inclusion in Wikidata if it "contains at least one valid sitelink to a Wikipedia, Wikivoyage, or Wikimedia Commons page". The latter is ambiguous; does "page" encompass categories? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 16 November 2013 (UTC)

It should. Categories from WP and WV count. --Jakob (Scream about the things I've broken) 13:42, 16 November 2013 (UTC)
And from Commons? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 16 November 2013 (UTC)
In principle, they should count as well. The problem is that due to ongoing discussion on whether Commons categories should be connected with Wikipedia pages or Wikipedia categories, very few of them have items.--Ymblanter (talk) 13:55, 16 November 2013 (UTC)
Side note: I have just closed that discussion. I will make a section here shortly. John F. Lewis (talk) 14:23, 16 November 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Thank you. In that case, please could an admin undelete Q15136093? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:23, 16 November 2013 (UTC)

  Done, but I removed the biographical information and links to userpages. --Jakob (Scream about the things I've broken) 15:47, 16 November 2013 (UTC)
Thank you; but why the removals? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 16 November 2013 (UTC)
In fact, I now see you've deleted all the content, apart from the Commons link. Please restore it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:47, 16 November 2013 (UTC)
Well, this far, content related to users do not meet notability. With the inclusion of Commons, because of pages like this, it's obvious that Wikidata:Notability is outdated. Andy Mabbet is an Author of content in Commons and we, sooner or later, have to accept that pages like this is a part of Wikidata. Though, that does not mean that I want to see pages like this about moi. -- Lavallen (talk) 18:12, 16 November 2013 (UTC)
I don't know who Andy Mabbet is; but Andy Mabbett (me), is the subject of a Commons content category, not just a creator of content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:27, 16 November 2013 (UTC)
Pigsonthewing, the subject of the item is your images on commons, not you. --Jakob (Scream about the things I've broken) 18:18, 16 November 2013 (UTC)
Quite the contrary; the subject is (images - almost all created by other people - and an audio file, of) me. You will notice that, in the first part of this discussion, above, it is the unequivocal view of other editors that that warrants a Wikidata entry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:27, 16 November 2013 (UTC)
Jakob, you might want to notice that Wikimedia Commons usually has multiple categories for content about a subject and content created by a subject. As Andy pointed out, Commons:Category:Andy Mabbett features media files depicting Andy Mabbett, while Commons:Category:Images by Andy Mabbett features images created by Andy Mabbett. This is commons practice on Commons (e.g. Commons:Category:Allan Warren and Commons:Category:Photographs by Allan Warren) and should be reflected on Wikidata accordingly. Commons:Commons:Categories#Categorization_tips uses the example of Rembrandt: Commons:Category:Rembrandt is categorised in other categories describing Rembrandt, his works are in sub-categories like Commons:Paintings by Rembrandt‎. Admittedly there are a lot of categories packed with content that should be moved into sub-categories, yet this doesn't affect these categories' logic. Regards, Christoph Braun (talk) 10:44, 17 November 2013 (UTC)

Policy Changes

Hello all,

Per my second addendum to the Commons links RfC, Notability was changed to specifically state a Commons category no longer meets notability. Commons site links are now exclusively (probably wrong word) for Commons pages or galleries. I don't have much time to specifically elaborate on this at the moment so if someone else wishes to, please feel free. John F. Lewis (talk) 21:25, 18 November 2013 (UTC)

Other than the single reference in your closing comment, I don't see any mention of notability in that discussion. Can you point it out, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 20 November 2013 (UTC)
By my interpretation of WD:N, Commons category links are not allowed at all, which, from what I can tell, is not supported by any option on Wikidata:Requests for comment/Commons links. The Anonymouse (talk) 17:04, 20 November 2013 (UTC)
That is the recent change, to which I refer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:20, 21 November 2013 (UTC)
OK, I think I understand now. Because option III will be the ultimate result, Commons category links should not be used until option III is available.
By the way, what is the development team's opinion on this matter (since it would require significant development to accomplish)? I though John F. Lewis said he talked to Lydia about this, but I'm not exactly sure. The Anonymouse (talk) 17:09, 21 November 2013 (UTC)
That doesn't match not my understanding of any of the options discussed in the RfC, and certainly not the option approved by the closing admin as an interim solution. However I can't claim to understand his changes to WD:N, including a change made since the above posts.
The development team's opinion on option III was explained at Wikidata:Contact the development team/Archive/2013/11#merging_items_for_Categories_with_items_for_the_Category_topic (unfortunately not until late during the RfC). Briefly, they think option III "does not seem impossible but would need a lot more investigation" and that given other priorities, this won't happen for the "forseeable future". --Avenue (talk) 20:16, 28 November 2013 (UTC)

Nudge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:16, 26 November 2013 (UTC)

This has been discussed further elsewhere, most recently at Wikidata talk:Requests for comment/Commons links#Review of closure. --Avenue (talk) 11:36, 27 November 2013 (UTC)
Thank you. I don't see any consensus there, for the recent change to our notability policy; nor evidence of such consensus being reached in discussion elsewhere. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:35, 2 December 2013 (UTC)

Interwiki section links

Hi. I ran into the problem of Interwiki #section links not working, and eventually found this discussion: Wikidata:Interwiki conflicts#Interwikis where there is no one-to-one match.

One option mentioned there (by User:Littledogboy) seems interesting, and I would like to discuss it further: Creating a redirect at the foreign language that only has a subsection mention.

E.g. The English article en:List of classical music composers by era (a graphical timeline) interwiki-links to the German subsection de:Komponist#Komponisten (Klassik) - Grafische Übersicht (a graphical timeline). Could/should I create a redirect at de:Komponisten (Klassik) - Grafische Übersicht (or something), so that the German content can be indexed in Wikidata?

What use-cases, or policies/guidelines, would conflict with this solution? (It's new territory for me, so I might be overlooking something obvious).

FAQ: Please, whatever the solution we come out with, add something to Help:FAQ (and/or the top of Wikidata:Interwiki conflicts), because it took a while for me to uncover, and is probably a common problem. Thanks! Quiddity (talk) 18:20, 29 November 2013 (UTC)

1. The software do not fully support sitelinks to redirects yet. (You have to temporary make it a "real" article first to be able to create the sitelink.)
2. The information in the Wikidata-item will not be linked to the de-article "Komponist", only to the redirect, where templates and modules cannot be added.
3. This solution is maybe not backward-compatible with the future solution the developers will create.
It the purpose only is to create interwiki, I would recomend you to wait. -- Lavallen (talk) 19:01, 29 November 2013 (UTC)
I agree with Lavallen, too. It's one of the biggest technical issues we have currently. --Ricordisamoa 19:34, 29 November 2013 (UTC)
Thanks for the insights. Could someone add 1 sentence explaining that, at the top of Wikidata:Interwiki conflicts and/or the bottom of Help:FAQ? Please and thank you! Quiddity (talk) 18:42, 30 November 2013 (UTC)
I've added two new entries at the bottom of Help:FAQ; Tweak as needed. Wikidata:Interwiki conflicts/Header is protected, so I can't boldly edit that in any way. Quiddity (talk) 05:17, 2 December 2013 (UTC)

File replacements and global usage

I struck an issue that there was a file in use at roWP that was being replaced from gif to png at Commons. After large amounts of wading through foreign language templates (always a pain), I found that the image was called at roWP through a property call to WD. So, okay, I have updated WD to the change the image, however this sort of issue is going to become worse and worse. The standard file replacement processes at Commons are not going to work, and there is no ready identifier at Commons to direct users that they need to look at WD. We clearly need to have a means that a file reference at WD shows up somehow, I am just thinking that surely that it could be referenced in Global Usage, eg. Special:GlobalUsage/Slavutich_prapor.png has a WD linkage somehow.  — billinghurst sDrewth 01:45, 1 December 2013 (UTC)

@Lydia Pintscher (WMDE): This sounds like something that needs to be handled from a technical side. --Izno (talk) 02:49, 1 December 2013 (UTC)
Yes indeed. We have bugzilla:46358 for that which could use some input from you. --Lydia Pintscher (WMDE) (talk) 08:31, 1 December 2013 (UTC)
@billinghurst: For the future, for techy sounding problems, you should probably leave a comment to WD:Contact the development team. --Izno (talk) 02:49, 1 December 2013 (UTC)
A soultion on the Commons end I can imagine is to update CommonsDelinker and other file replacing tools like Fastily's tool to also replace files in WD items. I have no idea how easy this is.--Ymblanter (talk) 09:18, 1 December 2013 (UTC)
From the Commons side there it knows nothing about WD, except for the rare times we physically link an image. So until the linkage issue is resolved, we cannot even talk to Commons about how we handle replacements. Even then there will be issues as it will be specific cases where it occurs and where it needs fixing. There will be a significant discussion at that time as there is complexity and xwiki progress in play here.  — billinghurst sDrewth 10:22, 1 December 2013 (UTC)
As I see it, adding an image claim should be just like adding an image to a normal page: All the relevant tables should be updated. If that's the case, it's not that hard for delinker to do it's job. The hard part is implementing the first part: ImagePage is a scary beast and it will bite!
On a side note, I would love to see a thumbnail here at Wikidata instead of the file title. Do we already have a bug for that? Multichill (talk) 22:13, 1 December 2013 (UTC)
Would having a thumbnail resolve the issue anyway? As it would be logged as an included image, and the system would then list it. Even if it isn't replaced, it is a step forward knowing that it is listed.  — billinghurst sDrewth 02:08, 2 December 2013 (UTC)
I think we absolutely need thumbnails.--Ymblanter (talk) 08:20, 2 December 2013 (UTC)
I think there's a script lying around for that. --Izno (talk) 23:05, 1 December 2013 (UTC)
There is bugzilla:44727 for showing thumbnails. --Lydia Pintscher (WMDE) (talk) 11:06, 2 December 2013 (UTC)
Unfortunately we don't currently have the capacity to mentor this so I fear no. --Lydia Pintscher (WMDE) (talk) 11:06, 2 December 2013 (UTC)

Litterall interpretation of Administrative unit in P131

I would like to have some feedback to this. -- Lavallen (talk) 07:11, 2 December 2013 (UTC)

Dates in Julian / Gregorian calendar

I want to refresh and extend Denny's address at User talk:Kizar#Dates in Julian / Gregorian calendar. Here are some more bots that have erroneously inserted dates in Julian calendar to the (proleptic Gregorian) data type properties:

Since I have found them by unsystematic experimenting there are probably more false dates by other bots or human users. How can we detect and correct them? I am quite sure that there are too much of them for a quick manual correction. Is there an other possibility than rivising all dates before 1923 when Greece adopted the Gregorian calendar? And have all the bots stopped these edits yet? (Dexbot at least has., ViscoBot does not work ATM) Best, --Marsupium (talk) 17:56, 29 November 2013 (UTC), edited 17:23, 3 December 2013 (UTC)

[Avoiding archiving. --Marsupium (talk) 17:23, 3 December 2013 (UTC)]

calendarmodel display

BTW: I would appreciate if the bots did not set a value for the calendarmodel displayed other than "auto" or even removed those yet setted. I think the indication of the display is perhaps not useful at all. The way some bots use it is for sure meaningless, for example in the statement <Leo I (Q183776)> date of death (P570) <+00000000474-01-18T00:00:00ZGregorian> added by User:KLBot2. The indication of the Gregorian display for a date nobody has given in Gregorian calendar, neither when Leo I (Q183776) lived, nor today, seems completely useless to me. --Marsupium (talk) 17:56, 29 November 2013 (UTC)

Idea regarding missing descriptions

There are a lot of items without descriptions right now, and differentiating items with the same label is a tedious task. Is it possible to use the value of instance of (P31) as a temporary description for items until a real description is filled in for those items? Those temporary descriptions should be shown in search results and in the claim-adding interface. Can this be done with a script or otherwise? --Wylve (talk) 16:07, 1 December 2013 (UTC)

I think you're looking for this post by Magnus Manske. :) --Izno (talk) 16:54, 1 December 2013 (UTC)
Didn't know this existed, thanks! --Wylve (talk) 17:20, 1 December 2013 (UTC)
My suggestion would be to put the first sentence in the article into the description. If there isn't an article in that language then instance of could be good. The one worry about adding these is that it will be more difficult to identify items with autodescriptions than items with no descriptions. Filceolaire (talk) 23:32, 1 December 2013 (UTC)
This is technically disallowed per the licensing incongruities. Information licensed under cc-by is not compatible with cc-0. --Izno (talk) 23:48, 1 December 2013 (UTC)
However, my label collector script has this kind of functionality, combined with the one from Magnus' autodesc. If you edit an item with it, it tries to extract a meaningful description from the linked article's introduction (like "Xyz is a British car manufacturer that has been founded 1921" becomes "British car manufacturer"). If that fails, the whole first sentence is proposed. And if there is no article linked, it tries to generate a description from the "instance of" statement among others. You have the possibility to edit these proposals to convert them to real language ;) without having to copy and paste, then save it, so everybody can make use of these descriptions without the need to have some script installed. I didn't get around to work on it recently, so there's quite some things that I have to fix and adjust soon, but it basically works. Feedback welcome. --YMS (talk) 09:39, 2 December 2013 (UTC)
@YMS, LabelCollector is working very well, though not perfect. Used it for weeks, in conjunction with Babel, for filling descriptions and aliases in 4 languages. Nice tool indeed. - LaddΩ chat ;) 01:39, 3 December 2013 (UTC)

Durian

Dear all, I noted that there are two link pages for interwiki for the same subject. I do not know how to combine these. I mean

Thank for your help solving this (I do not know how) and keep up the tremendously good work! Ellywa (talk) 14:19, 3 December 2013 (UTC)

I don't think they are the same: durian (Q134185) is for the fruit, while Durio zibethinus (Q1135236) is for the species of the plant. The Anonymouse (talk) 17:30, 3 December 2013 (UTC)

Looking for Wikidata folk w/genealogy interest

I'm a very active contributor on the single-tree genealogy site WeRelate. WeRelate has a number of namespaces for different types of information, including "PERSON" and "PLACE". Over the past several years, the site has developed about 76,000 correspondences between our "PLACE" pages and English Wikipedia place pages. We've also developed a bit over 22,000 correspondences for PERSON pages and English Wikipedia biography pages.

My current interest is in ways to turn our WeRelate <-> English Wikipedia correspondences into WeRelate <-> Wikidata. Among other things, this could be a way for WeRelate to start to move beyond our English bias and make our content more accessible to other language speakers.

I would appreciate hearing from interested parties over here, who are better positioned to know what is appropriate or reasonable from the Wikidata side of things.

Thanks! --Jrm03063 (talk) 14:39, 3 December 2013 (UTC)

Top of the subclass tree

What should go at the top of the subclass tree? I've been using Q15244161, which in retrospect might not be the best option. User:Emw replaced it with no value on one page, but that seems to break Template:tree, so that option is no good unless that bug is fixed. Should we just not have anything at the top? Follow-up question: If we don't have any item at the top, what items should we allow as property constraints of subclass of (P279)? As of now, the items at the top of the subclass trees appear to be entity (Q35120), space (Q107), mind (Q450), principle (Q211364), and physical phenomenon (Q15257329). That list covers everything I can think of. --Arctic.gnome (talk) 04:43, 1 December 2013 (UTC)

  • I don't think it is for us to decide how the upper parts of the subclass of (P279)-tree looks like. We just have to add the values that different sources give. Probably different sources will generate different trees that might even contradict each other. Another problem is that we might end up having items like "Universe", where even philosophers can't agree on the exact meaning. This will still take a lot of work and thought on our part, on how to model that. --Tobias1984 (talk) 12:42, 1 December 2013 (UTC)
I don't think we should punt on this. Without a sound and stable upper ontology, subclass of (P279) would be drastically less useful than it should be. As I explain below, entity (Q35120) is the standard root node for major, broad ontologies. Wikidata is in the same boat: many contributors are interested in their specific domains, but at the end of the day these domains must be coherent to each other. Having a consensus root node for subclass of (P279) is a basic requirement for that. Emw (talk) 13:46, 1 December 2013 (UTC)

  • I've been cultivating the top of the subclass tree since subclass of (P279) was created in March, but I've never given a decent explanation of why I've been using entity (Q35120) (alias: thing) as the root node of Wikidata's type hierarchy. The reason is convention. General-purpose ontologies typically root their taxonomic hierarchy at an item labeled "Entity" or "Thing". (The Thing (Q11039766) is a Wikipedia disambiguation page and the corresponding Wikipedia page for entity (Q35120) describes the concept in rough ontological terms, so I went with the latter and made "thing" an alias of it.) Examples of ontologies rooted at such an item are any ontologies built with OWL, SUMO, Cyc, and upper ontologies presented in widely-used textbooks like Artificial Intelligence: A Modern Approach, 3rd edition (see figure 12.1 on page 438).
Shared vocabulary and interoperability are important, so since other major ontologies use it there, I think keeping entity (Q35120) as the root node of our class hierarchy makes sense. The basic idea of a root class is that it is something that everything else can be said to be a more specific type of. This criterion easily disqualifies space (Q107), mind (Q450), principle (Q211364) and physical phenomenon (Q15257329) as root nodes: one can imagine an item that is not a subclass of each. On the other hand, it is clear that 'space', 'mind', 'principle' and 'physical phenomenon' are all entities, i.e. things.
(To answer Arctic's operational questions: "Should we just not have anything at the top?" With the possible exception discussed below, all items should be linked to entity (Q35120) by either P279 or P31. entity (Q35120) should have no P279 claims, nor any P31 claims. "What items should we allow as property constraints of subclass of (P279)?" Only entity (Q35120), with the possible exception discussed below, per the rationale in this post.)
While I think having "entity" and not something like "mind" as a general-purpose root node is uncontroversial, there are important open questions about related aspects of the top of our so-called subclass tree. I think the most pressing question is how we should root fictional entities. One of the soft conclusions of that linked discussion is that we would use fictional entity (Q14897293) as the root for things in fictional universes (e.g. the Harry Potter universe, the Star Wars universe). In this case, Wikidata would have two hierarchies: one for things that exist in the real universe, and one for things that exist in any non-real universes. I encourage anyone interested in this to read through the previous discussion on fictional entities. Emw (talk) 13:25, 1 December 2013 (UTC)
There is one more used root : Battle of Dresden (Q17594), that has been used to class classes (arguably this is maybe not the right item as this one states the classes of set theory). Also arguably fictional entities are also things, so maybe its just a subgraph on is own, and we keep our root. TomT0m (talk)
Totally agree with Emw's points. entity (Q35120)/conceptual item/thing no matter how you call should be the root and has no value for subclass of (P279). The very deep types including all space (Q107), principle (Q211364), and physical phenomenon (Q15257329) can occupy the level one, as direct subclass of entity (Q35120). These level one nodes can further be regarded as root node of different dimension of understanding: space (Q107) is for location, principle (Q211364) is for theory basis, mind (Q450) I don't think is a valid deep type since it is just kind of "process" (I don't know where is the class for universal process), physical phenomenon (Q15257329) in fact should also be subclass of "process", but sure mind (Q450) should at the same time be a subclass of "body" I list below. More types that should be in level one I think should include "process (physical, imaginary, mental)" and "body (something that can have possessionary relations with real objects, can be physical, abstract(legal, conceptual, fictional...))"...well, may be already enough.
For the fictional entity problem, I suggest we add a quantifier "in the setting of" for such kind of "facts". It happens that many fictional person are not purely fictional, then for the statements that it is fictional, we can add this quantifier. This quantifier also help to solve conflicts between contradictory theories. So the value of "in the setting of" can be filled with either a fictional work (drama, book, etc) or a theory...well but personally I think further split this quantifier property into "according to theory" and "according to setting of (fiction)" is more reliable and clear. But this increase difficulties to filter what statement is always true (need to check 2 quantifier properties instead of one). 金亦天 (talk) 14:37, 1 December 2013 (UTC)
It's an appropriate time to start thinking about this, but I don't think we should attempt to define the near-root nodes of the subclass tree right here in Project chat. An RFC would be a more better venue to develop proposals on that. Setting entity (Q35120) as the root node instead of 'space', 'mind', etc. is a relative no-brainer. The harder part is determining what the rest of the upper ontology looks like. I think we should consider importing an existing upper ontology like UMBEL, BFO or SUMO, and make adaptations if needed. What I would strongly advise against is creating an upper ontology of our own without robust justification. Issues in upper ontology have been an active area of research and development for a long time, and quickly creating a home-brew upper ontology would virtually guarantee significant problems in a Wikidata type hierarchy. Emw (talk) 16:57, 1 December 2013 (UTC)
An option is to import all of these upper level ontologies so HighLevelClass is 'subclass of:foo' 'stated in:UpperOntology1' and is 'subclass of:Bar' 'stated in:UpperOntology2'. Of course the root items for each of these upper ontologies will then get the property 'subclass of:Upper Ontology Root Items' ! That's assuming we have the right to reuse these upper ontologies. Last time this came up I tried to get a look at the upper level ontologies for these but as far as I could see they were all behind paywalls. The links posted by Emw just bring me to search pages. Does anyone have a link to the actual UMBEL, BFO and SUMO upper ontologies? What are their licensing terms? Filceolaire (talk) 00:05, 2 December 2013 (UTC)
Yes the upper ontology setting should have a good support (page with links to UMBEL/BFO/...). But at the same time I refuse to copy it from BFO. I think BFO is so beautiful, but it just inserts too many uncommon terms. If we want our data to be easily readable by the public, then we should try the best not to create extra items just for building an ontology without strong reason. I think there are things need to be clarified: 1) How volatile will the upper ontology be. 2) From what level should the subclass structure no longer a tree and become a DAG.
For the first point, since people's perception of the world is not constant, it may change according to cultural shift. then it is not reasonable to assume the upper ontology can remain unchanged forever. We should always be prepared for any change while keep an eye on the compatibility issue before/after each change.
For the second point, many entities in fact are not just one entity. As the example "mind" I described, some people treat it as continuent, some people treat it as occurrent (in the BFO sense). We should prepare to handle this kind of multiple routes going towards the root, but we can suppress it up to certain levels of the upper ontology. The classification will not result in a tree unless we do everything like splitting a country item into a list of items: spatial/political/organizational/cultural/...金亦天 (talk) 01:44, 2 December 2013 (UTC)
Per Filceolaire's request:
Upper ontologies
Name Official site Ontology Source code repository License Overview Detailed publication
BFO http://www.ifomis.org/bfo bfo-1.1.owl http://code.google.com/p/bfo/source/list ? Overview Ontology for the Twenty First Century: An Introduction with Recommendations
UMBEL http://www.umbel.org/ umbel.n3 https://github.com/structureddynamics/UMBEL/blob/master/ Creative Commons Attribution 3.0 Reference Concept Ontology and Vocabulary UMBEL Specification
SUMO http://www.ontologyportal.org/ SUMO.owl http://sigmakee.cvs.sourceforge.net/sigmakee/KBs/ "SUMO is free and owned by the IEEE. The ontologies that extend SUMO are available under GNU General Public License." Suggested Upper Merged Ontology (SUMO) Towards a Standard Upper Ontology
Emw (talk) 03:08, 2 December 2013 (UTC)
Thank you Emw. That will provide some food for thought. Filceolaire (talk) 07:28, 2 December 2013 (UTC)
  • If "entity" was the root, what would be the level-1 item for physical things? That throne has been fought over by matter (Q35758), material (Q214609), object (Q488383), physical system (Q1454986), and a few others that aren't linked anymore. As for fictional entities, I would be okay with giving them a second root. However, we should note that the fiction tree should be a lot shorter; "fictional city" can be right bellow "fictional location" which is right bellow "fictional entity", without all of the other branches that a real-world city would have. The RFC is probably a good idea; is there anything we have to hash out before starting an official community-wide discussion? --Arctic.gnome (talk) 03:13, 2 December 2013 (UTC)
Good point. My gut reaction is to create a second top level (or third if fictional entity gets its own) for Wikimedia organizational pages. --Arctic.gnome (talk) 19:24, 2 December 2013 (UTC)
This is a recurrent question; see e.g. Inconsistency?. I am against using P31 and P279 for classifying internal details of Wikimedia projects like templates, category pages, etc. Not only is it navel-gazing upon navel-gazing, it also introduces a basic inconsistency into the subclass tree. More details in the linked discussion. Emw (talk) 04:36, 3 December 2013 (UTC)
  • Something else to think about: The upper levels of an ontology are not that useful in practice. Most queries are related to lower levels. Putting an upper level item in a query will result in far to many hits to be useful for any practical purpose.
On the other hand we are the type of people who spend their free time creating a data model of all knowledge. There is no way we will leave the top level incomplete. Filceolaire (talk) 07:28, 2 December 2013 (UTC)
  • True, though it will probably help organize the mid-level ontologies and it will help us avoid property constraint violations. Also, I can see some cases where you would use the upper-levels. Off the top of my head, I might want to find items that span two countries, but I don't care about treaties and other political stuff, so I limit my search to physical objects. --Arctic.gnome (talk) 19:24, 2 December 2013 (UTC)
You never know what exact categorization you will need when you do a traversal. That's the reason why I suggest we should allow multiple "settings". In previous reply I use quantifier to illustrate that, but it is not good in fact. We need a new structure for separating "settings". Once settings are available, users can easily limit the scope of information by selecting the setting that concerns them. This new structure also provides long term solution to theoretical conflicts and also Wikidata to become a more ductile and universal platform. 金亦天 (talk) 02:46, 3 December 2013 (UTC)
Some of the flexibility needed for that is meta-modeling, sayed differently class classification. You can then filter the class tree by the (upper ontology/type of class you want/ ...) by searching the relevant or chosen classes / subclass relations you want to, and its already possible and used within Wikidata. TomT0m (talk) 11:41, 3 December 2013 (UTC)
What I mean is there are many different schools of knowledge, e.g. some philosophers think there is no real object in this world. When you fit the class structure using one school's knowledge, then the other school will not be happy. The only way to allow people from different schools to be happy is to separate "settings".金亦天 (talk) 01:02, 4 December 2013 (UTC)

Upper ontologies

BFO

BFO 1.1

TODO

BFO 2.0 (draft)

The BFO 2.0 ontology is currently in development. The reference document for the draft below is here: http://bfo.googlecode.com/svn/releases/2012-07-20-graz/BFO2-Reference-for-html.htm. Wondering what "continuant" and "occurant" are, and how they're different? See The dichotomy of continuant and occurrent.

From [https://bfo.googlecode.com/svn/trunk/docs/Introduction%20to%20BFO2%20OWL%20Ruttenberg%20ICBO%202012.pdf Introduction to BFO 2 OWL Implementation], page 9:

(TODO: Check reference document links for examples from BFO of each class.)

SUMO

From Towards a Standard Upper Ontology (page 4):

Just so I understand this one, I've tried sorting some mid-ontology classes; is this where they would go (maybe with some levels in between)?

  • people and animals => lifeform => ContinuousObject
  • emotions => biological process => process
This particular example -- emotions => biological process => process -- is an interesting example. biological process (Q2996394) is actually a core class in Gene Ontology (GO), one of the most widely-used ontologies in biology (see http://www.geneontology.org/GO.doc.shtml#biological_process). And GO is part of the Open Biomedical Ontologies (OBO), which is maintained at a high level by the folks who develop BFO (a separate upper ontology under discussion here; see above). Several people have suggested that we can support multiple ontology systems, which seems theoretically possible although I'm not convinced it's practically workable. Mapping the BFO 'biological process' to SUMO seems like it would be a good starting point for this. Emw (talk) 04:54, 3 December 2013 (UTC)
So maybe the way to proceed is to pick an upper ontology we like (or combination thereof), and then try to fit a few topic-specific ontologies into it to see whether they have a logical place to go or whether they have to be split up. For my own interests, I'd like to try to fit a politics and law ontology into these. As of now classes like political territorial entity (Q1048835), country (Q6256), state (Q7275), and polity (Q1063239) are a bit of a mess, all linking to each other and falling under locations, human behaviours, organizations, and legal fictions all at once. --Arctic.gnome (talk) 05:35, 3 December 2013 (UTC)
  • laws and other human rules => proposition
  • countries and natural geographic areas => place => CorpuscularObject
  • a song => ??? (maybe music => process?)
--Arctic.gnome (talk) 19:17, 2 December 2013 (UTC)

UMBEL

TODO

Wikidata

For reference, here are the three levels below entity (Q35120) as they are now. Feel free to update as needed.

About Wikidata and upper ontologies

Wikidata has already a lot of items, in particular there is most probably articles about each of the concepts used in those ontologies (to be verified). This implies that we already probably express relations like subclass / instance of about all these concepts for all upper ontologies.

So ... What would exactly mean adopting an upper ontology ? If we have those items, we can (and should, to express the full range of relationships beetween these concepts) use them to build an equivalent of all upper ontologies. So we can annotate the class and relationships as sources or as classes classification ... is it important do actually do more ? I'm not sure. TomT0m (talk) 18:52, 2 December 2013 (UTC)

Release dates for media entries

I was checking a few popular albums/movies/etc and noticed there is no statement for the release date. Is this something the project decided against adding or has no one just made an effort to do so? Thanks MusikAnimal (talk) 02:50, 2 December 2013 (UTC)

We use this property for that information publication date (P577). It is very likely that there are still thousands of artworks that are still missing this property. If you want to add it to a few of your favorite artworks, you can just look for an appropriate source and add the information by hand. --Tobias1984 (talk) 09:11, 2 December 2013 (UTC)
Could you give me an example of an album that contains this property? I tried hugely popular albums like The Beatles' Abbey Road, Sgt. Pepper's Lonely Hearts Club Band, Radiohead's Pablo Honey, etc... thanks MusikAnimal (talk) 16:34, 2 December 2013 (UTC)
This should be helpful: http://208.80.153.172/wdq/?q=claim[31:482994]_AND_claim[577] (you need to copy & paste the link). The reason you didn't fin anything is that there are only 167 albums with that information as opposed to the 78634 albums with (instance of = album) on Wikidata. If you can find a suitable source and a bot operator willing to help you, the information could be transferred in a matter of hours (Wikidata:Bot requests). --Tobias1984 (talk) 16:53, 2 December 2013 (UTC)
On an aside, 80k albums is a lot for an artform that has only existed for a century (and I hesitate to call anything before the 50s an album)! --Izno (talk) 23:34, 2 December 2013 (UTC)
I regularly used it for albums and films as a qualifier to the instance. I also add appropriate "preceding" and "succeeding" as qualifiers where appropriate. So have a poke at some my contributions.  — billinghurst sDrewth 12:42, 3 December 2013 (UTC)
Using a bot to transfer this data sounds like a great idea... by "source" do you mean a single source or one per item? I'm new to Wikidata, I figured we could just transfer release dates from the infoboxes on Wikipedia, at least that would be the easiest way to do it. You could alternatively go by a reliable external source, such as allmusic.com. The issue is that their API is not free, so the bot would have to scrape pages... doesn't sound good. MusikAnimal (talk) 21:06, 3 December 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Transferring the data from the infoboxes is also possible, but some people feel that that is not an appropriate source or in case a Wikipedia uses the data a case of circular sourcing. I think if you provide a reasonable sourcing strategy with the bot task then an import should be allowed. But that means that a few people have to add sources to the imported information by hand, which will take a couple of months of dedicated fact checking :) --Tobias1984 (talk) 07:17, 4 December 2013 (UTC)

My thoughts are that having something there is better than nothing, and should it be wrong, it can be corrected when noticed. The English Wikipedia is pretty well monitored, I'd argue well over the majority of the release dates will be accurate. I'm not sure about the circular sourcing... on Wikipedia it's simply plain text where you enter the release date. Most editors aren't even aware of Wikidata, and it also being a Wikiproject I would imagine it should not be considered a source by itself. Also wanted to point out if we do agree to use Wikipedia infoboxes, we should probably pull the data from Dbpedia, a project that already has done the hard work of scraping the wikitext into a tangible data format.
If you feel Wikipedia/Dbpedia is simply not going to work, then maybe, just maybe we could do a drive to raise money to do a one-time import of the release dates (and other valuable information) from Rovi, which is widely considered reliable. I can do more research to find out just how much it would cost, if you think it's worth it. It could be pretty cheap! MusikAnimal (talk) 16:24, 4 December 2013 (UTC)

Adminbot

hi, I requested for approval for a task about merging empty items. It is what exactly the bot does: "the bot goes through items without sitelink and check their history pages and if there is just one site link (that has been removed) checks the site link and if the site link exists in another item, merges these two, at first phase I'll merge only items that the empty item has no statement at all. How the bot merges? I give you an example, check out these edits [1] (the bot merges in lower Q-id) [2] and edits bakclinks items " so after merging them it need sto delete one of them and I used my account to delete them but per WD:Bots I need to request for approval, adminship, etc. I want to ask your opinion about this issue (it's pretty important because we have 740K items without sitelink)Amir (talk) 18:29, 3 December 2013 (UTC)

Are there 740000 items matching the criterion you mentioned ("just one site link (that has been removed)") or just 740000 items with no sitelink (and so probably most of them never had one, like all these Chinese administrative units, which nonetheless are valid items that are linked to each other)? In the first case, maybe we really need an adminbot to get around with this (as it would mean every single admin would have to delete more than 8000 items, which is far more than the very most of us ever has deleted). In the latter case, I'd better like it if your bot just compiles lists of the items that in its eyes really match the criteria to be deleted so they can be handled manually. --YMS (talk) 08:06, 4 December 2013 (UTC)
between 50K-100K items meet the criterion. so still we need a lots of admins to get through that list. Amir (talk) 15:04, 4 December 2013 (UTC)

Property for "official title" required

[I know that this is not the right place to request it, however, the secret handshake and arcane knowledge of battling through property requests just defeats my patience and willingness to battle on (something that project really needs to consider to make it easier for real people, not WD experts). Anyway ...] (relocate this as appropriate, lose my pomposity if you like)

We need a text property for (official title|official name|whatever), be it position, person or country, or whatever it may be. We have had a recent change of a country from the simple 'name' to its fuller political name. While this is correct, it is less than helpful for its use in typeahead, and once that becomes the (rule|expectation), it will be enforced across the board by those who like (formalistic|blackletter) approach. As a means to keep things simple for input, and to make available as a property, it is my belief that this property can have value in creation.  — billinghurst sDrewth 01:29, 4 December 2013 (UTC)

That property is already pending: Wikidata:Property_proposal/Pending/3#Official_name_.2F_Name_.2F_Nom_.2F You will have to be patient until the monolingual datatype is available. If you need help with any additional property proposals just leave me a message on my talk page. --Tobias1984 (talk) 07:24, 4 December 2013 (UTC)

script for adding identical labels to many languages?

I edit often items, mainly disambiguations, which should have identical labels in all roman script languages. It is a very boring to add each of the language labels by hand, see for example history of Blanca (Q1172727) and history of Blanka (Q4925148). I use LabelLister for this, but it often feels slow with all this copy and paste, clicking and waiting for save.

Is there a helpful script for this task or can someone write a script? I think of something where i can add a label to a predefined set of languages with only one click. Already existing labels should not be overwritten. And maybe the labels could also be added as aliases to ja, ru, zh and other non-latin languages. Holger1959 (talk) 18:55, 1 December 2013 (UTC)

Holger, you are right. I support this request. When I am working on disambiguations, it is the slowest part of the editing, and also you have to save more than one edit what makes the history longer. Matěj Suchánek (talk) 19:47, 1 December 2013 (UTC)
User:Jitrixis/nameGuzzler.js Ljubinka (talk) 20:28, 1 December 2013 (UTC)
My label collector script also proposes a label for all existing languages at least for disambiguation pages and persons, if all existing labels of one script are the same. I was going to extend this to all items if there are at least x identical labels, but I didn't get around to work on it recently. --YMS (talk) 09:31, 2 December 2013 (UTC)

Thank you for the help! NameGuzzler did not works for me. There was nothing changed in the interface. My computer was off in between, so the caches should be cleared, but even today i didn't see where I should click something (nothing changed). Maybe i made something wrong here [8] or its a conflict with User:Magnus Manske/wikidata_useful.js?
Now I try out the label collector. Holger1959 (talk) 20:24, 2 December 2013 (UTC)

With label collector now I see a link in the left sidebar but when i click on it for example on Leonie (Q1819464) then the page reloads but nothing else changes. Holger1959 (talk) 20:31, 2 December 2013 (UTC)

Does the JavaScript console of your browser (usually to be opened with Ctrl+Shift+I or J) say anything? Or, to shorten things up, can you open https://tools.wmflabs.org/eagleeye/xregexp-all-min.js? Currently, the script needs access to this, and some browsers silently fail if there are some issues with Wikimedia Labs' certificate. --YMS (talk) 22:32, 2 December 2013 (UTC)
Can't open this page. I waited some minutes, it doesn't load. Did not have any problems with javascript on Wikimedia before. Holger1959 (talk) 22:20, 4 December 2013 (UTC)

wondering about Wikimedia language code handling

Hi! Q6293548 might be the only Wikidata page where all WMF language codes are present. I was chasing a bug in a Wikidata related Javascript where the language recognition did not work.
To understand the issue you may see thet language codes as "roa-rup" and "zh-yue" are using a MINUS in the language code (and in the WMF subdomain) but an UNDERSCORE in the internal "foo_barwiki" coding. At the Special:RecentChanges page mentioned above you will see "roa_rupwiki" and "zh_yuewiki".
Babel templates are using the MINUS and variants using the UNDERSCORE will fail as you can see on my userpage.
questions:

  1. Is this behavior known? / intended?
  2. The script User:Yair rand/WikidataInfo.js will fail at languages using a MINUS in the subdomain. The description and the aliases are not recognized. If you use the Javascript at roa-rup and if you go to roa-rup:Wikipedia page you will see:
    1. Wikidata: (No label) (Q52), no description given
    2. Aliases: None

Please test whatever Javascript at such Wikipedias.
Please test whatever Javascript also at WMF projects where the Wikimedia language code differs from the language code defined in international specifications. Example: als versus gws.
Regards לערי ריינהארט (talk) 22:00, 4 December 2013 (UTC)

I mentioned this some weeks before: At the top of the Wikidata page is an icon which opens the Select Language dialog. You can neither select roa-rup nor zh-yue there. If you type zh in the input field you will have a mouse hover help only for the main Chinese WMF subdomain. The help for all other variants is missing. לערי ריינהארט (talk) 22:25, 4 December 2013 (UTC)
(edit conflict) Hm, the wgContentLanguage on the roa-rup and zh-yue wikis are "rup" and "yue" respectively, but the labels and descriptions on Wikidata don't use consistent codes. Some labels use "yue" and some use "zh-yue". I don't know if there's any particular reason for this. Perhaps this issue should be brought to the Wikidata developers. --Yair rand (talk) 22:30, 4 December 2013 (UTC)

Wiktionary, similar to languages

So the language iw links are nicely provided in the lefthand margin of my en:wiki page. I wonder why sibling projects like Wiktionary (Wikisource, ...) are not available in a similar way. I have not seen that in the Wikidata long term plans. Of course it shall not be within "Languages"; a new grouping could be needed. As it is now, I am five steps & a page scan away from a Wiktionary lookup (google is in three).
Earlier posted at :en:VPT#Wiktionary_at_hand, with boilerplate menu example. Did not find this in Help:FAQ (#18 does mention Wiktionary). -DePiep (talk) 13:22, 3 December 2013 (UTC) (homewiki en:User:DePiep).

Every project have it's challenges. Wikisource is scheduled for January. -- Lavallen (talk) 14:56, 3 December 2013 (UTC)
@DePiep:: Please, check Wikidata:Sister projects for more info on each sister project discussion. Wiktionary is not as trivial as it may seem.--Micru (talk) 14:57, 3 December 2013 (UTC)
In fact, it's the hardest project to get Wikidata to support, so it'll probably be the last one to get Wikidata support. --Jakob (Scream about the things I've broken) 17:09, 3 December 2013 (UTC)
Lydia herself said this. The Anonymouse (talk) 17:24, 3 December 2013 (UTC)
Thank you all, this is the first time I see it is on a todo list. Supports my intuition. -DePiep (talk) 08:37, 5 December 2013 (UTC)

Wikidata and archeology

I have seen that there has been a Wikidata meets archeology event a few months ago but I do not see any discussion about archeology on Wikidata. Has there been anything ? Would anyone be interested ? (not sure I would actively take part in the project, but I am wondering how archeology related items should be modelled). --Zolo (talk) 13:20, 5 December 2013 (UTC)

'instance of' everywhere?

As the use of P107 (P107) is reduced it has struck me that maybe we should be looking to add instance of (P31) everywhere instead. In places where we are using a synonym for instance of (P31) like P132 (P132) or P60 (P60) we can add 'instance of (P31):administrative territorial entity (Q56061)' and 'instance of (P31):astronomical object (Q6999)' as well. We can even add 'instance of (P31):class (Q5127848)' wherever we have 'subclass of (P279)! (As well as - not instead of)

I'm not raising an RFC for this as I think it is maybe not worth doing. I was wondering what other people think. It is probably best to leave this for now and revisit it later once we have queries. Maybe then we will find this would be useful. Filceolaire (talk) 22:06, 4 December 2013 (UTC)

We already started to do that here : Talk:Q16521, see upper in this chat. Actually the question is pending for a long time, see the discussions in Help talk:Basic membership properties. TomT0m (talk) 22:15, 4 December 2013 (UTC)
We could, but I do not think that is a very good use of our time except in particular cases; example ship classes which have a particularly convenient item at ship class (Q559026). (In the case of ship classes, it will help the infobox implementers deal with what I'm sure will be the eventual loss of vessel class (P289).) As for the "synonyms" ("sub-properties"), we should be making precisely the same claim in instance of (P31) as we would be making in those sub-properties; example ships in a ship class should have both instance of (P31) "x-class (ship type)" and vessel class (P289) "x-class (ship type)" until such time as the sub-properties no longer have consensus for use. This is in accordance with the best practices of use for the basic membership properties, and makes it very clear that data is duplicated due to the sub-property relations. This also makes it trivial to use either system to get information about the item. --Izno (talk) 00:18, 5 December 2013 (UTC)
Hi Izno, there is actually absolutely no guarantee that subproperties will ether be implemented. On the other hand, this solution just need queries and access to other items data in Wikipedia, which are both planned, to be OK for infoboxes. It also allows large flexibility in classification systems used and to sort them out with no properties at all. We just get sort of three levels : individual objects and concepts, classes of individuals, and classes of classes which allow to class anyway we want, allows to use different upper ontologies without mixing everything ... I think it is a pretty good path to follow. TomT0m (talk) 11:39, 5 December 2013 (UTC)
"absolutely no guarantee that subproperties will ether be implemented" – Which is why it is my belief that we should use instance of (P31) and subclass of (P279) to the bottom of the hierarchy, regardless of whether there are special types. "this solution" – Which solution? --Izno (talk) 14:47, 5 December 2013 (UTC)
  1. What do you means by regardless of whether there are special types ? Special type properties ?
  2. This solution is to use instance of (P31) and subclass of (P279), and by using instance of (P31) as Joe proposed to class classes. Compared to the subproperty solution, this is equivalent except that each time you want to use a special property with an item, you put instance of <special property [equivalent item]> instead of special property type <item>. Except that work without asking anything more to developper and it is way more flexible and easyer as we don't have to create properties but just the classes and a meta class. TomT0m (talk) 18:52, 5 December 2013 (UTC)

Question about item (Q2146005)

Hi, this item (Q2146005) has three articles : Restitution von Raubkunst (german), Restitution des œuvres d'art spoliées sous le troisième Reich (french), Restitution av stöldkonst (swedish). The french and swedish articles show a link to the two others, but the german page only to the swedish one. Thanks for your help --Franz53sda (talk) 23:21, 5 December 2013 (UTC)

You need to Wikipedia:Bypass your cache (Q10986112) or Help:Purge (Q11052584) on the de. article. --Izno (talk) 23:43, 5 December 2013 (UTC)

Muscle cuirass

Why can't I add Muskelpanzer to Muscle cuirass? Gun Powder Ma (talk) 12:03, 7 December 2013 (UTC)

Because Muskelpanzer had it's own item. Now it's   Merged with Q3006836. --Stryn (talk) 13:37, 7 December 2013 (UTC)

communist party (Q233591)

Hi! communist party (Q233591) has some disambiguation pages linked to it. Example: fr:parti communiste. Nevertheless it has some other statements which relate to pages from the (Main) Article namespace. There is also another disambiguation page Communist Party (Q502446) which is linked to fr:parti communiste révolutionnaire.
The Interwiki links should be changed. Please help! I should have known that there is always trouble with communist parties ;-) . Regards לערי ריינהארט (talk) 16:04, 7 December 2013 (UTC)

Let's make:
  1. communist party (Q233591) (article)
  2. Communist Party (Q502446) (disambiguation)
--16:16, 7 December 2013 (UTC)

  Done --Kolja21 (talk) 16:36, 7 December 2013 (UTC)

Change the resysopping process

I have a proposal.If an admin does fewer than 10 actions in 6 months and is desysopped, they have the option of either filing an RFA to regain their bit immediately or they can be active for a given amount of time (1 month?) and then request resyssoping at WD:BN. This will make it easier for inactive admins to come back if they want to. --Jakob (Scream about the things I've broken) 22:17, 4 December 2013 (UTC)

@King jakob c 2: How could bureaucrats tell if the admin is actually 'active' within that amount of time? --Ricordisamoa 00:23, 5 December 2013 (UTC)
@Ricordisamoa: By looking at their contributions/logs. --Jakob (Scream about the things I've broken) 00:40, 5 December 2013 (UTC)
  Oppose First the activity, then the community should re-evaluate the request. --Rschen7754 00:43, 5 December 2013 (UTC)
  Oppose because we cannot have a reliable measure of activity, on either a quantity or quality level. --Ricordisamoa 01:00, 5 December 2013 (UTC)
  Oppose I'd rather not have a post-desysopping activity requirement.--Jasper Deng (talk) 06:03, 5 December 2013 (UTC)
  Oppose If an admin has been desysopped due to inactivity and wants to become an admin again they can request it at RfA and justify their absence. 10 admin actions is (on this project) a negligible amount of effort over a six month period. It's the least we can ask to prove activeness. Del♉sion23 (talk) 22:01, 6 December 2013 (UTC)
  Oppose 100% agree with Delision23  Klaas|Z4␟V:  07:36, 8 December 2013 (UTC)

new features available for testing (ranks, ordering, table of contents and more)

Hey everyone!

We deployed a bunch of new code to test.wikidata.org for you to test.

Based on your feedback for the initial version of quantities I have decided to not release them to wikidata.org next week. We have been working on a good part of the feedback and most fixes are now also live on test.wikidata.org. This means quantities are now scheduled to come to Wikidata in the middle of January. I'm sorry for the delay but your feedback was very valuable.

In addition to that we have rolled out a new batch of features to test.wikidata.org for you to test and give feedback on. The first one is ordering. You can now change the order of statements and statement groups. There are still a few usability issues with it that we need to solve but I want to get this out to you now. The second one is ranks. Ranks are there to indicate one or more statements are preferred or deprecated. This is especially useful for things like indicating that someone was the major of a city many years ago. The third one is a table of contents that was developed by Bene*. This should come in handy especially on large items. The forth one is that the data type of a property is now also added to the JSON and API output. And last but not least we've worked on improving performance so things run a bit faster for you.

These should go live on wikidata.org on Tuesday next week. So how's that for a Christmas present, people? ;-)

Cheers --Lydia Pintscher (WMDE) (talk) 19:58, 6 December 2013 (UTC)

On the first day of Christmas, Wikimedia gave to me,
Claims ordering on an item... --Izno (talk) 20:50, 6 December 2013 (UTC)

Phase 2 started on 4. February 2013 ([9]). If quantities are really released in mid-January, this would mean it took a year. A year this 'database' exist, without the ability to store numbers - the most common thing for a database. This was one of the circumstances which resulted to my decision some month ago not to contribute to this project anymore. --37.35.115.38 23:33, 6 December 2013 (UTC)

You became addicted to wikidata very quickly ;) Good luck. Pyb (talk) 03:24, 7 December 2013 (UTC)
I kind of wish that there were more options than three for the rankings. There are certain scenarios where having a set particular order for items in a statement would be helpful, and with this setup we would have to throw out all the items in the statement whenever the order needed to be fixed.
No I think you're missing something. The order can now be changed as you wish without removing any statement. Lydia Pintscher (WMDE) (talk) 09:44, 7 December 2013 (UTC)
Well, I mean for the values within each statement. --Rschen7754 10:22, 7 December 2013 (UTC)
That is also possible. It's just not super intuitive. That's the usability issues I was talking about. Lydia Pintscher (WMDE) (talk) 10:29, 7 December 2013 (UTC)
Ah okay, I see it now. :) --Rschen7754 10:38, 7 December 2013 (UTC)
Also, I am concerned about the delays regarding essential data types. While definitely important, I am not sure if prioritizing the integration of sister projects is the right thing to do; the vast majority of people are Wikipedia-only, and having more working data types across a few projects would be more helpful than having only a few data types across all projects, some of which generate very little traffic. I'm not anti-sister project, but I think that adding more data types would help more people. The Wikipedia integration into Wikidata is not complete largely because of this. --Rschen7754 03:40, 7 December 2013 (UTC)
@Rschen. If you look at all RfC we had during this year I think you can't say that datatypes should be available faster: having tools is not enough to work we need to know how to use each tool. And right now it seems that in smoe cases there are still some open questions. The delay between each datatype release was good because it allows people to take the time to use one new datatype and to have time for questions and propositions. For me we should let the datatype longer in the test wiki before release in order to have time to think how we could use each datatype.
Adding data into a database is useless is there are no unique format to store data. Snipre (talk) 07:36, 7 December 2013 (UTC)
I strongly disagree. Not being able to store numbers is the one thing holding up Wikipedia integration. Also, it usually takes me 5-10 minutes of playing around on test.wikidata before I figure out how it works, not 3 months. --Rschen7754 09:28, 7 December 2013 (UTC)
Yes this is holding back. Which is why quantities was the first thing released to test under my watch. Now I am delaying it for a short time because a lot of very useful feedback came from you. I think this is a sensible step. Otherwise we don't need to do this whole testing thing at all ;-) Lydia Pintscher (WMDE) (talk) 09:44, 7 December 2013 (UTC)
Well, testing is good, but what I'm more concerned about is the emphasis on sister projects rather than on critical features like badges and the numbers data type. --Rschen7754 10:22, 7 December 2013 (UTC)
That was a very conscious decision though. Because it is crucial to get in the sister projects soon to not make Wikidata too Wikipedia-specific. Lydia Pintscher (WMDE) (talk) 10:29, 7 December 2013 (UTC)
Look forward, not backward :) Developping in a complex environment with so many actors must not be easy and there is a lot of tough decisions to be made by the devteam, so be pleased that the project is still going forward. One (two) essentials features to be deployed, woohoo \o/. Wikidata is here for many years and has a lot of potential, we can be patient for a few months/years before it reaches its full potential and have a little positive feedback from community to make things better. TomT0m (talk) 13:07, 7 December 2013 (UTC)
@Lydia Pintscher (WMDE). Thanks to put these small details in the priority list: this offer new possibilities to interact with data.
You're welcome :) Lydia Pintscher (WMDE) (talk) 09:44, 7 December 2013 (UTC)
Thanks for this update! When the sorting is changed and saved, is it inteded that it shouldn't show up in recent changes? (I'm not in favour nor against, just wondering how is the intended behaviour) And I find the arrow system a bit strange. I would have preferred something like this:
  • when the statement group has more than one claim, then display one set of arrows next to the property name that moves the whole statement group and another set of arrows next to the active claim that just move that property up or down inside the active group.
  • when the statement group has only one claim, enable only the set of arrows next to the property name.
Btw, I also noticed two weird effects:
  • if the statement is moved and edited, then the edit is saved, but not the new sorting order.
  • (1) create a new empty item, (2) add a new statement, (3) save it, (4) click edit, (5) cancel edit, (6) statement vanishes.
--Micru (talk) 17:25, 7 December 2013 (UTC)
Thanks for the feedback. Sorting order changes should show up in diffs in the future but do not at the moment because it is pretty tricky to do. Lydia Pintscher (WMDE) (talk) 11:06, 8 December 2013 (UTC)
I can reproduce the vanishing statement issue. I've filed a bug for it at bugzilla:58179. Lydia Pintscher (WMDE) (talk) 11:29, 8 December 2013 (UTC)
And I can also reproduce the ordering change not being saved. The bug report for that is bugzilla:58180. Lydia Pintscher (WMDE) (talk) 11:35, 8 December 2013 (UTC)
I think it is better to delay the number datatype. We don't want to risk frustrating people with a premature deployment. On the plus side, there is still an infinite amount of work to be done on the other datatypes. Until Wikidata can give me a list of all movies shot in the 60s in Spain, in which a black female horse is stolen by a left-handed actor playing a Portuguese orphan, directed by a colorblind German who liked sailing, and written by a dog-owning women from Helsinki, we have more work to do. Another thing to consider @Lydia Pintscher (WMDE): is to reply to these complaints with donation requests. More money means faster development and lots of other cool stuff, doesn't it? I would really enjoy a page where feature requests could be upvoted with microtransactions. Is there actually a way to donate directly to Wikidata? --Tobias1984 (talk) 18:39, 7 December 2013 (UTC)
I agree 100% with Tobias1984. Without wanting to introduce crowdsourced micromanagement, microtransactions can help, and would let individuals and organisations show their support for Wikidata. p.s. with medical condition (P1050) you can now add that the German woman is colorblind/colourblind. ;-) John Vandenberg (talk) 01:28, 8 December 2013 (UTC)
Haha you made my day, Tobias1984! I'll put that on the whiteboard in the office as the target to work towards from now on :P As for donations directly to Wikidata: I'll try to find out if that's possible and if so how. Lydia Pintscher (WMDE) (talk) 11:06, 8 December 2013 (UTC)
Glad I could add some humor to the situation. A really nice way to increase sourcing would be a "thank editor with 1 $/€ for the edit" next to the normal "thank" button. The person making the edit would get a message "user123 has donated 1 $/€ in your name to the Wikimedia Foundation for your edit to .....". On Wikidata that money should get a Zweckwidmung (dedicated to?) for Wikidata. --Tobias1984 (talk) 12:42, 8 December 2013 (UTC)

Sorting political divisions

We need to figure out how all of the near-synonyms of "state" should be classed within each other, because they're a bit of a mess now and they're changing frequently. I think this structure could work. Comment?

  1. political territorial entity (Q1048835) (anything with a single legally-binding administrative body above it (possibly with subdivisions))
    1. polity (Q1063239) (a singular body, as opposed to a political union)
      1. state (Q7275) (singular, geography-based political division)
        1. sovereign state (Q3624078)
        2. administrative territorial entity (Q56061) (subdivisions of sovereign states)
          1. first-level administrative division (Q13220202)
            1. U.S. state (Q35657), constituent country of the United Kingdom (Q3336843), province of Canada (Q13218404), etc.
          2. second-level administrative division (Q13220204), third-level administrative division (Q13221722), fourth-level administrative division (Q14757767), & Category:Television shows (Q6594710)
        3. constituent state (Q1763527) (vague term, most items also fit somewhere else)
          1. constituent country of the United Kingdom (Q3336843) (also under "first-level administrative subdivision", above)
        4. self-governing dependencies
          1. Crown Dependencies (Q185086), French overseas collectivity (Q719487), etc.
        5. federated state (Q107390) (vague term, most items also fit somewhere else)
          1. U.S. state (Q35657) (also under "first-level administrative subdivision", below)
      2. political division not based on geography
        1. community of Belgium (Q89934), etc.
    2. political union (Q1140229) (e.g., the European Union)
  2. country (Q6256) (geographic area)
    1. state (Q7275) (along with all of the subclasses of "state", above)
    2. occupied territory
    3. unrecognized state
  3. nation (Q6266) (cultural grouping, also a subclass of community (Q177634))
    1. nation state (Q179671)

--Arctic.gnome (talk) 22:04, 5 December 2013 (UTC)

In your tree, first-level administrative division (Q13220202) is a state (Q7275), and state (Q7275) is not necessarily a administrative territorial entity (Q56061). And why we need to distinguish administrative territorial entity (Q56061) and polity (Q1063239)? In my understanding they are the same. "Autonomous region" (can further split by level) is also important to add.
My suggestion for political division is
  1. administrative territorial entity (Q56061)
    1. "Federation"
    2. state (Q7275)
      1. sovereign state (Q3624078)
      2. federated state (Q107390)
    3. first-level administrative division (Q13220202)
      1. "First-level Autonomous Region"
        1. Oversea regions...
        2. Country specific terms...
    4. second-level administrative division (Q13220204)
      1. "Second-level Autonomous Region"
    5. third-level administrative division (Q13221722)
    6. fourth-level administrative division (Q14757767)
    7. ...
金亦天 (talk) 09:10, 6 December 2013 (UTC)


(1) You're right that "administrative unit" shouldn't be bellow state since some are just administrative without having their own government.
(2) "Administrative unit" can't be above "sovereign state" because the en.wiki article specifically calls administrative units subdivisions of sovereign states. Based on Google Translate, other languages seem to do the same thing. I've changed the name of it to "administrative subdivision" to make that more clear.
(3) "Polity" is an odd case, maybe we can just take it out of the tree and put it under "philosophical concepts".
How about this organization:
  1. political territorial entity (Q1048835) (anything with a legally-binding administrative body above it)
    1. political union (Q1140229) (e.g., the European Union)
    2. political division not based on geography
      1. community of Belgium (Q89934), etc.
    3. state (Q7275) (geography with a government above it)
      1. sovereign state (Q3624078)
      2. federated state (Q107390) (vague term, most items also fit somewhere else)
        1. U.S. state (Q35657) (also under "first-level administrative subdivision", above)
      3. dependent territory (Q161243)
        1. Crown Dependencies (Q185086), French overseas collectivity (Q719487), etc.
    4. administrative territorial entity (Q56061) (subdivisions of sovereign states)
      1. first-level administrative division (Q13220202)
        1. U.S. state (Q35657), constituent country of the United Kingdom (Q3336843), province of Canada (Q13218404), etc.
      2. second-level administrative division (Q13220204), third-level administrative division (Q13221722), fourth-level administrative division (Q14757767), & Category:Television shows (Q6594710)
      3. constituent state (Q1763527) (vague term, most items also fit somewhere else)
        1. constituent country of the United Kingdom (Q3336843) (also under "first-level administrative subdivision", above)
  2. country (Q6256) (geographic area)
    1. state (Q7275) (along with all of the subclasses of "state", above)
    2. occupied territory
    3. unrecognized state
  3. nation (Q6266) (cultural grouping, also a subclass of community (Q177634))
    1. nation state (Q179671)
  4. polity (Q1063239) (under philosophical concept)
--Arctic.gnome (talk) 18:58, 6 December 2013 (UTC)
Looks quite good, however, I do not like the classification with first-level administrative division (Q13220202), second-level administrative division (Q13220204), etc. It can be ambigious in countries with many types of subdivisions, e.g. have a look at en:File:Administrative Gliederung Deutschlands.svg. In Canada it's even worse because every province has its own classification. Therefore, I suppose to use administrative territorial entity of Canada (Q3750285), administrative divisions of Germany (Q387917) etc instead. --Pasleim (talk) 12:16, 8 December 2013 (UTC)
@Pasleim: I'd be fine with deleting the 1st-level, 2nd-level pages. They don't have Wikipedia articles in any language, so it wouldn't be a big loss. --Arctic.gnome (talk) 20:03, 8 December 2013 (UTC)

Derivatives(Der) to reduce the load of Items(Q) and Properties(P)

Currently to satisfy constraints of some properties is difficult due to lack of items. For example, when we want to say the occupation of a gymnast is "gymnast", we have no item for it and can only use gymnastics (Q43450) instead. This violates the constraint of field of work (P101). In the future structure of Wikidata, if for the property (of a Derivative), we are required to fill in a Derivative of an Item, then this problem will be solved. We can define a "Derivative" as "Profession of Field(Der_x)", then P101 -> Der_x:Q43450(Profession of Field:Gymnastics) will solve the problem above. Another example is, we always lack senses separation when defining items, especially when those different senses are indeed not useful in terms of Encyclopedia. For example, association football player (Q937857) has property subclass of (P279) to show it is a class, but at the same time it has instance of (P31) showing it is an instance, why? Because the instance of (P31) part is in fact assigning the property to "Profession Implied(Der_y)". Then similarly, Der_y:P31 -> profession (Q28640) solves the problem.

This should be really important if property constraints are really to be strictly enforced. It also clarify the logic. Just check the violation list and see if you can resolve all those violations without creating a lot of extra items that just won't appear in Wikipedia.

Another extended issue related to this is the Wikipedia page language links. Items in different languages are often divided according to different dimensions. You can either map something wrong or allow a lot of language links to be isolated. For example, association football player (Q937857) currently has no page in Chinese, but association football (Q2736) is a reasonable description for this translation. To reduce the language isolation problem, tracing along Derivative chain automatically should be quite effective.

For the implementation, a simpler way might be just to use properties as derivatives. Then each statement is like: P_x -> P_y:Q_z. But using derivatives can help to tell where is the source or original term that the related concepts are derived from.金亦天 (talk) 07:24, 6 December 2013 (UTC)

I don't understand how this would work. Can you give a more specific example. What would one of these derivative properties look like in use? Filceolaire (talk) 15:34, 6 December 2013 (UTC)
Derivative actually can be defined similar as Property now, but it is at the same time like an item because we need to specify the class of the derived values. For example, "Sportsman of (Sports)" can be a derivative, then, value has class of sportsman (property linking "resulting in" to item), and the variable(Sports) item must be subclass of sports (constraint as Property). Through the use of this derivative, we can link all current sports and the sportsman titles. For missing ones, we just don't need to create items but apply the derivative. Furthermore, if we input the derivative of some item as property value, then the system may also be able to automatically find the existing derivative match. Say I didn't notice there is an item "basketball player" but I used "Sportsman of (Sports)":"basketball" to fill in "instance of" for a player item, then this input can be automatically updated to "basketball player" that already exists. All in all, derivative serves as a way to label more direct properties and also to skip the creation of extra items to just for fitting the property logic.金亦天 (talk) 01:49, 8 December 2013 (UTC)
The idea is interesting, as item scoping is a probem we get since the beginning, but I wonder if it would need substantial changes in the Wikibase data model to be implemented. Would it require any other concepts below property, items and qualifiers ? I'm afraid it would require subtancial motivations and lobbying in the community and the dev team to be implemented if that's the case. TomT0m (talk) 18:07, 6 December 2013 (UTC)
Current data model can handle this change but requires some workaround effort, and a lot of scripts need to be updated (but I guess anyway they keep being updated). For applying derivative for value: "P" = "Der":"Qs", "wikidata-entity" type value can be replaced by another definition, which accepts derivative, followed by an array of "input variable to the derivative" (for example "relationship between 2 countries" need the input of 2 country items). But for assigning value to derivative case: "Der":"P" = value, this sound more troublesome and one way to handle this is to include the "derivative" as a quantifier and let the display automatically group the statements with this quantifier to the same group to give a reasonable display. Well, the need of the later use may not be that solid, if the former use can be solved then I think it already realizes the main effect of using derivatives. 金亦天 (talk) 01:49, 8 December 2013 (UTC)
If I understand this right, are you proposing making an item like "gymnast" an alternate way of displaying "gymnastics" rather than it being its own item? I wonder if that will cause trouble for people who are trying to sort data; what if they only want the professions and not the fields? In a case like politician/politics you could end up with tonnes of unwanted data. Couldn't we solve the professions issue by just having a property called "item is the title for a professional of" or, more broadly, just "derivative term of"? What is the harm in not having Wikipedia articles linked to the item when it's easy to link to the parent item that does have articles? --Arctic.gnome (talk) 18:24, 8 December 2013 (UTC)
Derivative allows the use of items that do not exist. For people trying to sort data, if they want to list profession list, then no trouble since the actual items are not affected; if they want to list professions of people, then they need to make their list smarter. They should separate results from different derivatives. Then some professions are listed in terms of true professions, some are bases of derived professions. I think the current situation is clearly worse since people are being forced to fill some non-profession item into profession property in order to express some information, which really creates troubles.
Derivatives will not create unwanted data. You want to add that information, but you lack the item only, that's the situation you apply derivative to input precise information (instead of inputting bad information). "item is the title for a professional of" will not help to input profession of a person when the professions item just doesn't exist. A similar idea is to use a lot of properties like "in a occupation under field" is in fact similar to my proposed "Derivative", but less structured.
Wikipedia language links are really helpful when people want to check similar article in other languages. You will know how sad you are if you find an article has no page in other languages while that article is describing something well-known.金亦天 (talk) 02:51, 9 December 2013 (UTC)

I can no longer edit string values...

 

It seems that I have another problem this morning: I can no longer edit string values in statements. I click twice on "edit" (why twice by the way?), the "remove" and "cancel" links appear, but I can't change the value... Does anyone else have this bug? — Ayack (talk) 10:21, 5 December 2013 (UTC)

Can you please reload the page and try again? If it still happens please send me a screenshot. --Lydia Pintscher (WMDE) (talk) 10:51, 5 December 2013 (UTC)
I cleared the cache and reloaded the page but nothing changed. — Ayack (talk) 11:20, 5 December 2013 (UTC)
I recognize this, but it is limited to strings that are links to another site (inside or outside the WMF-franchise). Has been so for a few days. - Brya (talk) 11:41, 5 December 2013 (UTC)
You can add a new string value via UI, but after reloading the page the string value is no longer editable. --Succu (talk) 11:56, 5 December 2013 (UTC)
Ok now I can reproduce it. When you disable the Authority Control gadget these statements are editable again. We're investigating if it is an issue with the gadget or the Wikibase code. --Lydia Pintscher (WMDE) (talk) 12:48, 5 December 2013 (UTC)
Ok, thanks. — Ayack (talk) 13:25, 5 December 2013 (UTC)
Update: Henning is working on a rewrite of the gadget to fix this bug and make it considerably faster. He should be done soon. --Lydia Pintscher (WMDE) (talk) 10:33, 6 December 2013 (UTC)
This should be fixed now. The Anonymouse (talk) 17:39, 6 December 2013 (UTC)
Yes, It's working now, thanks, but I still have to click twice on "edit" to change it... — Ayack (talk) 19:37, 6 December 2013 (UTC)
Does not work correct with all qualifiers. See IUCN conservation status (P141) in Podocarpus annamiensis (Q1024023). --Succu (talk) 07:39, 7 December 2013 (UTC) Some references are broken too e.g. taxon name (P225) in blue water-speedwell (Q159711). --Succu (talk) 12:36, 7 December 2013 (UTC)
I'll have Henning have a look at it on Monday unless someone else finds the issue before that. Lydia Pintscher (WMDE) (talk) 12:40, 7 December 2013 (UTC)
Update: The gadget has been updated. Let me know if anyone is still seeing issues that don't go away after reloading the page. Lydia Pintscher (WMDE) (talk) 17:49, 9 December 2013 (UTC)
In Podocarpus annamiensis (Q1024023), I have to click three times on "edit" to change the value of taxon name (P225)... — Ayack (talk) 18:59, 9 December 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Hmm, you must be having a separate issue because I only have to click once to edit. I've confirmed in the sandbox. The Anonymouse (talk) 19:38, 9 December 2013 (UTC)

An apology

I should have come back to say this a long time ago, but I would like to apologize to the community for my mini-outburst back when I withdrew my RfA. AutomaticStrikeout 21:10, 5 December 2013 (UTC)

Don't worry, all is fine. Welcome back! --Stryn (talk) 21:42, 5 December 2013 (UTC)
Emotions are what living things have. Glad your back! --Tobias1984 (talk) 09:37, 6 December 2013 (UTC)
Same. Glad you're back. — ΛΧΣ21 00:35, 10 December 2013 (UTC)

Same title and same description in an unknown language --> items are locked...

Giuseppe Pecci (Q1332564) and Giuseppe Pecci (Q595813) are two cardinals who also have the same name. The problem is that I can edit these items because in a language I don't speak, they also have the same description: "An error occurred while trying to perform remove and because of this, your changes could not be completed. Another item (1332564) already has label "Giuseppe Pecci" and description "włoski duchowny katolicki, kardynał" associated with language code pl. "

Do I really have to change the description in an unknown language to solve this problem? — Ayack (talk) 11:30, 7 December 2013 (UTC)

Aren't the same person: it:Giuseppe Pecci (1807-1890) (Q1332564), it:Giuseppe Pecci (1776-1855) (Q595813) --ValterVB (talk) 11:39, 7 December 2013 (UTC) Sorry read to fast --ValterVB (talk) 11:41, 7 December 2013 (UTC)

I've added the dates of birth and death to the pl description. Hope it will work now. --Kolja21 (talk) 11:46, 7 December 2013 (UTC)

Yes, thanks. But this behavior seems strange to me. — Ayack (talk) 11:53, 7 December 2013 (UTC)
This behavior should not matter. Both these items have been created with these Polish labels and descriptions in December of last year. Looks like it had been possible to create two items with the same label and description back then. This long changed, and apparently there are only very few of those items existing (otherwise we would get such reports every day), so probably that's a problem of the past to a large extent. --YMS (talk) 13:10, 7 December 2013 (UTC)
PS: A similar, perhaps more serious problem has been reported (and not fixed) a while ago on Wikidata:Contact the development team/Archive/2013/11#Can not remove P107 in Q101 because of length constraint. There, two languages had too long labels, which prevented certain actions, including changing the labels ion one of these languages, so (other than in the Giuseppe Pecci case) the conflict could not be resolved using Wikidata's GUI. I did it now by (completely) deleting both labels via the API. Such an action should never be required. --YMS (talk) 13:17, 7 December 2013 (UTC)
Can somebody make a list about items with same title and same description in a language?--GZWDer (talk) 14:48, 7 December 2013 (UTC)
Same problem is here Wikidata:Forum#doppelte commonscat; Qualifikatoren (ich hoffe die Bezeichnung ist richtig) können bei Namengleichheit nicht gelöscht werden no. 2, with regard to Breughel the Elder/the Younger--Oursana (talk) 01:49, 8 December 2013 (UTC)
Urgh. I thought you could at least fix this by changing one of the items via the webinterface. That's not possible? Bad indeed then. Will need to look into it more. Lydia Pintscher (WMDE) (talk) 10:58, 8 December 2013 (UTC)
This is often problem with categories - description is "Wikipedia category" and some forgotten label from link, which was moved tyo another item. JAn Dudík (talk) 20:43, 8 December 2013 (UTC)
We have bugzilla:58166 for this now. I'm sorry I missed that this is causing items to be completely uneditable via the UI. --Lydia Pintscher (WMDE) (talk) 13:43, 9 December 2013 (UTC)

Retiring as administrator of Wikidata

Hello fellow Wikidatians, I want to hereby announce that I will request a removal of my administrator rights on Meta. This decision, which was hard to make, comes as a result of being too busy IRL and having not any desire to edit Wikidata. Also, I wasn't involved in Wikidata lately. I have been considering this already for some time and tought it would be a good moment to stop.

I have had fun in doing administrative tasks when Wikidata was just out. I have been admin in total for a bit more then a year and was also one of the first appointed admins. I wish Wikidata and its administrators the best for the future. Wiki13 talk 15:15, 9 December 2013 (UTC)

Removed by User:QuiteUnusual. Sad to see you leave WD. Thank you for all your contributions to Wikidata! --Glaisher [talk] 15:23, 9 December 2013 (UTC)
Sad to see you leaving. But of course IRL is always more important than the Wiki life. Thank you for your work here and good luck! --Stryn (talk) 15:28, 9 December 2013 (UTC)
It is a pity you are leaving. Thanks for your good work.--Ymblanter (talk) 19:48, 9 December 2013 (UTC)
Sad to see you go, but thanks for your service. Ajraddatz (Talk) 20:19, 9 December 2013 (UTC)
Thanks for all your service, Wiki13. — ΛΧΣ21 04:12, 10 December 2013 (UTC)
Thanks for your work, Wiki13. --by Revi at 04:55, 10 December 2013 (UTC)

Redesign of Wikidata:Tools

As a task of GCI, I created a fully new design of Wikidata:Tools. There are now three subpages for External tools, Gadgets and User scripts. Thus the page is less full and much more user friendly. On Wikidata:Tools itself, you can see a short description of the three types of scripts and at the bottom a weekly changing "tool of the week". This will be changed by a bot automatically later. Another change is that bugs will no longer be reported at the project page because this only serves documentation from now. Bugs as well as feature requests do belong to the talk pages of the scripts or their authors. I hope you like the new design of the page, but if you have any tips to improve it I would be glad to hear from you. Best regards, -- Bene* talk 21:38, 9 December 2013 (UTC)

Awesome! Tbh the old page was awful. But subpages could be better (still looks boring), maybe some different background (not white) for the tools with div? --Stryn (talk) 21:45, 9 December 2013 (UTC)
I second that. The subpages could be way better but well, you're not getting paid for that :P I can put my hands on it soon and give them my personal touch :) — ΛΧΣ21 04:11, 10 December 2013 (UTC)

Unable to edit any statements

Apparently new code was just deployed, which includes the table of contents, ranks, and a new box in the watchlist. However, I am unable to add/edit any statements. Anyone else (since according to Special:RecentChanges shows that users are still creating claims)? It also appears that Javascript is not working for me on any item page. The Anonymouse (talk) 20:05, 10 December 2013 (UTC)

Also, caching appears to be broken in items, with items being in the language of the last user that edited it. The Anonymouse (talk) 20:07, 10 December 2013 (UTC)
We're still working out a few issues. Should be fixed within the next 30 mins - hopefully earlier. Will keep you posted. --Lydia Pintscher (WMDE) (talk) 20:08, 10 December 2013 (UTC)
At first the page crashed while making an edit, but now it's working for me. The strange part is on Canada (Q16) when I changed the rank of a statement, that entire property moved to the top of the page, but that hasn't happened with any other properties I've ranked. Also, for some reason sometimes pages load with the title in the wrong language even though all of the statements are in the right language. --Arctic.gnome (talk)
Should all be fixed now. If you're still seeing issues please reload/purge the page. --Lydia Pintscher (WMDE) (talk) 20:48, 10 December 2013 (UTC)

Table of contents

Is there an option to switch off this space consuming table of contents? --Succu (talk) 20:11, 10 December 2013 (UTC)

This is probably the smallest ToC there is :P But you can make it go away by clicking hide in the ToC box on this page for example. --Lydia Pintscher (WMDE) (talk) 20:16, 10 December 2013 (UTC)
Old items like lion (Q140) have no ToC, new created like Luzula lutea (Q15296688) have a ToC. --Succu (talk) 20:25, 10 December 2013 (UTC)
THat's a caching issue we're working on right now. A purge of the item page fixes it. --Lydia Pintscher (WMDE) (talk) 20:27, 10 December 2013 (UTC)

Wikivoyage banner

The property Wikivoyage banner should show a link to Commons but I see the filename in plain text instead. --Kizar (talk) 23:25, 10 December 2013 (UTC)

What's wrong with the current approach? --Wylve (talk) 01:24, 11 December 2013 (UTC)
I think this is a bug; see above. The Anonymouse (talk) 06:20, 11 December 2013 (UTC)
Sorry I misread the question. --Wylve (talk) 06:50, 11 December 2013 (UTC)

General guidelines about ordering

So, now, we can try to have a relatively consistent look across Wikiata items, and we should agree on some conventions, here are some proposals. -Zolo (talk) 09:19, 11 December 2013 (UTC)

Order of properties

This proposal seems a bit messy because it includes properties that are for very different types of items. We will certainly need, "how to" pages for specific classes, but it seems better if they can be be consistent with project-wide guidelines.

General idea about the item
Creator
Titles (for works), names (for people)
Start date, end date
Other properties (to be refined)
Timeline significant event (P793)
External links and identifiers (ISBN, VIAF, GND etc.)
I copypasted the list from statementSort.js into Help:Ordering. I think the "navigation properties" (bottom up, lateral, and top down) should generally be on top in every item. When it comes to e.g. geographical items, that have their own "navigation properties" (like the bottom-up "is in the administrative unit"), I see no problem with putting these on top as well, because in non-geography items these won't be present anyway. All in all, I think it might be best to classify every property as either "top down", "lateral" or "bottom up", and order them accordingly. - Soulkeeper (talk) 14:48, 11 December 2013 (UTC)
I would separate identifiers from the external links and move them further up. Italian WP show them the same way as the coordinates: it:Alice Munro. (BTW: ISBN is not part of identifiers, since it can be used for different editions.) --Kolja21 (talk) 15:14, 11 December 2013 (UTC)
I think we need an RfC.--Ymblanter (talk) 21:35, 11 December 2013 (UTC)
@Soulkeeper:: that is interesting but I wonder if it can work to separate things by topic this way. I am thinking of point in time (P585): for works of art, the date is conventionnally put between the title and the material used, but the date property is not specific to artworks, so it cannot really go to the "Works/Art&Architecture" section (or maybe the place of the date property should be dependent of the item class). --Zolo (talk) 22:03, 11 December 2013 (UTC)
Imho the ordering should depend on instance of (P31). Works need a different kind of order (of properties) than persons or terms. The main topics should have a Navigation template that show the basic properties needed for this item. --Kolja21 (talk) 15:53, 12 December 2013 (UTC)
That sounds reasonable, provided that not too many items have several p31 with conflicting orders. Perhaps document them on pages like Talk:Q16521/class to define the ordder ? That said, I think we should try to have a few general guidelines, so that we keep a relatively consistent feel. --Zolo (talk) 17:44, 12 December 2013 (UTC)

Order of statements with the same property

For time dependent properties, like "head of the executive" or "key event" I would propose to put statements in chronological order. That means that the most useful statement like the current mayor of a city will be shown towards the head, but as it can be marked as "preferred", that does not seem like a major problem. I do not find reverse chronological order very intuitive, and it would not really solve the issue either (the elected mayor be shown first, even if she has not yet assume office and should thus probably not be the preferred value). --Zolo (talk) 09:19, 11 December 2013 (UTC)

I guess the "preferred" values should be used when we have contradicting claims. ("Dorotea rural municipality was founded 1863" or "Dorotea rural municipality was founded 1874") Not when we have complementary claims: "A was mayor of X 2001-2013" compared with "B was mayor of X 1995-2001". -- Lavallen (talk) 14:01, 11 December 2013 (UTC)
We need a way to find the most current reliable value, and that may be tricky to do that without the help of rankings or something similar. According to meta:Wikidata/Notes/Data model primer: "if preferred statements exist, these statements are returned in response to a query. They would, e.g. for a population contain the most recent one as long as it is regarded as sufficiently reliable. Wikidata editors might decide to mark several statements as preferred". Apparently, when there are conflicting claims and one can be confidently considered more accurate, we should rank the other one as "deprecated". That means rankings has two meanings as the same time (reliability and relevance) but I suppose separating them would have make things a bit complicated to manage. --Zolo (talk) 14:27, 11 December 2013 (UTC)
I do not know how it will look like with queries.
But to find the most current statement, I think we can use an algoritm to identify it, just like the other uses of qulifiers you have proposed?! When it come to Malmö Municipality (Q503361) for example, it has two values with P131 today. One value "to 2007-12-31" and one "from 2008-1-1". Looking for a statement without enddate, will give us the present value in this case. -- Lavallen (talk) 14:46, 11 December 2013 (UTC)
If we have contradicting claims then use 'deprecated' to indicate the value which is considered less reliable/accurate. Don't (IMHO) use 'preferred' for this.
Where there are multiple values which are qualified in some way (historic, applies to part, etc.) then use 'preferred' to indicate the current value.
I just edited Malmö Municipality (Q503361) to order the values for located in the administrative territorial entity (P131) so they are in chronological order (oldest first) but the current values is marked as 'preferred'. While Lua can be used to find the current value, using preferred means that basic queries, which don't check this kind of thing, still get sensible answers. Filceolaire (talk) 18:05, 12 December 2013 (UTC)

Founded but never existed

Järle was founded as a City 1642, it was even made capital in the new Järle County and got it's own city arms. But very few people ever moved to that place, so few that it never started to act as a city. Today some people humorously claim that this is the only City in Sweden, since all other cities have lost their city-rights, except Järle.

What kind of statements would you add to this item? -- Lavallen (talk) 10:41, 11 December 2013 (UTC)

What is it's current legal status: municipality? When did it get that status? What was it's status before then?

Järle
Type of admin unit:city
start date:1642
Source - stated in:city charter of 1642
Type of admin unit:municipality (rank:preferred)
start date:1938
Source - stated in:local government act of 1938

Does that make sense? Filceolaire (talk) 23:56, 11 December 2013 (UTC)

The thing is that Järle has never been any kind of admin unit since then. The canal which should have given welth to the area was never built. The new County was renamed and the capital moved to the neighbour city of Nora, until the county was dissolved 1648. Today it's a hamlet, but that is not a "legal status". It looks like it 1863 was located in Nora City (a rural municipality), which was replaced by Nora Municipality 1971.
Half of the article is about the factory in Järle, who existed until the 1880's. -- Lavallen (talk) 10:11, 12 December 2013 (UTC)
There is a database-file about Järle as an archeological site here. -- Lavallen (talk) 11:18, 12 December 2013 (UTC)
Hmm. Tough one. From the sound of it the current status is 'instance of:village' and it has had that status all the way back to before 1642. While it was given a city charter this was never implemented. so
Järle
Type of admin unit:city (rank:deprecated)
status:not implemented
comment:never implemented.
start date:1642
Source - stated in:city charter of 1642
instance of:village (rank:preferred)
Filceolaire (talk) 18:17, 12 December 2013 (UTC)
+1: rank:deprecated is also what I would propose. This works even if qualifiers status and comment are missing.  — Felix Reimann (talk) 18:26, 12 December 2013 (UTC)

{{Item documentation}}

Hi, I just worked a little on this template created by Zolo, who has the potential of beeing a header in every items to display automatically some information about the item, maybe even some kind of autodescription if we want to. Just a starting point, see it in action on Talk:Q4167836 and Talk:Q16521. Per Zolo each class can have its list of properties associated. TomT0m (talk) 18:03, 11 December 2013 (UTC)

Status update on performance issues

We're working on trying to find a fix for the performance issues. If we don't find a solution by tomorrow 18:00 Berlin time I'll make the call and turn off ordering again until we can make some more fundamental changes. Sorry for the issues folks :( --Lydia Pintscher (WMDE) (talk) 16:01, 11 December 2013 (UTC)

Update: It looks like we've found a way to speed things up quite a bit. It's currently being finished and tested. I hope no more major issues arise and we don't have to turn off ordering again. Once this is all finished here we need to find someone at the Foundation to deploy it. --Lydia Pintscher (WMDE) (talk) 13:41, 12 December 2013 (UTC)
Update 2: The fixes are ready for deployment and will hopefully go live very soon. They should bring performance back to the level before the last deployment. We will work on further improvements after christmas. --Lydia Pintscher (WMDE) (talk) 17:35, 12 December 2013 (UTC)

And it's done! The update is deployed. Things should be faster again even if not perfect. You might need to clear your cache. --Lydia Pintscher (WMDE) (talk) 19:34, 12 December 2013 (UTC)

Quick question about WD:N

Hi, there's one thing I've been thinking about that isn't explicitly touched upon by WD:N. If I remember correctly, if we have item A that has links to WP articles, item B that is linked to from item A, and item C that is linked to from item B, then item C would fail WD:N. In other words, WD:N criterion 3 only applies to items that are used by items that meet criterion 1. I'm assuming that I remember correctly that this wasn't allowed, but I just wanted to make sure. --Jakob (Scream about the things I've broken) 19:23, 11 December 2013 (UTC)

Well if item A have a source from a book who is described in item B, who has an author, described in item C. Then I cannot see, that item C can be deleted, without destroying the possibilities to use sources as it is intended. -- Lavallen (talk) 19:43, 11 December 2013 (UTC)
Notability on Wikidata is whatever we decide it is.
When wikidata started, with sitelinks only, we decided that only items with an article on a wikipedia were acceptable.
When statements were added we expanded the 'notability' criteria to include items needed for statements.
We are not there yet but there is no particular reason why wikidata should not expand in the future to cover every species that ever lived, every village in the world, every astronomical object ever recorded, every movie, record, book, computer, phone, TV show, car, airplane, ever commercially released. Then we can debate whether we should create an item for every person ever mentioned in the credits of some movie. Filceolaire (talk) 00:25, 13 December 2013 (UTC)
I would say no thanks, I can imagine how messy it would be. --Stryn (talk) 05:55, 13 December 2013 (UTC)

Searching for a property

I just wanted to see if we have "stepmother", property to match P43 (P43). There seems to be no obvious indicator to tell editors how to search for a property, by name, to check whether it exists and what its property number is. How can we make that facility more clearly visible? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 12 December 2013 (UTC)

Try going to https://www.wikidata.org/w/index.php?title=Special%3ASearch&profile=advanced&search=&fulltext=Search&ns120=1&redirs=1&profile=advanced. --Jakob (Scream about the things I've broken) 15:45, 12 December 2013 (UTC)
Indeed, thank you. My point is that that page is neither linked prominently, nor easy to find, from our main pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 12 December 2013 (UTC)
See the bottom four lines of my common.js page. --Jakob (Scream about the things I've broken) 17:49, 12 December 2013 (UTC)
Actually there is a search box on Wikidata:List of properties, which is linked to from Wikidata:Community portal. The Anonymouse (talk) 18:49, 12 December 2013 (UTC)

There is a way to use the search box to search for properties: just put P: before the search term. I agree with you that this is not properly documented and "Property" should be one of the options below the searchbox. Filceolaire (talk) 00:34, 13 December 2013 (UTC)

"Save" button disabled even if the value was changed (by a script)

Hi!

I was trying to make a small script to facilitate the conversion of labels from "This form" to "this form" (per Help:Label#Capitalization) but, for some reason, once the script changes the case of the first letter, the "save" button is disabled.

Any ideas why it is not detecting the changes made by the script? Helder 15:37, 13 December 2013 (UTC)

In order to trigger the save button becoming active, I previously used something like
$('.wb-ui-labeledittool input').trigger('input');
Hope that helps. Inductiveload (talk) 18:48, 13 December 2013 (UTC)
Changing the class from your example to wb-ui-propertyedittool-editablevalueinterface it works. Thanks! Helder 19:23, 13 December 2013 (UTC)

Hall of (f/sh)ame anywhere ?

Up All Night (Q650284) is labeled in english The best album that has ever existed ever apart from midnight memories and take me home of course . Anything better ?  – The preceding unsigned comment was added by TomT0m (talk • contribs).

This was vandalism. It has been removed. --Jakob (Scream about the things I've broken) 19:41, 13 December 2013 (UTC)

P279 & P31 (& P361) for taxons (included species)

What should P279 & P31 be for taxons? Currently, we use P31=taxon (Q16521) and P279=organism (Q7239) in human (Q5). But I think we can probably copy P75 (P75) to P31 (or probably still use P31=taxon (Q16521)), and probably merge all of P273 (P273), P75 (P75), P76 (P76), P77 (P77), P70 (P70), P71 (P71), P74 (P74), P89 (P89) to P279 (or probably P361) with P75 as qualifier, and P273 (P273), P75 (P75), P76 (P76), P77 (P77), P70 (P70), P71 (P71), P74 (P74), P89 (P89) as well as parent taxon (P171) will be deprecated and can be deleted. Wikidata:Requests for deletions/Archive/2013/04/02#Property:P171 was a discussion before.--GZWDer (talk) 15:51, 22 November 2013 (UTC)

The recommendation in Wikidata:Taxonomy task force is P31: taxon (Q16521) or monotypic taxon (Q310890). I think it makes sense. It seems that parent taxon (P171) is not likely to be deleted, as it often makes life easier than subclass of (P279). I guess we can also add the above taxon in subclass of (P279) if that sounds useful. Hopefully, we will be able one day to document that a property is a subproperty of another so that we do not need to repeat things thigs way. --Zolo (talk) 16:05, 22 November 2013 (UTC)
I'm sure that I can speak for all active members of WD:Taxonomy task force (which you did not ask before starting this discussion) that we of course keep parent taxon (P171). Perhaps you should read the answers you got at some of the other threads you started for related topics.  — Felix Reimann (talk) 16:09, 22 November 2013 (UTC)

You can speak for me... :) @all owl-theoreticians: there are a lot of alternatives to model a domain. For a litte, but import part - ranks, taxonnames and how they are related - we have a good working solution. This solution is in agreement with real owl solutions out there. --Succu (talk) 16:40, 25 November 2013 (UTC)
@Zolo This is a case of class classification :) TomT0m (talk) 18:33, 22 November 2013 (UTC)
Don't use instance of (P31); use taxon rank (P105) instead - it's a specialised synonym for P31. Don't use subclass of (P279); use parent taxon (P171) instead. It's a synonym for P279 for use in taxonomy. Don't use part of (P361); it's for linking things to bigger things; not for linking classes to bigger classes. All taxonomy is about classes so there is not much scope for part of (P361) in taxonomy unless you are talking about anatomical features. Filceolaire (talk) 21:37, 22 November 2013 (UTC)
I don't like the idea we use sbecialised properties without proper support in the Wikibase software : this mean a sotware coded for any class won't work for taxons as is:This is why I advocate to class classes and not for upper taxon: TomT0m (talk) 00:43, 23 November 2013 (UTC)
So, remove P279 & P31 or set P31=taxon (Q16521) and P279=organism (Q7239)?--GZWDer (talk) 06:03, 23 November 2013 (UTC)
No reason not to use P31 and P279. And like Paperoastro noted on PfD for P60 (P60), the use of P31 = classes can even entail the use of the specialised property if we want to. TomT0m (talk) 16:43, 9 December 2013 (UTC)
I'd say, remove p279==organism (Q7239) (but there might be other useful values for p279) and set P31=taxon (Q16521)
@tomT0m, Talk:Q16521 :-). Though the template is very much in alpha mode, the class documentation is segregated in Talk:Q16521/class so it can easily be transcluded in other places like task force pages. Hopefully, the can avoid some duplicates. --Zolo (talk) 08:45, 23 November 2013 (UTC)
Great work, congrats :) Just a thing that make me wonder : is really taxon a subclass of class ? TomT0m (talk) 15:26, 23 November 2013 (UTC)
Each Taxon is a collection of some organisms and excludes other organisms so (for me) it is a class.
If every item with taxon rank (P105) needs instance of (P31):taxon (Q16521) as well then I guess every items with P132 (P132) should also have instance of (P31):administrative territorial entity (Q56061)? Filceolaire (talk) 14:49, 25 November 2013 (UTC)
I actually asked Amir as he was running Dexobot over the items removing GND main type that those with P132 (P132) have added instance of (P31) as a duplicate of P132 (P132). This would help us delete P132. :^) --Izno (talk) 01:01, 26 November 2013 (UTC)
TomTom: As (I'm pretty sure) I'm the one who added that claim, I would argue that it is. A taxon is a grouping, a set, or a collection of things which all share certain properties, which by most definitions is a class. What is most telling of course is that species, genus, or any of the other taxonomic ranks are subclasses of taxon, which makes the P31 taxon a duplicate statement. The problem of course is that you silly taxonomy task group people have decided to duplicate P279 and P31 by using taxon parent and taxon rank respectively. :^) --Izno (talk) 01:01, 26 November 2013 (UTC)
You're right, I figured. If we take all the classes of objects, taxons are surely inside them. TomT0m (talk) 19:19, 26 November 2013 (UTC)
@TomT0m: I agree that taxon is subclass of class, but @Izno: I don't agree that specific taxon (say, genus Homo) is a subclass of (term) taxon. I'd say that it is a taxon. --Infovarius (talk) 13:07, 11 December 2013 (UTC)
@Infovarius: Barack Obama (Q76) instance of (P31) human (Q5). human (Q5) subclass of (P279) Homo (Q171283) and instance of (P31) species (Q7432). species (Q7432) subclass of (P279) taxon (Q16521). Was I somehow unclear previously? --Izno (talk) 15:08, 11 December 2013 (UTC)
@Izno: May be you were. Because I've read in your message human (Q5) subclass of (P279) taxon (Q16521), while I'd insist on human (Q5) instance of (P31) taxon (Q16521). --Infovarius (talk) 06:23, 12 December 2013 (UTC)
I've been following this discussion from the sidelines for a while, and just wanted to chime in and say that Izno's comment reflects my views precisely. As I argued in April, parent taxon (P171) is one of the clearest examples of redundancy with subclass of (P279) on Wikidata, and should be deleted. Having domain-specific 'subclass of' and 'instance of' properties is a bad idea, as has been agreed upon in many property deletion discussions; having a domain-specific 'subclass of' property for biological taxonomy is no exception.
The idea that parent taxon (P171) is "in agreement with real owl solutions out there" is, to my knowledge, incorrect. Show me an example of a biological taxonomy encoded in OWL that uses 'parent taxon' instead of 'subclass of'. I haven't seen one. Instead, what I've seen is that very large, established biological ontologies use the standard subclass of (P279) property and not a custom 'parent taxon' property to define parent taxon. UniProt, a consortium of some of the biggest national bioinformatics organizations in the world, uses 'rdfs:subClassOf' (on which 'subclass of' P279 is based) to specify parent taxon. See for example UniProt's structured data on 'dog', defining the parent taxon Canis lupus (gray wolf) with 'subclass of', not 'parent taxon'. This makes the data standards-compliant and easily queryable, as explained here. Emw (talk) 17:05, 30 November 2013 (UTC)
Mmm, I would say it is true enough that P31=taxon is redundant if, say, P225 is present. It is not possible to have a value for "taxon name" unless there is a taxon. Apparently P31=taxon is there for those who are unable / too lazy to figure this out.
        I would say that indeed parent taxon (P171) is a case of subclass of (P279), and could be redundant if "subclass of" were rigorously used. However, "subclass of" can be used for other things as well, so it is handy to have a separate P171. Discussions are confusing enough, as it is. - Brya (talk) 06:19, 5 December 2013 (UTC)
Biological taxonomy has specific rules which we need to comply with, otherwise I'm pretty sure that we will not convince a single Wikipedia to switch to our data. OWL is not the only factor which makes a data model good. Usability is another. I have no problems with marking P171 a subproperty of P279, as soon as Wikidata supports this. However, there are taxa which belong to half a dozen different superclasses because different authors have different opinions and we need to be able to reflect all of them. And there never exists an end date for a classification. Moreover, in contrast to uniprot, here we additionally want to specify "cat subclass of pet", "dog subclass of scavenger", or "corn subclass of cereal", all valid uses of subclass of. But you need to be able to easily distinct such valid (!) classifications from the strict biological taxonomic classification. And no, Izno, I'm not silly. I understand that you could resolve this also by asking each and every superclass if it is again instanceof taxon or whatever you propose. However, I know that a taxobox currently already needs to load ~20 items to display all the information we have. If now every taxon has only 5 additional subclasses, the number of items to load increases by the same factor. And - again - it is also not easily usable for humans.  — Felix Reimann (talk) 15:03, 9 December 2013 (UTC)
You are right but there is an important piece of the puzzle missing: the query engine which should be able to retrieve those data, including in infoboxes, efficiently. Otherwise of course qualifiers and sources should be able to help to sort the whole kind of classification problem. Maybe a first step would be the Wikimedia tree view tool to be able to filter the classes. TomT0m (talk) 16:36, 9 December 2013 (UTC)
Please have a look at Module:Taxobox which implements already some(!) of the taxonomic rules. I'm pretty sure, this is not what the query engine is ever planned to be able to solve. And yes, we could make this piece of code even more complex, search all the possible superclasses of each and every taxon up the hierarchy to the kingdom (Q36732) only to always find that "pet", "dolphin", "drug", "food source" are valid superclasses of organisms but not taxonomic items we are interested in and track back. Please consider: Taxonomy "defines" a subclass tree with 2 million items which is - hurray - constantly changing. This is be complex enough for the human user to have it separated from all the other feasible hierarchies in which you can pack organisms.Not only for the human users - creating a visual representation only for a subset took my Core i7 with 16GB RAM already 3 days to finish. And I never heard an appealing advantage why we should merge the hierarchies and, thus, create more complexity than less besides "owl tells us it's good". Which problem can we solve better then? Especially, when we tag P171 being a subproperty of P31.  — Felix Reimann (talk) 19:03, 12 December 2013 (UTC)
First, all taxons classes should be labelled as instance of (P31) <taxon>, so just by a query we can filter the interesting classes. This is a general solution, not only for taxonomy (which by the way is a word that is used also in non biological context I think) but also for every specific fields in the project. Second, what you need is the parent taxon property, which is enough to build your tree, but could be replaced by subclass of, programmaticaly it would just require or to add a qualifier to the subclass statement to identify the good one if there is several, or to check which of the superclasses are themselves taxons, pretty much no overhead programmaticaly if done properly. Fourth, it is unlikely that the suproperty will be implemented anytime soon if at all. TomT0m (talk) 20:45, 12 December 2013 (UTC)
We know the specialised properties work.
There is a theory that using generic properties would make queries better but we don't have queries yet so we can't test that.
After we have queries we can test this theory and revisit this question but let's leave it for now. Filceolaire (talk) 07:58, 14 December 2013 (UTC)

New stuff! (ordering, ranks and a table of content)

Heya folks :)

After a few hick-ups ordering, ranks and a table of content for item pages are now live together with a load of other small improvements. I hope you enjoy them. There are still a few usability issues with ordering as well as the problem of ordering changes not showing up in diffs. If you find any other issues related to this deployment that do not go away after reloading/purging(add ?action=purge to the URL) the page please let me know here.

Cheers --Lydia Pintscher (WMDE) (talk) 20:44, 10 December 2013 (UTC)

Great! Two questions: Is there a page with info about ordering? Can someone shorten the table of content? Example German:

  1. Bezeichnung und Beschreibung in anderen Sprachen Andere Sprachen
  2. Aussagen
  3. Wikipedia-Seiten, die mit diesem Objekt verlinkt sind
  4. Wikivoyage-Seiten, die mit diesem Objekt verlinkt sind
  5. Wikimedia-Commons-Seite, die mit diesem Objekt verlinkt ist

--Kolja21 (talk) 22:40, 10 December 2013 (UTC)

I wanted to change it but I can't because this would change the headlines too. Can we use different translations for the TOC and the headlines? --TMg 00:05, 11 December 2013 (UTC)
@TMg: Für meinen Geschmack sind die Überschriften eh zu lang. Die engl. Fassung kommt mit der Hälfte der Buchstaben aus. Also, sei mutig^^ --Kolja21 (talk) 02:20, 11 December 2013 (UTC)
Will look into it. --Lydia Pintscher (WMDE) (talk) 07:29, 11 December 2013 (UTC)
Die "anderen Sprachen" hab ich verkürzt. Der Rest ist problematisch. Ich will auf keinen Fall "Verknüpfte Wikipedia-Seiten" oder so schreiben. Der Projektname muss meiner Meinung nach das erste Wort bleiben. Vorschlag: "Wikipedia-Verknüpfungen", "Wikivoyage-Verknüpfungen" und "Wikimedia-Commons-Verknüpfungen". Lydia? --TMg 14:11, 12 December 2013 (UTC)
Idealerweise würden die Überschriften angeben wie sie im Dokument und wie im Inhaltsverzeichnis aussehen. LaTeX kann sowas. Dadurch kann man dann eine gekürzte Version im Inhalstverzeichnis zB haben. User:Bene*: Willst du dir das mal anschauen? --Lydia Pintscher (WMDE) (talk) 14:36, 12 December 2013 (UTC)
Any guide on how to use these features, especially ordering, since it apparently obsoletes statementSort.js which is pretty much essential? Thanks --LBE (talk) 23:05, 10 December 2013 (UTC)
Took me minutes to manually move one single statement to the top of ethanol (Q153). I don't understand the new ordering feature... I'll keep using statementSort.js until further notice. LaddΩ chat ;) 23:41, 10 December 2013 (UTC)
The new sorting feature seems to be for multiple statements within a property, whereas statementsort.js is for sorting properties among each other. --Arctic.gnome (talk) 23:48, 10 December 2013 (UTC)
No you can also move whole groups of statements. Just move the top-most one up once more or the bottom one down once more. Still need to improve this obviously. --Lydia Pintscher (WMDE) (talk) 07:29, 11 December 2013 (UTC)
Just some feedback: on the technical side, this update made editing extremely slow and saving an edit now needs twice the time it needed before the update. In terms of policy, we need to set out when to mark a value as deprecated, normal or preferred. --Wylve (talk) 02:01, 11 December 2013 (UTC)
Will look into it. Thanks. --Lydia Pintscher (WMDE) (talk) 07:29, 11 December 2013 (UTC)
Speed is currently indeed unacceptable. We're trying to reenable the parser-cache asap but I don't yet know when. I hope within the next 2 days. Re-enabling it is unfortunately not simple because it was responsible for the issues you were all seeing last night where some parts of a page suddenly showed up in a different language. --Lydia Pintscher (WMDE) (talk) 11:23, 11 December 2013 (UTC)
Does someone want to start Help:Ranks (Help:Ranking?) and Help:Ordering? --Izno (talk) 03:42, 11 December 2013 (UTC)
Using the latest version of Firefox, Wikidata has become very, very slow since the update. Clicking on items, whether the same/new tab/window causes the screen to freeze (Firefox isn't responding), and the pages (esp. the statements) only then begin to load. This is quite annoying! Jared Preston (talk) 14:56, 11 December 2013 (UTC)
Yes we're aware and working on it right now. For the time being Chrome and Opera seem to work better. Sorry for the problems :( We're trying to fix them as fast as we can. --Lydia Pintscher (WMDE) (talk) 15:14, 11 December 2013 (UTC)
So this is for sorting statements of each item individually (& manually), all 13 millions of them ! Very different from statementSort.js, which applies predefined order to any existing item (so I get the order I know on any item I can open). NOT an improvement, so not a replacement. I'll keep statementSort.js if I can (and I would like it to ignore the manually defined order).
IMHO, Wikidata feature development should prioritize higher things which allows fast editing, import and verification of already supported information, and not add new types of information, which have to be (difficultly) edited by hand. --LBE (talk) 16:00, 11 December 2013 (UTC)
  • The code for statement ordering seems to clash with the AuthorityControl gadget — I am unable to save a moved statement's position (for strings which the AuthorityControl gadget acts on), though I can move the statement. --Izno (talk) 15:25, 11 December 2013 (UTC)

Firefox freezes opening an item in a new tab

Since yesterday, my Firefox freezes during 3-4 seconds each time I open a Wikidata item in a new tab. Is there anyone else having this problem? — Ayack (talk) 12:06, 4 December 2013 (UTC)

For small items, I don't see any performance change or freeze. However, for big items (with many statements, like countries), my Firefox today not only freezes, but even comes with a "Unresponsive script" warning dialog asking me whether I want to stop it (and if I choose to continue, it keeps freezing). This is using Firefox 25.0.1 on a high-performance Intel Xeon workstation utilizing 16 GB of RAM. --YMS (talk) 13:20, 4 December 2013 (UTC) PS: For me, it doesn't seem to matter whether I open such an item (like Q212) in a new tab or not. --YMS (talk) 13:23, 4 December 2013 (UTC)
Tha same for me, I confirm. --Accurimbono (talk) 15:36, 4 December 2013 (UTC)
Me too, I confirm Amir (talk) 16:18, 4 December 2013 (UTC)
Outsch. We're actually working on improving the performance. This shouldn't make it worse -.- We're looking into it. Sorry. --Lydia Pintscher (WMDE) (talk) 18:47, 4 December 2013 (UTC)
Just to confirm, I also get this quite often. -- Bene* talk 17:15, 6 December 2013 (UTC)
I reported the problem on bugzilla:58106, and attached a CPU profile, the screenshot of the Flame Chart and of the table of CPU usage by function. I used Google Chrome 31 to open the page https://www.wikidata.org/wiki/Q212?debug=1 and it took more than 4 minutes to load. Helder 18:40, 6 December 2013 (UTC)
Hmm, Opera is still the fastest browser (just joke, please not take it seriously) :) Full load of an average item (with ~ten statements and ~gadgets) takes 30 seconds. No freeze, but the process of loading statements is somewhat discouraging. Infovarius (talk) 13:12, 11 December 2013 (UTC)
In the past, I was often irritated about the slow loading of Wikidata pages, so it is very nice if this gets better. I also get often the message "Unresponsive script" from Firefox. Today even more than a while ago (my previous Wikidata session was in November). I mention that when I click to go on, it does not take a lot of time to finish the script. Bever (talk) 22:45, 14 December 2013 (UTC)

Database error

I got 

A database query error has occurred. This may indicate a bug in the software.

1.    Function: IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits)
2.    Error: 0

when searching for an edit by @Succu: in Property & associated namespace. Not sure where I am supposed to flag such things, so putting it here to get things going. --Daniel Mietchen (talk) 01:15, 15 December 2013 (UTC)

religious buildings and religion

Someone want to give some advice about how churches/cathedrals/mosques/shrines/... are assigned a religion, to a religious body. The property religion or worldview (P140) clearly specifies that it is for a person, whereas owned by (P127) may be somewhat appropriate, it seems a little clinical, and not always accurate. Advice welcomed.  — billinghurst sDrewth 00:52, 9 December 2013 (UTC)

My advice: change the description of religion or worldview (P140) and use it! — Ayack (talk) 13:56, 9 December 2013 (UTC)
Technically, a church building is owned (or controlled) by the respective church institution. So that proposal seems fine to me. --NaBUru38 (talk) 14:00, 9 December 2013 (UTC)
My issue about "owned by" is that the actual ownership can be a convoluted thing. Sometimes it is by the congregation, or by a parish, or by a diocese; sometimes by a church trust that itself has mysterious connections depending on how they are minimising tax. Each of those has a relationship to their respective religious body though clarity or obscurity exist.  — billinghurst sDrewth 23:40, 10 December 2013 (UTC)
@NaBUru38: Not necessarily. Churches (buildings) and chapels are/were often owned by the landlord, state, city etc. Synagogues of the past were often established in private buildings; even if they're property of the Jewish community today, it doesn't point out, which denomination of judaism uses them. About Mosque-Cathedral of Cordoba (Q33200) we can make a simple statement, that it was a Moslem religious building until 1236 and a has been a Christian religious building since. To find this simple piece of information in a list of owners (chalifs? kings? church? archbishops?) can be quite tricky. Thus my recommendation is the same as Ayack's - extend religion or worldview (P140) to the building (cemeteries, religious items and whatever necessary and use it. Or create a new property for the religious assignment of building; but it seems to me as superfluous.--Shlomo (talk) 20:35, 15 December 2013 (UTC)

Wikidata:Bots

How can we make it a Wikidata policy?--GZWDer (talk) 03:10, 15 December 2013 (UTC)

Have a discussion and then ratify it in an RfC.--Jasper Deng (talk) 06:02, 15 December 2013 (UTC)
I have draftted Wikidata:Requests for comment/Bot policy.--GZWDer (talk) 07:21, 15 December 2013 (UTC)
That was not well thought out. See Wikidata_talk:Requests_for_comment/Bot_policy#Wikidata:Bots. Legoktm (talk) 07:37, 15 December 2013 (UTC)
Notice that I said "discussion" first, which meant that the RfC should've been crafted according to what the community expects from it.--Jasper Deng (talk) 07:38, 15 December 2013 (UTC)

Q4387616

Hi! Please take a look at Q4387616. It seems that there are many odd issues, Regards לערי ריינהארט (talk) 22:20, 15 December 2013 (UTC)

It seems to be deep vandalism by several users. I've restored the last clean version. --Jakob (Scream about the things I've broken) 22:58, 15 December 2013 (UTC)

Collective echo notifications

Pretty often discussions here or on various other pages are related to an existing Wikiproject. I thought it could be useful to notify the project participants in a simple way and created {{Ping project}}. It invisibly transcludes the list of people stored in the [[Wikidata:Wikiproject <param1>/Participants]] page so that they get "you have been mentionned" notification. Thus {{Ping project|Visual arts}} notifies people listed on Wikidata:WikiProject Visual arts/Participants. Does that sort of thing sound useful ? -Zolo (talk) 10:34, 12 December 2013 (UTC)

Is it technically possible to ping a larger number of users at the same time? I have tried it once on WP, but I got no response. -- Lavallen (talk) 11:17, 12 December 2013 (UTC)
I have tried {{Ping project}} and it worked. According to the Echo doc, we get a notification whenever our user page is linked from a signed post in the Wikidata namespace. -Zolo (talk) 12:57, 12 December 2013 (UTC)
The ping template in enwiki only supports five users, so if you list ten users using that template there, only there first five will get a notification. But (as far as I know) that's no limitation of Echo, but simply of that template. Zolo's Ping Project doesn't have this limitation. --YMS (talk) 13:07, 12 December 2013 (UTC)
Ok, I did not use any template, I edited manually. Then, I {{Support}}! -- Lavallen (talk) 14:30, 12 December 2013 (UTC)
This is not very accessible. It might be better if we had a bot task to monitor heavily used talk pages for mentions of the WikiProject pages instead and then post notifications to dedicated talk pages?
As well, this forces a particular structure on the WikiProjects, which I don't see a reason for. --Izno (talk) 15:36, 12 December 2013 (UTC)
I do not think it is more complicated to uese "ping project|X" rather than writing out an equivalent sentence ("It may be worth mentionning this issue to members of project X"), and that does not require a bot. Imposing a particular structure to Wikiprojects is indeed a constraint, but I guess it could have other uses, say, raise a bot to send automatic newsletters based on smart dumps analyses to participants to the project (ok, I am getting a bit carried away on this one). --Zolo (talk) 17:53, 12 December 2013 (UTC)

I hope that Flow will eventually have a built-in system for instant and batch notifications for discussions involving many users. --Ricordisamoa 16:08, 16 December 2013 (UTC)

CheckUser

Hey all!

I think we're at a stage that it would be good to have local CheckUsers on Wikidata. While the work may not be very high at the moment, it would be great to have a total functionary team and it will be positive for Oversighters, if comes a situation where they need to do something together. However, it does not make sense to start any nominations before we have had this discussion to make sure do we need them or not at the moment. And about the policy, we already have it ready at Wikidata:CheckUser. So, please tell your opinion, do we need local CheckUsers now, and if not, then why not? --Stryn (talk) 21:19, 14 December 2013 (UTC)

  Oppose Next to no sockpuppets and we have some stewards who are active on Wikidata. --Jakob (Scream about the things I've broken) 21:26, 14 December 2013 (UTC)
  Oppose Firstly per Jakob. Secondly, I am not sure what you mean by "a situation where they need to do something together". Could you clarify this, please? I personally don't expect this project to ever have a need for a local CheckUser team as we have a comparatively small community. Vogone talk 21:55, 14 December 2013 (UTC)
To be fair, our community is already at least as large as Commons. The predicting factor should be the amount of abuse, not the community size (we're capable of electing functionaries, as we have done with oversighters). Wikidata is not currently under widespread use under phase 2 on most Wikipedias, where abuse is likely to hop over from.--Jasper Deng (talk) 22:15, 14 December 2013 (UTC)
Are you really sure about this? From what I saw Commons gets far more input in policy discussions, requests for permissions, etc. than Wikidata does. And it was really hard to get 25 users to vote for local OSes here either which would be unthinkable for a project like Commons or the other larger projects with functionaries. Vogone talk 23:12, 14 December 2013 (UTC)
I don't think so. Special:Statistics counts about 10000 active users here. If I'm not completely mistaken, this number includes everybody who once clicked the "Add links" link in the "In other languages" section of any Wikipedia or Wikivoyage in the last 30 days. Even without such effects, the same page on Commons counts 28000 active users. --YMS (talk) 23:23, 14 December 2013 (UTC)
  Oppose CheckUsers do not usually serve to complement the oversighters. We have had a total of two or three cases of sockpuppetry where it was not a cross-wiki or spambot case better dealt with by stewards anyways.--Jasper Deng (talk) 22:06, 14 December 2013 (UTC)
  Neutral To be blunt, I was really annoyed with the issue at [10], where the stewards basically prevented us from enforcing our local policies. And I don't think that it would be the worst thing in the world if we did get local CUs. With that being said, I don't know where we would get the candidates (since a lot of people seem to be of the opinion that local oversighters cannot run here, despite the high levels of cooperation necessary between the teams) and I don't think it would be used too much, at least not to the level of where we are using oversight right now. --Rschen7754 22:27, 14 December 2013 (UTC)
Or get the 25 votes for the candidates, as Vogone mentions. --Rschen7754 23:14, 14 December 2013 (UTC)
  Support To be brutally honest, I support the need for local CheckUsers. What Jakob said is true and false. Yes, we don't have 100s of sockpuppets every day but we have cases and when we do, we need to deal with them locally and make sure our policies are followed, not metawiki's as stewards usually do. What Jasper said again, true but when we have these issues, we need to deal with them locally. This is what Rschen said with linking to the recent sockpuppetry case. We had a user who was clearly violating our policies multiple times however we could not deal with them because the steward was following meta/other wiki policy which does not allow disclosure nor allow action for these offenses yet Wikidata does. While I do admit we do not have an active use, we do have a use for CheckUsers locally. John F. Lewis (talk) 22:40, 14 December 2013 (UTC)
  Oppose per King jakob c 2 and Jasper Deng. --Ricordisamoa 16:17, 16 December 2013 (UTC)

Comment on SamoaBot 32

See talk. --Ricordisamoa 15:36, 16 December 2013 (UTC)

The IP said the databases you want to imports takes their datas partly in ... Wikipedias, which imply a sourcing loop for some of the datas, so she not really for the import. TomT0m (talk) 16:28, 16 December 2013 (UTC)
@TomT0m: I actually read French quite a bit ;-) of course, I am asking you if we should avoid importing all those data just because of such little disagreement. --Ricordisamoa 18:42, 16 December 2013 (UTC)
I guess that is more a question about cataloguing rules for the libraries. If a library creates a new entry in the authority file (e.g. GND) it needs some source for the whole creation. Thus, it has to answer the question: on which sources do you rely that this person or term exists? Often the source for a person is the book, that has to be catalogued and of which the person is the author. In other cases, one can rely on an encyclopedias such as Brockhaus, Meyer, etc. Moreover, one will not find entries for recent stuff in traditional encyclopedias, therefore also Wikipedia some other websites are taken as source (sadly no date is added). This does not mean that every statement in the authority file is from that source.
The other concern in the French discussion is about data quality in general and for the nationality in particular. Since you want to import birth and death dates, I don't see an immediate problem. --Zuphilip (talk) 18:59, 16 December 2013 (UTC)

Common knowledge

Hi! maybe it's just my first Interwiki conflict but its kind of ironic to have no clear concept of "common knowledge" when it is refered to at Help:Sources/Items not needing sources. There is common knowledge (Q1116133) and there is general knowledge (Q1930471), both explicitly statet as distinct at en:Common_knowledge. I just removed the interwiki-Link from common knowledge (Q1116133) to de:Common Knowledge because the later is a specific term only used in game theory. I cannot judge whether this equals to common knowledge (Q372650). Anyway one should be clear about what knowledge is refered to when used to justify the lack of sources. Maybe we should better refer to I know that I know nothing (Q259588) instead of any kind of "common knowledge"? -- JakobVoss (talk)

Your general remarks are something to ponder about. The boundary between common knowledge (in the general sense, not the game-theory meaning) and general knowledge is of course blurred, since what exactly is considered "known by everyone" depends on your environment. The typical example of common knowledge not needing a source is "Paris is the capital of France" (this example came to my mind before reading the Wikipedia page, so the example is rather common  ;-) as well), but I would not be able to serve a meal to all people in the world who do not know thát.
In the meantime, I have added the German page you mentioned to common knowledge (Q372650). Some authors it refers to (D.K. Lewis, Aumann) are the same as in en:Common knowledge (logic) and although the German article mentions some differences ('Er [i.e., D.K. Lewis] misst dem Begriff jedoch eine ganzheitlichere Bedeutung zu als eine rein spieltheoretische.'), the English article is not only about logic in general but also about game theory, so I think tey correspond enough to link them. Bever (talk) 01:16, 17 December 2013 (UTC)

Instance of capital

In Umeå (Q25579) a user has added instance of (P31) ducal (Q4994447) and instance of (P31) chef-lieu (Q956214). Both ducal (Q4994447) and chef-lieu (Q956214) can be regarded as subclasses of Capital so it looks ok to me.

But how are we supposed to tell which entities Umeå is capital of? I know it is Umeå Municipality (Q507709) and Västerbotten County (Q104877) (and maybe some more), but I would like to get some advise of how to write it, so everybody here add this information in the same way. -- Lavallen (talk) 19:51, 13 December 2013 (UTC)

Use of (P642) as a qualifier? Filceolaire (talk) 21:27, 13 December 2013 (UTC)
Add Umeå Municipality (Q507709) capital (P36) Umeå (Q25579) and Västerbotten County (Q104877) capital (P36) Umeå (Q25579) instead ? --Zuphilip (talk) 23:37, 13 December 2013 (UTC)
The problem with that, is that it does not tell which kind (subclass) of capital it is. -- 78.73.94.165 08:00, 14 December 2013 (UTC) (Lavallen)
That's what the proposed "specifically" qualifier property is for. Filceolaire (talk) 14:09, 14 December 2013 (UTC)
How are we supposed to get that information from Umeå (Q25579) then? - Lavallen (talk) 17:21, 14 December 2013 (UTC)
With 'What links here'? (I mean the first option in the tools section of the navigation bar on the left of the page, or Special:WhatLinksHere/Q25579. I have heard rumours that in the future, properties will be bidirectional.
I think using capital (P36) is logical: the administrative unit is the primary place where we would want to store this relationship, not the capital.
@78.73.94.165:: that it doesn't tell what 'kind' of capital it is, is not a big problem in my opinion. You meant probably the level of administrative division: country, province (in this case, län), municipality. But for example, Umeå (Q25579) tells that it is located in the administrative territorial entity (P131) in Umeå Municipality (Q507709). It is not immediately visible that the latter is a municipality. One cannot always have everything at once. Bever (talk) 06:05, 15 December 2013 (UTC)
No, I do not mean the 'level of administrative division'. I am talking about which function the capital has. In a County seat in Sweden, there is a recidence for the governor. A Municipality has no recidence for the executive chief of the Municipality. Instead is the capital the location of the administrative center. In a Civil parish, the capital is the natural gathering point of the citizens, normally the village the local Lutheran church is located in. This makes that a County always have only one capital, a Municipality can have several, and a civil Parish can have none at all. A Swedish Province never have a capital. This makes that we in Sweden have different names for the county seat in California compared with a county seat in New England. -- Lavallen (talk) 14:23, 17 December 2013 (UTC) (also known as 78.73.94.165)

Bot to handle new articles?

Hi everyone, over the last year most Wikipedia articles (and categories) have been connected with items here on Wikidata. I think it's safe to say that the initial article import is done, but new pages are created every day. We should probably have a bot keeping an eye on all newly created Wikipedia articles and connect them to items here or create new items. Preferably a bot running under a shared project on Toollabs. Has anyone already looked into this? Anyone willing to help out here? Multichill (talk) 16:48, 15 December 2013 (UTC)

Hi. Reza has written a code in order to do that (User:Reza1615/BOT/new interwiki.py) I know it has been used in several wiki but I can work on it and make it better and we can run it in a shared tools service group. Amir (talk) 16:52, 15 December 2013 (UTC)
We should only import articles older than about 10 days to avoid creating items for articles that get speedies or prodded. --Jakob (Scream about the things I've broken) 17:51, 15 December 2013 (UTC)
What is so bad about short-living items? I doubt it is a question of storage space. Vogone talk 17:54, 15 December 2013 (UTC)
It is not so much a problem of storage, it is a problem of time of a deleting administrator. If the article gets deleted, in 99,999% cases nothing happens to the item here, until a bot finds it, deletes the item, and then another bot sometimes nominates it for deletion. Then we get an empty item where the history needs to be checked to make sure it was a legitimate link removal and not vandalism. I think it is better if obvious garbage does not make it here in the first instance. (This is not even to mention BLP vandalism issues).--Ymblanter (talk) 19:22, 15 December 2013 (UTC)
Well, if it is already a bot which adds the items, why shouldn't it be allowed to delete these items again if no human-made edit followed in the history and the page for which it was created got speedy deleted? Vogone talk 20:46, 15 December 2013 (UTC)
If we permit this, I agree to the package.--Ymblanter (talk) 21:20, 15 December 2013 (UTC)
I didn't go into the details how such a bot would run. Some points:
  • Wait at least n days (n=10?) before creating a new item, this gives users time to connect
  • If a page is connected to another language using an old interwiki link, that page is linked to an item here and no conflict, than link it
  • If a page is tagged for deletion, stay clear of it (if the page is kept the bot will find it again)
  • The bot should probably only edit here to stay clear of the rules of 200+ Wikipedia's
Multichill (talk) 21:55, 15 December 2013 (UTC)

I'll write a code for doing this task very soon. Best Amir (talk) 13:43, 17 December 2013 (UTC)

Help merging Pèire Leturaire/Pierre Letuaire

Please, does anyone can help me wiht merging Piere Letuaire french page into Pèire Letuaire occitan page (or vice versa) since I've never done that before.

Many thanks, --Lembeye (talk) 14:44, 17 December 2013 (UTC)

  Done. Merged Q12950105 into Q8341184. See Help:Merge for how to do this yourself next time. With the merge gadget mentioned there, it's basically one click. --YMS (talk) 15:05, 17 December 2013 (UTC)

Many thanks, --Lembeye (talk) 15:12, 17 December 2013 (UTC)

How to create a new statement for fgkz (a administrative number for rivers and streams in germany)

I'm new to wikidata and I couldn't find a statement for the FGKZ (Fließgewässerkennzahl) which is a administrative number for rivers and streams in germany. Its hierachical ordered, beginning with rivers going into the see. Every sidearm of a river or stream adds a numer and so on. Most of the articles about rivers and streams of germany already have these numbers. Does it make sense to add these and what additional information is needed? Ogmios (talk) 19:59, 16 December 2013 (UTC)

This sounds like a property of rivers. Have a look at already created properties Wikidata:P. Maybe, you don't find the property you are looking for, then you can suggest to add it there as well: Wikidata:Property_proposal. Please read the steps before property creation there. --Zuphilip (talk) 22:23, 16 December 2013 (UTC)
thx Ogmios (talk) 09:47, 18 December 2013 (UTC)

Cyrillic search

How can I find items which contains "описание структуры" in description? Search still doesn't work at all for cyrillic. --Infovarius (talk) 13:15, 18 December 2013 (UTC)

Did you activate the "New search" in the "Beta" features section of the preferences? I get 23 results for that search. --YMS (talk) 13:20, 18 December 2013 (UTC)

Bot for new pages, Done!

Hello all, I just finished a script for connecting new pages of Wikipedia sites to Wikidata, What this bot is doing It checks new pages (pages less than one month and more than ten days old) and checks if it isn't marked for any kind of deletion, tries to add it to Wikidata. the algorithm of adding is a little complicated but you can see the results of running the bot on English Wikipedia [11] (these are just results of making new items and they are not included connecting via adding site link to an existing item) just these optional l10n can help us connect Wikipedia and Wikidata even more:

  • basic templates of deletions (e.g. for English Wikipedia it's "'Db-meta','Article for deletion','Proposed deletion'" these names are enough even as a part of the template title)
  • is it okay to create a new item if no interwiki was found? I set it True for the first twenty wiki (by size) and False otherwise
  • ways to add very basic information:
    • being a disambiguation: No l10n needed
    • being a biography: for example finding these regex is enough for English Wikipedia article "\[\[[Cc]ategory\:\d{1,4} births" but about other languages we can obtain this from interwiki links of years like Category:1912 births (Q9710085)

Besides all of the functions the bot reports if It couldn't find any interwiki but it found hard URL to another wiki (e.g. User:Ladsgroup/en for English Wikipedia)

Any comments are welcome @Multichill: yours specially :) Amir (talk) 17:38, 19 December 2013 (UTC)

computer sequrity

i

I'm not sure how we can help you here. Could you explain your problem further, please? Vogone talk 12:22, 20 December 2013 (UTC)

Draft name space

As some of us probably know yesterday the Draft: namespace was introduced on the English Wikipedia. Are articles in the Draft namespace notable for Wikidata? I would say not because they are mainly former AfC articles which were not notable, but let us discuss.--Ymblanter (talk) 16:11, 19 December 2013 (UTC)

No, they are not notable because they are not finished articles and are subject to change/deletion. I suggest that we append Wikidata:Notability/Exclusion criteria with something about the Draft namespace (or drafts in general). The Anonymouse (talk) 16:17, 19 December 2013 (UTC)
One idea would be to not create items solely for draft articles, but to include draft article links into existing items. Maybe a technical restriction could be implemented, so that the interwiki links are displayed in those draft articles, but not in the existing articles to the draft articles. --YMS (talk) 16:20, 19 December 2013 (UTC)
Indeed, this is why I asked this question.--Ymblanter (talk) 16:23, 19 December 2013 (UTC)
I support YMS's idea. --Jakob (talk) 16:28, 19 December 2013 (UTC)
So let's say that Draft links are not notable in themselves, but can still be used in other items that are already notable. That way the links can be added to existing items, but cannot be used by themselves to make an item notable. Does this make sense? The Anonymouse (talk) 17:15, 19 December 2013 (UTC)
Yes.--Ymblanter (talk) 17:19, 19 December 2013 (UTC)
One drawback of not creating items for draft articles would be that once some infoboxes etc. get their data from Wikidata, some draft articles (using the solution I proposed: the ones without interwiki links, using the "no draft links in Wikidata" rule: all drafts) could not have a proper infobox, or the infoboxes for draft articles would have to be filled manually and then cleared once those articles get released by moving them into the article namespace. We can ignore this (as the same problem currently exists if an article is prepared in user namespace), but that could be a pitfall especially for new editors. --YMS (talk) 08:17, 20 December 2013 (UTC)
I support YMS' opinion. --by Revi레비 at 05:14, 21 December 2013 (UTC)
  • In my opinion, drafts should not use Wikidata because a fair portion of them get deleted (and many have sourcing problems, limiting the usefulness of any data they might contain).--Jasper Deng (talk) 08:19, 20 December 2013 (UTC)
  • Whatever the status of an article, when there is only one article (draft or otherwise) it is ok to link it to Wikidata. I would argue that even red links should be linked to Wikidata. This would make linking to information not in a Wikipedia but in Wikidata possible. As long as there is ONE article by a name, it should be linked. GerardM (talk) 14:33, 21 December 2013 (UTC)
Remember, this is Wikidata NOT Wikipedia and its policies are manifold and inconsistent as a totality. GerardM (talk) 14:33, 21 December 2013 (UTC)

Where did Wikipedia's Special:RecentChanges go?

One of Wikidata's core functions is to link pages on Wikipedias, but now da:Speciel:Seneste ændringer and en:Special:RecentChanges have no link, and it appears that Special:RecentChanges have been removed altogether. Why? And when/where was that decided? --Palnatoke (talk) 11:43, 20 December 2013 (UTC)

Q6293548, https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_deletions&oldid=94602363. It was deleted on Wednesday. Matěj Suchánek (talk) 11:49, 20 December 2013 (UTC)
The dawiki page appears to have links and on enwiki I already asked the admin who removed the links to readd them. Unfortunately, he hasn't done it yet. Vogone talk 11:51, 20 December 2013 (UTC)
Yes, I re-added the links on dawiki, because Wikidata failed. I find the deletion silly, bordering on stupid. --Palnatoke (talk) 11:57, 20 December 2013 (UTC)
I guess Wikipedia's front pages will be deleted next.. <shaking head> --Palnatoke (talk) 11:59, 20 December 2013 (UTC)
Thank you for this incredibly constructive comment. Vogone talk 12:00, 20 December 2013 (UTC)
You're welcome. When a project fails in this magnitude, constructive comments are rare. --Palnatoke (talk) 12:32, 20 December 2013 (UTC)
Do you have a count of the number Wikipedias affected by this deletion? Have you, in any way, warned these communities that you planned to remove the links? --Palnatoke (talk) 13:15, 20 December 2013 (UTC)
The wikis were affected by this item's creation, not deletion. We just restored the initial situation. Vogone talk 14:05, 20 December 2013 (UTC)
The creation in it self did not break anything, since every wiki can overwrite the interwiki. The deletion breaks status quo. --Palnatoke (talk) 14:07, 20 December 2013 (UTC)
The default status was not to have any interwiki links on special pages which was restored now … Vogone talk 14:23, 20 December 2013 (UTC)
I think the page should be restored. --Rschen7754 19:06, 20 December 2013 (UTC)

I think the idea that the special pages should not have language links are sound as they are not entities, but as one of the core features of Wikidata is to replace the iw-links it is not wise to make it deliberatly break in this respect. Keeping the items makes no harm, deleting them does. I agree with Palnatoke, the deletion should be reverted. Jeblad (talk) 19:11, 20 December 2013 (UTC)

What do you mean? It is better that all Wikipedias get overloaded by hundreds of useless interwiki links which weren't there before? And I'm not sure what harm this deletion caused. Do you mind explaining? Anyway, special pages are not notable for Wikidata according to our policy and thus I don't think it would be really senseful to restore. Vogone talk 19:20, 20 December 2013 (UTC)

I have restored the item for now. 4 in favour of deletion with 3 against does not seem like a consensus. Plus this deletion has a significant impact on all wikis hosted by Wikimedia and enabled with the Wikibase client. A discussion of around 4 hours is in no way extensive enough to decide whether an item should be deleted as is without it being uncontroversial. John F. Lewis (talk) 19:25, 20 December 2013 (UTC)

You know that this item is still against our notability policy and there was still no consensus provided in favour of adding this item to our inclusion criteria? Vogone talk 19:28, 20 December 2013 (UTC)
Well, if the community objects to the deletion of the item, it overrides notability really. John F. Lewis (talk) 19:29, 20 December 2013 (UTC)
I'm not sure whether it is good to let only 4 people decide over 700 wikis … Vogone talk 19:31, 20 December 2013 (UTC)
Who deleted an item after 4 people people said delete after 4 hours? You. John F. Lewis (talk) 19:32, 20 December 2013 (UTC)
Again, this item is against our notability policy and only 3 people caused it to be exempted from this policy. That's where the problem starts. Vogone talk 19:34, 20 December 2013 (UTC)
What? So we just blindly follow the rules and that's it? I thought that common sense was above all of our rules. — ΛΧΣ21 19:42, 20 December 2013 (UTC)
Yes, using common sense was the reason why I proposed the deletion of this item :) It just breaks skins and overloads hundreds of small wikis with unnecessary iw links. For big wikis, it rather makes only a little difference thanks to their big communities. Vogone talk 19:44, 20 December 2013 (UTC)
I disagree. The item does not flood small wikis with "unnecessary" links, as they are necessary. The very existence of Wikidata depends on that, and RecentChanges is one of the important pillars of the Mediawiki software. Your very same argument could be extended to all big pages such as the Main Page, for example. — ΛΧΣ21 20:13, 20 December 2013 (UTC)
Well, if someone was done against consensus, doing something when people disagree around 6 months later causes nothing but problems. John F. Lewis (talk) 19:36, 20 December 2013 (UTC)
The answer is to have a discussion about this when an item is so widely used, rather than just deleting it because "you didn't follow the rulez!" --Rschen7754 19:37, 20 December 2013 (UTC)
Thank you for your efforts. Vogone talk 20:40, 20 December 2013 (UTC)
Created, will transclude in a second. I do not mind changing the structure by any user, for obvious reasons this is not a question I had much time to think about.--Ymblanter (talk) 20:54, 20 December 2013 (UTC)
mw:Compact interlanguage links as a beta feature! Multichill (talk) 12:22, 21 December 2013 (UTC)

Topic clash

Items Q13576192 (nl:Electra (ster) only) and Q13429 (en:Electra (star) and many others) refer to the same object. How to proceed? Kleuske (talk) 17:49, 20 December 2013 (UTC)

Maybe with a merge ? :) I have merged them. --ValterVB (talk) 17:59, 20 December 2013 (UTC)
Ah. Ok. I was focussed on another job and more or less stubled across it. Wikidata isn't my usual stomping ground. Thanks for resolving it. Kleuske (talk) 15:15, 21 December 2013 (UTC)

list

seems User:Byrial not update his useful lists for a while, can anyone C expert continue his work? --Rippitippi (talk) 06:18, 22 December 2013 (UTC)

The source codes uploaded at his toolserver account are from August at the latest. In September he wrote that he has to update them to work with the new dumps. If he did do some work in this regard, it's not online. If he didn't do, someone else probably has to do it if he/she wants to go on publishing the reports. I just mailed Byrial to ask about the state of the script (and himself). --YMS (talk) 12:53, 23 December 2013 (UTC)

Birth day : fictional universes task force

Hi, just created Wikidata:Fictional_universes_task_force, pretty empty yet, but I know there has already been a lot of discussions about this subject here and there, about fictional calendars for example. Of course, it's a Wiki page, so if you know anything about current practices on Wikidata or have question, please contribute. TomT0m (talk) 18:11, 22 December 2013 (UTC)

Sex and gender

Significant changes are being considered to P21. There are two broad proposals for how to improve structured data for people for whom biological sex does not match cultural gender. This effects all items about people on Wikidata. Please see Wikidata:Property_proposal/Person#gender. Thanks, Emw (talk) 06:07, 23 December 2013 (UTC)

Emw we just had a detailed and lengthy discussion of this very item on Property_talk:P21#Transgender_.2F_Cisgender_changes. I posted a detailed response to your arguments there a week ago and have had no response from you. Starting a new discussion somewhere else at this stage seems like forum shopping. Filceolaire (talk) 11:48, 23 December 2013 (UTC)

loading Template:Link FA and Template:Link GA

Is it possible to load en:Template:Link FA and en:Template:Link GA from wikidata for articles? for example in e.wiki: for en:United States it loads {{Link GA|ca}} {{Link GA|da}} {{Link GA|es}} {{Link GA|fi}} {{Link GA|lt}} {{Link GA|nah}} {{Link FA|an}} {{Link FA|ar}} {{Link FA|ceb}} {{Link FA|eu}} {{Link FA|fa}} {{Link FA|fo}} {{Link FA|lv}} {{Link FA|ml}} {{Link FA|pt}} {{Link FA|sl}} {{Link FA|sq}} {{Link FA|vi}} {{Link FA|es}} {{Link FA|af}} {{Link FA|eo}} form wikidata. Yamaha5 (talk) 10:57, 23 December 2013 (UTC)

This (or something similar, probably making those templates completely obsolete, I guess) is part of the "sitelink badge" feature (see Help:Sitelinks#Badges). It's planned and it regularly turns up in Wikidata:Status updates, however, it's not finished yet and I don't know when it will be. --YMS (talk) 11:44, 23 December 2013 (UTC)
One of the most asked questions :) Btw: Bugzilla:40810. --Stryn (talk) 14:03, 23 December 2013 (UTC)

Questions about a new property

Hi, I am a wikidata newbie. I have been looking through your help documentation for a few hours, and can't find the answers to the questions I have. My questions are about NLM Unique ID (P1055), and the list below is a revised version of what I wrote here. The questions here are more general, but NLM Unique ID (P1055) is a "case study".

[Pinging @Bluerasberry:, @Daniel Mietchen:, because maybe they'll be interested.] Thanks! Klortho (talk) 07:28, 22 December 2013 (UTC)

(replying point-by-point):
  1. The URL is created by the gadget AuthorityControl. The URL can easily be changed in the JavaScript code of the gadget.
  2. A RfC has been held about storing better documentation for properties, but the functionality has not been developed yet. Until then, the talk page is the only place. In the meantime, if you have any documentation for a specific property, you can place it on the talk page below the template.
  3. Constraints are sometimes used, which are useful for data validation. See P21 (sex) for an example.
Hope that helps, The Anonymouse (talk) 07:54, 22 December 2013 (UTC)
Klortho, I've expanded the examples in the 'domain' parameter to indicate that it is not restricted to the types from P107 (P107) (diff). P107 had several useful values, but 'term' is not an appropriate domain (or range). A more specific value like astronomical object (Q6999) or disease (Q12136) is better than term (Q1969448). Emw (talk) 17:18, 22 December 2013 (UTC)
Thanks, both of you, for the help. Regarding the Gadget-AuthorityControl.js, I think it would be nice if the URL could eventually be generated from a property on a property, that would take the value of a URL template, but I seem to remember reading somewhere that properties on properties are not implemented yet.
Regarding "domain": so, it doesn't have any "normative" effect, it is just documentation, right? I just wrote a suggestion about it here.
Klortho (talk) 23:15, 22 December 2013 (UTC)
Klortho, I think 'domain' does have normative effect, it's just not very enforced most times. For example, it could be used to generate constraint violation reports, which could be used as a way to help manual, semi-automatic or fully automatic curation. Beyond the primitive state of tools, I think another reason domain isn't very enforced is that we as a community often don't have a good sense for the appropriate value for domain.
We do have properties of properties -- domain is a great example. They're not supported in Wikibase itself, though, and likely won't be for quite a while. Your idea to decentralize URL handling to individual properties' documentation templates would be helpful. Instead of having one central repository for rules, the rules could be spread to each documentation template, and a bot could routinely scrape the rules from each property and centralize them. That way we would only need 1 additional HTTP request for an item with N properties, rather than N requests. Changing property documentation -- which could reside in a subpage of the property talk page -- could be restricted to autoconfirmed users. Emw (talk) 23:46, 22 December 2013 (UTC)
I'm glad you like the idea of decentralizing the URLs, and I like your idea about keeping them along with the properties' documentation, but I'm not sure it would be worth it now. Glancing through the Gadget-AuthorityControl.js, I see a lot that aren't simple substitutions, but actually have some tricky Javascript. So you'd either have to allow Javascript functions for those (which wouldn't fly, because it would be a huge security hole, even if it were restricted to autoconfirmed) or make up substitution parameters for each of the functions in use. Actually, that might be an argument for doing it sooner rather than later, to keep the URL rewriting from getting out of hand. Klortho (talk) 01:48, 23 December 2013 (UTC)
Regarding the property documentation, I just created this new RfC, Property documentation redux. Klortho (talk) 06:43, 23 December 2013 (UTC)
  • I am interested in this but like with so many things about Wikidata, I read these proposals, feel that they are relevant, and then fail to understand what is going on. I am not sure how to respond or what to ask to clarify my thoughts. Blue Rasberry (talk) 02:42, 24 December 2013 (UTC)
Well, I'm just learning the ropes, myself, and I know you are new too, so I thought you might be interested. The main issues here are about how authority control properties (IDs that link items to other databases, like the NLM Unique ID (P1055)) are: A, documented; and B, linked to those other databases. Regarding the documentation, I think it should be on par with template documentation in Wikipedia, but right now it is pretty inadequate, so I opened Property documentation redux. As for linking, the URLs are built by the Javascript gadget, which is an okay solution, but might not scale very well in the future. Klortho (talk) 04:16, 24 December 2013 (UTC)

missing fonts

Hi, just realized that some fonts are missing on wikidata that work on wikipedia. example: go to [12] and copy his name in the Khmer characters over to alias on Q369942 and see. May want a Bugzilla for this, the reason are probably missing font packages on the wikidata servers. Mutante (talk) 17:40, 22 December 2013 (UTC)

servers are often out by at most a week. Check in a weeks time.. GerardM (talk) 07:20, 24 December 2013 (UTC)

A year

Hoi, we are nearing the end of 2013 CE. When you look at the item for that year, you find that it is defined as a year. I blogged about the year 1328 HS and come to the conclusion that the definition used for a year is wrong. A year is NOT to be exclusively associated with the Gregorian calendar. I intend to change this. Thanks, GerardM (talk) 09:40, 23 December 2013 (UTC)

Who said a year is exclusively associated with the Gregorian calendar? It's not true at all: Romans sure didn't use the Gregorian calendar, yet they adopted the year as unit of measure of time. And this applies to all types of calendar... sorry I don't think your reasoning makes sense. — TintoMeches, 10:53, 23 December 2013 (UTC)
In my opinon 2013 needs to be "instance of = gregorian/julian year". For other calendars e.g. 1328 SH (Q5936312) "instance of = modern Iranian calendar year" seems more appropriate. We just need to create the item I guess. --Tobias1984 (talk) 10:58, 23 December 2013 (UTC)
No. 2013 (Gregorian) and 2013 (Julian) have different start dates and end dates so they need different items. 2012(Gregorian) and 2012(Julian) (if it exists) should be an 'instance of (P31):leap year (Q19828)'. 2013(Gregorian) and 2013(Julian) are an 'instance of (P31):common year (Q235729)'.
Leap Year and Common Year both have clear definitions and should I believe be used for Gregorian and Julian years. The simple 'year' item can mean a lot of different things and is probably better treated as a class item with both 'leap year' and 'common year' being 'subclass of:year'. OK? Filceolaire (talk) 11:18, 23 December 2013 (UTC)
Ok for me. — TintoMeches, 11:47, 23 December 2013 (UTC)
How do you define a "leap year" ? Gregorian and Julian are not the only years that leap when needed.. GerardM (talk) 07:18, 24 December 2013 (UTC)

This is how I think a year should have its statements... 1328 SH. GerardM (talk) 09:43, 24 December 2013 (UTC)

instance of (P31)year (Q577) is not specific enough, I think. Perhaps one form of "X calendar year" should be created per calendar to replace year (Q577), with each of those being a subclass of calendar year (Q3186692) (which is itself a subclass of year (Q577)). --Yair rand (talk) 18:30, 24 December 2013 (UTC)

How do I get a list of Wikipedia articles in language X that are not in language Y?

I am interested in translating articles but can't seem to be able to find a feature that lets me see all the articles for example in Arabic that are not in English. Rakkalrast (talk) 15:32, 18 December 2013 (UTC)

Rakkalrast: That will be possible (I believe) when queries are available, in the (hope not to be so distant) future. Cheers. — ΛΧΣ21 05:10, 19 December 2013 (UTC)
This tool may help for now. [13]. Del♉sion23 (talk) 11:30, 19 December 2013 (UTC)
There are some older lists (listing most popular items without link to language), but not to arwiki. --Jklamo (talk) 12:35, 19 December 2013 (UTC)
See also this tool and toollabs:ptwikis/common-iw:ar. Helder.wiki (talk) 19:37, 24 December 2013 (UTC)

Stated-Implied Pairs of Properties

Many properties appears in pairs, or sometimes one-to-many relations. For example: contains the administrative territorial entity (P150) implies located in the administrative territorial entity (P131) from the other side; father (P22), mother (P25) each implies child (P40) from the other side. Leaving these stated fact and implied fact unlinked will allow many mistakes to be made, slow down the updating of information and sometimes hide useful information.
My suggestion is to define "Implied Converse" properties which disallows all direct manual updates but update them by the machine to synchronize the underlying "Stated" property. With this construction, located in the administrative territorial entity (P131), child (P40) will no longer require manual care, and editors will no longer need to visit both pages for updating such relation.金亦天 (talk) 07:27, 23 December 2013 (UTC)

Alternatively could we extend 'What links here' to show properties which link to an item? Filceolaire (talk) 11:36, 23 December 2013 (UTC)
For sure 'what links here' grouped by properties should be displayed. But I think a more direct display inside the statement panel is more preferred since that will be part of the basic understanding of the item. The actual implication is not important and a simple one can be using a query on the link table. What I really care is what editors can see and do.金亦天 (talk) 14:05, 23 December 2013 (UTC)
There is a big for this in Bugzilla, I believe. --Izno (talk) 23:10, 24 December 2013 (UTC)

Language links without a corresponding article

I'd like to add the Gujarati term for sherwani to Q837879, but that article hasn't yet been created on the Gujarati Wikipedia. The sitelinks help page says "only add languages if a page on that language version of Wikipedia exists," but I could have sworn I read about a month ago about that Wikidata was starting to accept localized terms in all languages. Am I imagining that? —Neil 07:31, 24 December 2013 (UTC)

We do have labels, which is what you want to add and what you - of course - are allowed to. And we do have sitelinks. I think the help page you've linked unnecessarily mentions that you should only add sitelinks if there is an article in that language - as because there is no Gujarati article for that item, you can't add one anyway. Also the next sentence is "The linked page should be an existing page", but it's simply not possible to add non-existing pages. So just go on with adding your label. --YMS (talk) 07:50, 24 December 2013 (UTC)
Okay, thanks for the clarification. But I'm still a bit confused since the page you linked to says that each page has only one label, and that should be the most common English term. Do you mean alias, and if so, how do you indicate which alias a language is in? I just tried adding it, and my edit summary is "added English alias," which doesn't seem right. —Neil 16:58, 25 December 2013 (UTC)

Xmas troll : Santa Claus (Q315796)

Is he really a fictional character ? Think of the childrens who read Wikidata ! /o\ TomT0m (talk) 17:04, 24 December 2013 (UTC)

For the children: The statement is missing a source, so we don't know if he is fictional or not :) --Tobias1984 (talk) 17:15, 24 December 2013 (UTC)
At least Joulupukki (Q946762) is a real :P --Stryn (talk) 17:50, 24 December 2013 (UTC)
@Stryn: What's the difference between Joulupukki and Julbocken? -- Lavallen (talk) 18:35, 24 December 2013 (UTC)
Joulupukki is like a "Finnish version" of Santa Claus. Julbocken is a goat made from a straw (at least if I understand something from the Finnish article)? But "julbuck" means literally "joulupukki". --Stryn (talk) 18:51, 24 December 2013 (UTC)
Well, the Swedish Julbock distributed the X-mas-gifts long before a oversized tomte did it. The Swedish "Julklapp" comes from the knocking on a door by a goat, not by a troll. -- Lavallen (talk) 18:56, 24 December 2013 (UTC)
Created mythical character (Q15410431) and changed Santa to an instance of this. Filceolaire (talk) 12:23, 25 December 2013 (UTC)

dates revisited

Hoi,if there is one thing that I learned about the "year" issue, it is that a year like 1346 does not work when it is an item. It should be 1346 AD or 1346 HS. All years should have their primary label with the inclusion of an indication of their label. To keep it easy on users, the date can have an alternate label of 1346 for any calendar.. Thanks, GerardM (talk) 14:05, 24 December 2013 (UTC)

We can have duplicate labels. That's what the description is for. We should stay consistent with this. --Tobias1984 (talk) 16:28, 24 December 2013 (UTC)
We agree that we can have duplicate labels. For this reason the labels 1346 will still be there but the dominant label will be for instance 1346 HS. Thanks, GerardM (talk) 17:00, 24 December 2013 (UTC) PS this is a perfect job for a bot so we will stay consistent.
I think it would be preferable to keep the plain number form as the label, and make the other versions aliases. --Yair rand (talk) 18:24, 24 December 2013 (UTC)
Why? GerardM (talk) 21:33, 24 December 2013 (UTC)
Because the numbers are the primary name. It is comparatively rare to add the "AD" or other prefix. If they appear in a list, infobox, etc. the expected value is the number form. There is no reason to prevent multiple items from having the same label. Are there any arguments in favor of adding the suffix? --Yair rand (talk) 22:37, 24 December 2013 (UTC)
When a date has an indication of the calendar it belongs to, it helps understanding and it does not distract. You assume that everywhere an infobox will use a common era date. This is just not true. From an application point of view, the current standardisation on the Gregorian dates is wrong. It introduces errors and it reduces precision. Thanks, GerardM (talk) 23:15, 24 December 2013 (UTC)
How it is standardization on Gregorian dates? I would not expect any calendars to use suffixes in their labels. (I don't think the Hebrew calendar even has a usable suffix, so it wouldn't even be an option for that one...) I don't see how it could introduce errors, either. If you're talking about when adding data to Wikidata, aliases can be used for searching just as well as labels, and descriptions are always shown beneath the label anyway. --Yair rand (talk) 23:29, 24 December 2013 (UTC)
I tend to agree with GerardM that years should have a suffix indicating the calendar. The problem is getting consensus on whether to use AD or CE. I think this might be a big enough problem that we should go back to bare numbers. Filceolaire (talk) 12:31, 25 December 2013 (UTC)

I think the label is chosen by the language natives, so I see no point into precising the calendar in the label if all the speakers of this language use the same calendar. I you say "year 2000" in france, in quebec or in any other french speaking country, there is no problem. If the calendar is an exotic one, we could (must?) be more precise. TomT0m (talk) 22:30, 25 December 2013 (UTC)

I agree. The 'AD'/'CE' disagreement seems to be mostly an English Language thing. Filceolaire (talk) 14:32, 26 December 2013 (UTC)
I'm not sure if this is true. For example in the German language, there are quite direct translations for "AD" ("n. Chr.") and "CE" ("u. Z." or "n. d. Z."), and while the AD one is clearly the dominant one, also the other ones are used to a certain degree. However, similar as TomT0m says, both would be used around the year 1 only and it's highly unlikely that anybody ever would put such a suffix to the year 2013. --YMS (talk) 15:04, 26 December 2013 (UTC)

Shameful issues

I've been ading thousands of items here, but when I try to change some item with larger number of languages it simply can't open. It happened with Saturn and Jupiter, and now it's happening again with Germany (Q183) - Mozilla simply can not open it. This is really shameful and it makes Wikidata completely useless. --Orijentolog (talk) 15:23, 24 December 2013 (UTC)

Hi. These problems are known and hopefully will be fixed soon. However, it's only performance problems. It should be possible to open these items, though it may take some ime and/or the browser might freeze. In case Firefox is asking you whether it should stop some running scripts, choose "Yes". Otherwise waiting some seconds should do the trick. If that does not work for you it's sad, but there's probably not much that we can do shortly. Keep in mind that it only affects some of the bigger items (next to planets, countries and so on this also includes many persons, but anyway most of the items should load fine). --YMS (talk) 15:32, 24 December 2013 (UTC)
OK, thanks for info. :) --Orijentolog (talk) 17:19, 24 December 2013 (UTC)
I often use in these cases the browser chrome and give it (a lot of) time ;-) --Zuphilip (talk) 11:45, 26 December 2013 (UTC)
If you want to track progress on this please watch bugzilla:54098. --Lydia Pintscher (WMDE) (talk) 13:11, 26 December 2013 (UTC)

Wikidata problem I have noticed for several months

When I'm adding statements to a Wikidata item and navigate to another site and then hit the back button, all the recently-added statements seem to disappear until I hit the refresh button. Does anyone else experience this? --Jakob (talk) 16:07, 25 December 2013 (UTC)

I have the same effect, quite consistently.--Ymblanter (talk) 17:13, 25 December 2013 (UTC)
This is the default behaviour of your browser. It is the same as when you are editing a Wikipedia article and then click the back button. The browser automagically saves the site in the cache and loads it from there when you navigate back. You just don't notice this issue on Wikipedia because there the site is loaded again when you are saving the article. However, in Wikidata only an AJAX request is sent to the api but the page itself isn't loaded again. I think it would be really awkward if the page would reload everytime one is adding a statement. Thus I do not see why this should be an issue of Wikidata, but if you think this is really annoying we can tell the web browser to never cache the site. This means having more traffic but it would perhaps solve your problem. -- Bene* talk 17:38, 25 December 2013 (UTC)
I see this when I use FireFox, but not otherwise. -- Lavallen (talk) 07:15, 26 December 2013 (UTC)
That's interesting. So only Firefox caches the site. Bene* talk 12:37, 26 December 2013 (UTC)
Yes and No. This cache-effect is (to me) only visible in FireFox, but it can also be seen with IE if you have an edit-conflict with yourself in the page. Accidently open and edit the same item in two windows, can give you very confusing results! -- Lavallen (talk) 14:02, 26 December 2013 (UTC)
That should be bugzilla:53466. --Lydia Pintscher (WMDE) (talk) 13:12, 26 December 2013 (UTC)

merged items bugs

you can see at this page [14] merged items, when two pages are merged we lose the labels and descriptions like this [15] and [16] and items are merged with not attenction on lowerd id. I think the problem is when you try to add a link to wikipedia, if the item exist the first attempt you recive an error but if you retry the item is automatically merged with these bad results I think we are loosing tons of data--Rippitippi (talk) 22:50, 25 December 2013 (UTC)

Is this bugzilla:58850 maybe? --Lydia Pintscher (WMDE) (talk) 13:13, 26 December 2013 (UTC)
If I have understood user find a page with no interlink for exaple on it.wikipedia, with the tool on wikipedia try to add a page on en.wikipedia, at the first attempt returns an error because the voice already has a item on wikidata but on the second attempt the item are transparently merged with lose of label and description see here [17] and Q1237273 italian label and description are removed but not added --Rippitippi (talk) 14:23, 26 December 2013 (UTC)
Maybe it should be made clearer that the user is going to perform a merge when they use the tool on Wikipedia. -- Bene* talk 15:51, 26 December 2013 (UTC)

How are we planning to handle senses of the same term?

Many terms have different senses that links different things. For example:

  • history (Q309) can either refer to past events or the academic discipline.
  • scientist (Q901) can be a profession or a class of people: when it means a profession, it is an instance; when it means a class of people, it is subclass of human.
  • People's Republic of China (Q148) can either refer to the country/land or the ruling political body.
  • fictional characters can either be treated as an imaginary person or a character design art work.

Without clarifying which sense are the statements stated to, we are not building precise knowledge base. Creating a lot of items is a way to solve this problem but the way to reach this is still too long and will result in very sparse items with worse structure. Applying "derivatives" as I suggested before might be a faster and more structured alternative (see the archieve).
I think it is best to quantify all statements with a specific sense. We may use instance of (P31) as a compulsory quantifier that divides all statements into sections (grouped by P31 value, so item with more than one P31 will have multiple sections). For class items we can apply "class" as a universal class for P31.金亦天 (talk) 10:16, 24 December 2013 (UTC)

To be honest, the notion of subclasses is pretty much dead. Typically "is a" or "instance of" is used in stead. As to disambiguation, the best method is provided by the automated disambiguation tool.
The question if a sense of a word is too broad or to narrow is one that we will never resolve. At this stage less than half our items have one or no statements and less than half our items have only one label. We are not building a precise knowledge base, we are slowly but surely enriching a repository of data that is based on the existence of Wikipedia articles. The saving grace of this effort is that it is practical, not academic or without an application. Compulsory quantifiers will only drive the people away that we need very much at this stage of the Wikidata development. Thanks, GerardM (talk) 12:00, 24 December 2013 (UTC)
No matter we intend to or not, Wikidata will finally become or is already a knowledge base. The problem I want to point out is, as a usual editor, I find it impossible to input some common knowledge using current set up. I am not talking about technical and difficult things, but once you think logically, the current property structure will force editors to create a lot of troublesome statements with many wrong implications. I really don't want this sort of forced wrong input continue to happen. 金亦天 (talk) 14:08, 24 December 2013 (UTC)
Wikidata is already a knowledge base. For all kinds of reasons we do not import data from sources that can be trusted to be reasonable. The processes about resolving issues is not all that transparent either. Given the young history of Wikidata there have been several high impact failures. Going for an imposed solution will fail as well. At this time we need to concentrate on making sure that all humans are known as humans, all men as men and all women as females. That is the level where we are. All the rest will become increasingly manageable as we get more data to manipulate statements on items.
At this time Wikidata is immature. It is not possible to add much data that is out there given the existing potential for properties. Thanks, GerardM (talk) 14:35, 24 December 2013 (UTC)
Gerard, 'subclass of' enables creating a hierarchical tree of concepts for all human knowledge. Have you seen http://tools.wmflabs.org/wikidata-todo/tree.html?q=Q35120&rp=279&lang=en? The tree is large and growing. We will be able to make useful statements with the P279 tree with OWL. The W3C introduction is better than the Wikipedia article: please read http://www.w3.org/TR/owl2-primer/#Modeling_Knowledge:_Basic_Notions. Emw (talk) 04:19, 27 December 2013 (UTC)
Thanks, I wrote this as a result. I am now less negative about all this. There is something like a tree but the devil is in its detail. Thanks GerardM (talk) 14:35, 27 December 2013 (UTC)
You're welcome -- and I completely agree with you about the devil. Emw (talk) 15:21, 27 December 2013 (UTC)
Let us not forget that words having multiple meanings is not a mistake of Wikidata, but a thing common to all languages. I'm not an expert, but the books by Steven Pinker (Q212730) have talked about this. You always need grammar to make sense of statements, and that is true for human and programming languages. It just means that our statements have to follow a grammar that makes the statements unambiguous. Our grammar already rules out one possibility of scientist (Q901), because we always use "instance of" for human. We could say "= scientist", but we decided that our grammar should not work that way. The same goes for history. If we say that somebodies occupation is history, then we (and a algorithm) certainly don't think that this persons occupation is the sum of all past events. I highly recommend reading The Stuff of Thought (Q7767123), for those interested in the cognitional underlining of language. --Tobias1984 (talk) 16:26, 24 December 2013 (UTC)
One of the key feature of semantic web it's that items are tight to their meaning, not their syntax. Moreother Wikidata is multilingual, so the meanings of the translation of a word might not be the same in all languages. I suggest you read more carefully the data model planned to support wiktionaries, which take that into account, but the item should in general tight by meaning. TomT0m (talk) 17:00, 24 December 2013 (UTC)
GerardM To be honest, the notion of subclasses is pretty much dead. ?????? What does that even mean ? I don't agree at all, subclass of is correctly used in plenty of cases, and we are already building class hierarchies in plenty of domains. TomT0m (talk)
You may not agree but what I observe is that such constructs are not used much. So some of these things may exist but so do the remnants of the GND stuff. Thanks, GerardM (talk) 17:15, 24 December 2013 (UTC)
Of course I do not agree. What Wikidata is really bad at is to enforce any meaning to any property, by design. The only tools we already have to enforce that are datatype properties and constraints, which are not really strong. Make the difference between class ans instances is really useful for tools and to define constraints, to define domain and range constraints, to build list of properties associated with items which will allow to build smarter tools, or reasonator extensions which will build correct instance or subclass relationship. Choosing an infobox type can also be made by knowing the class of an item. There is plenty of applications which did not emerge just because the project is young and poor in tools (which is by design as it looks like a raw triple backend as is). So no, class and instances are not dead. We already have tools to visualise them, and more will come. I think you lack of vision, Wikidata need to have higher level tools, and structure knowledge will help tools, and tools will help to structure knowledge. TomT0m (talk) 17:25, 24 December 2013 (UTC)
<grin> I read the OWL article on Wikipedia. It is so bad it hurts. You may want more academic approaches but you indicate that is not what is happening. You even indicate that this is by design. </grin> I do agree we need more and better tools. We need more data because that will give us grip on the items we are dealing with. As to me not having a vision.. sure. But you fail to indicate what higher level tools will bring solace and why. At that do you qualify yourself as an academic? Thanks, GerardM (talk) 17:31, 25 December 2013 (UTC)
The infoboxes at first, they are not really developed yet, part of the reason is that Wikidata is complex and we still did not reach the point such that it is clear enough so that community use it for real for infoboxes, and anything that does not show in an infobox is not really well modeled probably. Apart from that domain specific interfaces that hide modelling complexity will be a good step. Constaints, who needs class for a bunch of them to be interesting and point to odd things made by uninformed users, ... I must admit I'm not convinced yet by Wikidata being so low level by design. We also badly need help pages to guide the users who do not know how to do something that we have ourself badly talk to (not) decide and are currently lost (I think of fictional entities, we had a message on french project chat of a french Wikipedian who simply did not find anything and did not know how to.) Apart from that, I'll not knollow you on the me beeing academic or not (and I know too damn well where you are going, I don't need that lesson), this is not the subject :p. The point is that subclass of is far from beeing dead, you failed to convince me that it is. If you want to go data driven, like any industrial would like to be, you will have to give datas to support that, and interview us contributors to have our feeling as well :) TomT0m (talk) 19:01, 25 December 2013 (UTC)
@金亦天: the fact that an item can be both an instance and a class is not a mistake, it's a feature in OWL2, and it's really convenient. TomT0m (talk) 17:00, 24 December 2013 (UTC)
The problem I can see is, Wikidata users are not all experts, they easily commit mistakes when there's no good constraints to follow. When you flip over the page talks, almost all constraints are being violated systematically. I really want constraints to work. Another issue is the integrity problem. With clear disambiguation, we can use basic logical deduction to make a more sophisticated integrity checking system.
Other systems do not care about this because they are tackling only one of the senses for each term. Like the case of "scientist", we currently just use it as instance of profession from other items. However, I think in Wikidata we need to handle all senses. For example when we see a character is created by somebody, we really don't know whether the creator physically creates the body of that character inside the story or the creator designs the character. I don't think grouping statements by instance base is a difficult task to do, it just need an implicit quantifier by P31 and divide the statement panel into P31 target panels. The initial migration of adding all P31 quantifier is also bot-friendly. This will allows statements to be placed in the right place. Doing this early can inspire the design of more useful tools.金亦天 (talk) 02:07, 25 December 2013 (UTC)
Scientist is a class; a subclass of:people. But it is an example of a particular type of class: it is an instance of:Profession which is a subclass of:Class. These are not two different meanings or items. These are both properties of the class of scientists.
Suggested constraint: Anything using the 'Subclass of' property should be an 'instance of:Class' or some subclass of 'Class'. Filceolaire (talk) 16:29, 25 December 2013 (UTC)
China can refer to the country or the other country or the various historical countries. The various political and administrative offices related to China (president, minister of Education etc.) are all properties of one of these countries or more properly properties of the persons with the country as the value for the property. The supreme soviet of China (or whatever they call it) is a separate item.
art work is not a fictional character, nor is a novel, even if it depicts a fictional character.
I understand this is related to the concept of 'derivative properties' somehow. This seems to mean that we, for instance, create a 'study of' property such that Dr Joe Smith '(is a professor of:(the study of:history))'. I think this would present a lot of problems and if someone create an RFC about this I will list them out. Filceolaire (talk) 20:57, 25 December 2013 (UTC)

Is Mary a scientist or a profession? Punning in Wikidata with OWL

Suggested constraint: Anything using the 'Subclass of' property should be an 'instance of:Class' or some subclass of 'Class'.
—Filceolaire

subclass of (P279) is based on rdfs:subClassOf. Thus, from the definition of rdfs:subClassOf, it follows that all subjects of P279 are instances of rdfs:Class (or owl:Class).

This built-in constraint is interesting, but what we're really looking for is a way to handle classes like 'scientist'. As Filceolaire says, 'scientist' can be a subclass of 'person' and an instance of 'profession'. Let's extend the example and say that 'Mary' has occupation 'scientist', and we have an axiom that says "statements of the form 'X occupation Y' entail that X is an instance of Y". In other words, Mary is an instance of 'scientist'. This creates a problem. How do we know that Mary is a scientist and not a profession?

We know by metamodeling. Metamodeling allows for applying P31 (rdf:type) claims on items that have P279 (rdfs:subClassOf) claims. In other words, metamodeling allows treating a class like an instance. OWL 2 DL supports metamodeling through a feature called "punning": read more at http://www.w3.org/TR/owl2-new-features/#Simple_metamodeling_capabilities.

What does that mean? It means we can represent classes and instances within same URI -- i.e., within the same item. This is great news. It's something that TomT0m has been pushing for a while, to his credit, and is used in many domains throughout Wikidata. Behind the scenes, to make querying computationally efficient, OWL 2 DL-compliant reasoning engines treat such entities as two separate items. One of the restrictions on metamodeling in OWL is that it requires specifying whether a property is a "datatype property" or an "object property" (see here for more). But we have that built into the property creation process: properties have a fixed data type -- any properties that takes items are object properties; properties that take strings, numbers or other non-item data are datatype properties. (If an OWL exporter in RDF/XML ever gets built, it will have to account for the fact that P31 and P279 are instances of rdfs:Property and not owl:ObjectProperty.)

Hopefully this example and tie-in with OWL gives 金亦天 and others context on how different senses of a word can be represented on Wikidata in a way that is compatible with Semantic Web standards. Emw (talk) 04:08, 27 December 2013 (UTC)

Pages in a category without any language links

How to look for all pages in a category without any language links?--GZWDer (talk) 10:11, 25 December 2013 (UTC)

You mean an external tool? -- Bene* talk 17:33, 25 December 2013 (UTC)
@Bene*:Yes. Where is it?--GZWDer (talk) 05:29, 26 December 2013 (UTC)
I think once toollabs:bene/itemsbycat/ was able to do this. Let me take a look into that. -- Bene* talk 15:54, 26 December 2013 (UTC)
Ah, it is still able to do so. :-D -- Bene* talk 15:56, 26 December 2013 (UTC)
@Bene*:That I want is a list of items with only a link to one wiki, not missing items.--GZWDer (talk) 05:14, 27 December 2013 (UTC)

Item for Template subpages

In Wikidata:Notability said subpages for templates and modules are not notable. why we shouldn't make item for en:Template:Convert/LoffAoffDbSoff.

In my opinion this limitation should be only for /doc subpages not all template or modules subpages. also I didn't find any comment in below links for subpages

Yamaha5 (talk) 07:19, 27 December 2013 (UTC)

Makes sense, may /doc subpage has low importance but other templates subpagess like convert subpages IMO are eligible to have an item as they may have different names across Wikipedia languages. –ebraminiotalk 09:06, 27 December 2013 (UTC)
Yes, I am agree with Yamaha5; it's a good idea.--Calak (talk) 09:40, 27 December 2013 (UTC)
@Ebraminio, Calak, Yamaha5, Jasper Deng, Rschen7754, Ymblanter:
@Zolo, Edinwiki, Addshore, Izno:
I have started Wikidata:Requests for comment/Interwiki links for subpages.--GZWDer (talk) 09:55, 27 December 2013 (UTC)

Wikidata:About

Seems to be hopelessly out-of-date, especially the last part. Anybody wants to update about the plans etc?--Ymblanter (talk) 00:39, 25 December 2013 (UTC)

Doesn't look good. Will try to do some work on that this week. --Tobias1984 (talk) 16:02, 25 December 2013 (UTC)
I moved the page to Wikidata:Development as it was mainly about the steps of development of Wikidata. However, contributions to the page are still welcome. Additionally I redirected Wikidata:About to Wikidata:Introduction as the introduction is already a perfect page explaining how Wikidata works. If someone thinks that Wikidata:About should contain some other content, he/she is welcome to create a new page with better information about Wikidata but atm I think that this is a good solution. Best regards, -- Bene* talk 17:11, 25 December 2013 (UTC)
Thank you, I think this is fine for the time being.--Ymblanter (talk) 10:58, 27 December 2013 (UTC)
We should probably avoid redirect pages (Wikidata:About) which are used in an interface message, especially one that appears on every page (see the bottom of this page). --Izno (talk) 15:07, 28 December 2013 (UTC)
Those links can be updated... Ajraddatz (Talk) 17:18, 28 December 2013 (UTC)

Question about linking and redirects

en:w:Pastafarianism redirects to en:w:Flying Spaghetti Monster. On eswiki, es:w:Pastafarismo covers both "Pastafarianism" and "Flying Spaghetti Monster." Some Wikipedias, however, have articles for both. Currently en:w:Pastafarianism, the redirect, is what links to es:w:Pastafarismo. That does a disservice to someone who's on en:w:Flying Spaghetti Monster, though, and may want a link to the eswiki. What is best practice for dealing with this issue? Pastafarianism and Flying Spaghetti Monster, since some Wikipedias do have both, are necessary, but what about when a language only has one or the other? How can it link to the same subject using the other name elsewhere? --Rhododendrites (talk) 23:34, 28 December 2013 (UTC)

I think wikidata needs interwiki fallbacks. i.e. on Pastafarianism (Q14397660), specify that Pastafarianism (Q14398001) and Flying Spaghetti Monster (Q12044) are almost equivalent and wikipedia links on those items should be used for languages that don't have a link on Pastafarianism (Q14397660). The lack of interwiki fallbacks is why in the section below ("one item, different meanings"), splitting the item is a 'Wikipedia wont like it' problem. John Vandenberg (talk) 08:00, 29 December 2013 (UTC)

make Wikidata information applicable

Hoi, I blogged about the need to make the data in Wikidata applicable. To do that we need to apply it. What I want us to consider is to have a place where information can be found in a similar way as what we currently have as a result of a Wikidata search when added to the extended search in a Wikipedia.

Obviously we should start this in a Wiki way. It does not have to be perfect from day one. Because we do not know what works best. The objective is very much at this stage to motivate more people to add labels in their language. It will open up Commons and, it will make us consider more what Wikidata is and, is there for. Thanks, GerardM (talk) 09:36, 29 December 2013 (UTC)

Special:SetSiteLink page didn't automatically fill the "ID" field

Hello, I've found and oddity in the Special:SetSiteLink page that it didn't acknowledge the item ID appended to the URL.

How to reproduce:

This issue seems to be minor and didn't affect functionality itself (since it still works if I manually filled the ID field).  – The preceding unsigned comment was added by Nvtj (talk • contribs) at 13:55, 29 December 2013 (UTC).

https://gerrit.wikimedia.org/r/104357 will fix that once merged and deployed. Cheers, Hoo man (talk) 14:56, 29 December 2013 (UTC)

solved discussion

How to handle solved discussions? Clear page [18], place done [19] - or what would you do? Greetings, Conny (talk) 20:34, 29 December 2013 (UTC).

If you have completed a task or request, you can use for example the done template. There are some other similar templates, see https://www.wikidata.org/wiki/Category:Resolution_templates. For keeping order and make it easier for possible readers to focus on the new discussions, there are mechanisms to move old (maybe even outdated) discussion to an archive. I would rather try to use some archive then to delete discussions (blank the page). For example this page uses archives with some rules and a bot doing the job. For discussions on item pages, I have never seen a lot of text, such that I guess we can just let them there. --Zuphilip (talk) 12:01, 30 December 2013 (UTC)
But it takes energy, when people must read texts, of problems allready solved ;) . Conny (talk) 13:19, 30 December 2013 (UTC).
Yes, reading is time-consuming. On the other hand, you don't have to read everything ;-) Should we decide what is worth to read any longer? Maybe, this is a task every reader has to do. Please allow me to compare this with a fictional example: Assume your husband want to read the newspaper, but to make reading easier for him, you will give him only some pages with the "relevant information". For example sport is silly and nobody has to read this information ;-)
Moreover, you can use the hidden template, e.g. for large lists. Example:
Hidden template
This text is hidden but not deleted, e.g. for large list this can be useful.
Corresponding code: {{Hidden begin|Hidden template}} This text is hidden but not deleted, e.g. for large list this can be useful. {{Hidden end}}
--Zuphilip (talk) 13:46, 30 December 2013 (UTC)


Decoration and constraints

The differentiation between award (Q618779) and order (Q193622) and the fact that the latter is an instance of the former currently generate accepted situations in Wikidata:Database_reports/Constraint_violations/P166 that should be rejected (see the criteria : Property_talk:P166). For instance, Legion of Honour (Q163700), a group of orders, is wrongly accepted as a value of award received (P166).

Nevertheless, I think it would not be ideal to solve this by differentiating even more the two terms and creating another property.

Louperivois (talk) 22:01, 29 December 2013 (UTC)

I think awards and orders are almost the same thing for Wikidata purposes - whether civil, military or other. What relationships and properties do you think makes them different?
See also Wikidata:Property proposal/Person#sports title held and Wikidata:Property proposal/Unsorted#title held by. John Vandenberg (talk) 08:48, 30 December 2013 (UTC)
I share this opinion but the fact is there is an article on WP for both of them and it is thereby more accurate to use them as a value of instance of (P31) or subclass of (P279) (which is better?). Louperivois (talk) 18:17, 30 December 2013 (UTC)
I do not understand. order (Q193622) is a subclass of award (Q618779). Both are concepts, not things, so they must be classes. There is a lot of variation in awards, including academic degree (Q189533), and awards like championship belt (Q2132957) that are transferred to someone else who beats the previous holder, but sometimes they can keep them like Lonsdale Belt (Q6674827). John Vandenberg (talk) 18:42, 30 December 2013 (UTC)

one item, different meanings

I don't know this issue has been raised before or not but today I saw Neda Agha-Soltan (Q326474), in several wikipedia (including Persian, German, Spanish, etc.) the title is "Neda Agha-sultan" and the article is about her and in several wikipedia (including English, Dutch, French, etc.) the title is "Death of Neda Agha-sultan" and the article is about the murder. The problem is in statements, is it okay to have instance of (P31): human (Q5) statement and coordinate location (P625) of murder (not burial place) at the same time? I thought about splitting the item but I don't think Wikipedians would like this solution. Amir (talk) 07:09, 29 December 2013 (UTC)

Is Q326474 going to be an instance of person and event? Surely not. If not, the options are : split and use significant event (P793) to link them, or keep it as a person and push the event details into a significant event (P793) as qualifiers for the date and event location (of Kargar Street (Q6370248)? ; the google maps of the geo-coordinate show it as Khosravi Street), and possibly create a new item for the precise place of the shooting. John Vandenberg (talk) 07:53, 29 December 2013 (UTC)
I like pushing statements into significant event (P793) but problems will start when the statements will be used in infoboxes. Amir (talk) 09:13, 29 December 2013 (UTC)
What Wikipedians like and don't like is not that relevant. What is important that Wikidata items can have proper statements. A murder and a person are two different things. A murder for instance does not have a date of birth. Thanks, GerardM (talk) 09:30, 29 December 2013 (UTC)
I doubt your sentence about the relevance what Wikipedians are thinking. We try to make the statements inside wikidata to be as accurate as possible, but also we want to be useful for wikipedias (cf. Wikidata:Introduction#What_does_this_mean.3F). Sometimes these two goals are not achievable in the same time and we have to make a compromise. --Zuphilip (talk) 09:35, 30 December 2013 (UTC)

I made this Neda Agha-Soltan (Q15457364) and changed English label of Neda Agha-Soltan (Q326474) to Neda Agha-sultan, I removed unrelated statements (like coordination and date) and moved it to the new item, but I didn't split sitelinks Amir (talk) 11:38, 29 December 2013 (UTC)

The unsolved state of these questions on Wikidata is an issue. I have encountered similar problems yet several times. I think the problem is our handling of sitelinks. I do not think that their article name has to be the same as our label. Wikidata items are about things, Wikipedia articles are about topics, although both of them, the item and the article are resources, and there are items about articles, e.g. those with a instance of (P31) <Wikimedia disambiguation page (Q4167410)>-statement.
It is neither possible nor useful to superpose them entirely. Missing consciousness of these differences leads to problems like that at Property talk:P31#Inconsistency? We should probably agree to a relation/role like http://xmlns.com/foaf/spec/#term_isPrimaryTopicOf for the sitelinks. DBpedia (Q465) does so, too, cf. here: <dbpedia:Mercury_(planet)> foaf:isPrimaryTopicOf <http://en.wikipedia.org/wiki/Mercury_(planet)>. If we agree on that we can simply group the sitelinks to useful sets (depending on the existing articles) and add the sets to the most appropriate item! I'd like to add some sentences to Help:Sitelinks to denote these considerations. What do you think? Regards, --Marsupium (talk) 14:46, 31 December 2013 (UTC)

Q83165 and Q2724976

Can any of you integrate this (Q83165) and this (Q2724976), because they are intended for the same --albebas (talk) 21:40, 30 December 2013 (UTC)

Don't think so, the species of the plant itself should be different from the spice it produces. TeleComNasSprVen (talk) 06:09, 31 December 2013 (UTC)

How to handle disambiguation qualifiers on place name labels

I recall that policy about place labels is that they should not have disambiguation/qualifier words that are not part of the basic name. However, I have encountered place names that still have the qualifier on the label. For example, Q2189258 has the label "St. Andrews, South Carolina". Whenever I encounter such a label, should I change it to "St. Andrews" and add "St. Andrews, South Carolina" as an alias? Or is there a reason that some place names have those disambiguation suffixes? (St. Andrews is an instance of a "census-designated place" (Q498162) so maybe a bot didn't notice those as being like city names.) --Closeapple (talk) 09:16, 31 December 2013 (UTC)

I think what has happened is that the bot has just imported the English article title and no one else has got round to fixing it yet. Please do change these labels as you describe above and make sure they have a suitable description ('census designated place in Richland County, South Carolina, USA') which will distinguish it from every other 'St Andrews'. I have also
  • changed 'is in administrative unit' to point to 'Richland County' instead of 'South Carolina'.
  • Deleted P107
  • Added instance of:census designated place
  • used the 'label collector' gadget to generate descriptions in other languages, based on these properties.
Filceolaire (talk) 12:26, 31 December 2013 (UTC)

Abbreviations in place names

Another question about labels: Is there a Wikidata guideline about whether abbreviations in place labels should be retained or expanded? For example, should the first two words in the place name Q2189258 label remain "St. Andrews" if that is the most common name, or should it be changed to "Saint Andrews" unless there is an exceptional reason? (Q2189258 is a strange example, since it is not a legal entity; it is an unofficial settlement, that has a census boundary only for statistics; and whether it is written as "St. Andrews" or "Saint Andrews" varies from source to source. I don't actually know which is the most common; they may be equally common in this instance.) --Closeapple (talk) 09:29, 31 December 2013 (UTC)

In my opinion the guideline should be that you follow whichever is most widely used and you make sure the other label is listed as an alias. Filceolaire (talk) 12:38, 31 December 2013 (UTC)

More about abbreviations

The thread above make me think of something I have discovered in Swedish labels. ":" is often used in Swedish abbreviations like "S:t" and as a separator between the genitiv-suffix and the main word, like "USA:s". This is one reason the interwikilinke between sv.wikipedia and sv.wikisource isn't using "s:" to link between the projects. (The users became suprised to arrive in Wikisource, when the tried to go to "S:t Petersburg".)

Our bots are not always handling this correctly. Labels, where the WP-title contains ":" has been mistyped. For example "USA:s högsta domstol" has been shortened to "s högsta domstol".

What can we do to prevent and correct this? -- Lavallen (talk) 15:39, 31 December 2013 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2013/12&oldid=1102153516"