Wikidata:Project chat/Archive/2013/06

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Sourcing statement

With the time datatype and the property publication date (P577) creation it is now possible to source data with book reference: the minimal set of properties for book description is available and described in Help:Sources. However there are still some discussions about the best way to store book data in order to reuse them (see Wikidata:Requests_for_comment/References_and_sources). As this can take still some time I propose to put the book data under the source section of each statement until a decision is taken (see that example). This solution is not the most practical one when adding a lot of data from the same book but for that kind of work the optimal solution is to work with a bot which can add both value and source in each statement in an automatic way.

It would be great if someone with lua programming skills can start to create a template extracting value and source from wikidata in a wikipedia article: this will be the complete example of the potential of wikidata as data source for wikipedia. Snipre (talk) 00:15, 30 May 2013 (UTC)

Help:Sources also need a guideline for online-databases and if every database with an ID deserves its own string-property. --Tobias1984 (talk) 07:48, 30 May 2013 (UTC)

Online databases follow the rules of website parameters. Snipre (talk) 09:28, 30 May 2013 (UTC)

This would set a precedent before the relevant discussion is finished and we reach a decision. And from the current state of the discussion, the model you want to employ has already pretty much been rejected, so most likely all the work would have to be redone. In light of this, I'm not sure I agree with your proposal. Silver hr (talk) 12:24, 30 May 2013 (UTC)

The discussions last since one month and some persons want to discuss again of a general concept instead of focusing on practical solutions. I can't close the discussion and I don't want it if there is some project for developing new features. But at the same time we can't wait until the optimal solution is found especially if we don't have an idea about the time necessary to reach it.

During that time data continuously flow in the database without any good possibility of sourcing and the proposed solution is the normal model which will be applied for most sources (article, webpage, media,...) so this model is the most appropriated until the RfC finds a conclusion. This not a precedent as since the beginning of wikidata temporary solutions are used until a final solution is found (just as example the property imported from Wikimedia project (P143) used to source import from wikipedia).

I finish with that position: I am open to all good solutions but please bring a solution because wikidata is not waiting on your opinion. Snipre (talk) 15:47, 30 May 2013 (UTC)

I only want to avoid wasting effort through unnecessary duplication of labor. What I meant by "precedent" is that if someone starts doing it a certain way now, others are likely to imitate and if the conclusions of the RFC turn out such that the way of doing it was wrong, effort will have been wasted. And the model you suggest (mentioned in the RFC as 'Only references for statement sources (1Q model) The "source" field under the claim would store ALL information needed about the source') received 3 opposing and no supporting votes in the RFC so I don't think it's the most appropriate. Silver hr (talk) 22:53, 30 May 2013 (UTC)

@Snipre: In general I like you example at Q113820. The problem with this approach is that currently everything has to be entered by hand. It actually should be sufficient to enter the doi or ISBN13 and then a bot could fill in the rest of the information. If I have an item with 20 statements that all come from the same source I don't want to type the source information 20 times. Even Wikipedia with its doi and ISBN lookup-function has more automation than that. I think once a solution is found where sourcing a claim does not take longer than entering the claim, people will adopt it. --Tobias1984 (talk) 18:34, 30 May 2013 (UTC)

Also to Snipre: the way to approach edition data is much clear now after the Hackathon (see my comments here). Bear in mind that Wikidata is at early stages (it is only a week since data can be pulled into Wikipedia), so we need to have tons of patience and then more.

I will inform all participants in the RFC about references and sources about these ideas which I hope satisfy everyone and if there are no concerns, then we can aim to the 15 of June to have a final resolution.--Micru (talk) 23:48, 30 May 2013 (UTC)

I know I am putting pressure on the RfC but just read the post below Wikidata:Project_chat#Statements_that_need_a_reference.2C_statements_that_don.27t to understand the problem. If we have data + source even in the wrong format this not a problem to rework later but if we have only data without source that will be wasteful work and most important this will lead to a bad impression of wikidata. Snipre (talk) 17:45, 31 May 2013 (UTC)

@Silver hr What you say is correct about edition data for book, but books are not the only source format and the RfC doesn't say anything about other sources I try to keep a global view of the sourcing problem and the option 'Only references for statement sources (1Q model) The "source" field under the claim would store ALL information needed about the source' is the only solution for all references which are not a book. If we have to create an item for each url this will become quite complex and qualifiers option can't be an option for urls or for articles. So my proposition is for all sources and if the RfC finds a conclusion we will have an exception for books. Snipre (talk) 17:45, 31 May 2013 (UTC)

@Tobias1984 Work with bots and your problem disappears: instead of adding manually each value to item, prepare a list of items with value and sources (in an excel or text file), get in touch with a bot owner and prepare with him the import task. Snipre (talk) 17:45, 31 May 2013 (UTC)

@Snipre: the RfC had many discussions revolving around books because it is where more difficulties are. In any case I understand and share your concerns that we should aim for a global view about sources. I have started this draft with that in mind: Guidelines for sources.--Micru (talk) 04:38, 1 June 2013 (UTC)

Statements that need a reference, statements that don't

It is time to agree on a more precise policy on what content should be sourced. Wikidata has repeatedly promised that the content would be verifiable and that non-trivial statements would be referenced. It's written explicitly in Wikidata:Introduction and it's an assurance we've given whenever Wikipedia editors were hesitant to use Phase 2 features. Now that the time datatype is available, bots have started to import day of birth/day of death data, which is non-trivial data that should be sourced (and typically is sourced properly on en.wiki). This mass import is breaking the promise we made to be careful with referencing. Pichpich (talk) 13:23, 31 May 2013 (UTC)

I'd like to add that it's necessary to handle cultural differences with dates import too. For example, Russian Empire used Julian calendar until 1917, so all relevant dates should be for Julian calendar. However, bots followed easiest way and Wikidata interface doesn't allow to switch between calendar systems. :-( --EugeneZelenko (talk) 13:49, 31 May 2013 (UTC)

I agree. Every non-trivial statements should have sources. E.g. on fi-wiki we have strict sourcing policy for birth and death days. Every this kind of information needs to be sourced, or it will not be accepted on fi-wiki. I've seen that on en-wiki they are not very seriously with sourcing birth days, just one example en:Nate Ruess, and comment "Why is the birthdate so hard to believe? The New York Times confirms it. *SMH*". And of course every other Wikipedia's had taken that same birthday from en-wiki, without any given source. Not good. --Stryn (talk) 14:26, 31 May 2013 (UTC)

Meanwhile Wikidata:Requests for permissions/Bot/SamoaBot 26 is getting support from other bot operators as if sourcing was a non-issue and at least one editor is seriously arguing that since many dates are not sourced on en.wiki there's really no rationale for requiring sources on Wikidata. Pichpich (talk) 16:54, 31 May 2013 (UTC)

Fact is we are fair away from good sourced Data, because sources are nearly useless until they get checked automatically by Computer. We are not there, but the day will come. --FischX (talk) 21:39, 31 May 2013 (UTC)

Some sources can be checked automatically by computer against structure data elsewhere (population for example) but a lot of other data will need to be checked by a human. I'm willing to help do this but I can't be bothered starting until we have a url datatype to record where we found the information and a comment qualifier where we can put a quotation or other string such as a bot leaving the message "url should be checked by a human". Can we please prioritise the url datatype? Filceolaire (talk) 22:54, 31 May 2013 (UTC)

Possibly with a vote for the corresponding bug, but still well done sourcing is more than a link, in an ideal World we have a tool for selecting the part of the source that is relevant and keeps it as citation this is also possible with books but with much more effort. And we have to keep in mind that people like to believe in sources but don't like to check them. --FischX (talk) 23:14, 31 May 2013 (UTC)

Regarding this, I have started this draft: Guidelines for sources.--Micru (talk) 04:40, 1 June 2013 (UTC)

Exporting a copiable interwiki list?

Hey, is it possible (or even desired) to export out an easily-copied list of interwiki links for a data item? I just updated a Wikispecies page, and manually copying and pasting the language codes and article names was a pain in the ass... but I also readily acknowledge that not everyone would get any benefit from the tool.

In this instance, the respective pages were species:Galeus and Q137561. EVula // talk // 16:41, 31 May 2013 (UTC)

Write the following line into your common.js:

importScript( 'User:Ricordisamoa/InterwikiList.js' );

FallingGravity (talk) 18:28, 31 May 2013 (UTC)

Huh, so a different problem now... user scripts aren't showing up on data pages for me. I've got the "UTC Live Clock" gadget enabled, but it doesn't display on Q137561 (or any other random page that I pull up), but it does show up in the project, user, user talk, category, and template namespaces. I first noticed on my primary browser of Safari 6.0.3 on OSX 10.8.3, but duplicated the same results in Firefox 21.0 and Chrome 27.0.1453.93. Curiously, the clock does show up in Opera 12.15, though I can't find any indication that the above script is working (Vector theme). Bizarre. EVula // talk // 19:05, 1 June 2013 (UTC)

Additional global bot right request on meta

Hi! There is currently a request for global editinterface rights for Addbot open on meta wiki here to allow the bot to edit protected pages to remove interwiki links that are already on [[:|wikidata]]. It has been proposed that a second global bot group be created that includes the following flags (edit, editprotected, autoconfirmed). This is not something stewards want to rush into as the flag would allow the bot to operate on protected pages and would prefer to have a wider participation in the request for approval before any action is taken. All comments should be posted at (meta:Steward_requests/Global_permissions#New_global_permissions_group) ·Add§hore· ^{Talk To Me!} 16:03, 1 June 2013 (UTC)

Concept of deletion

I suppose that the way properties are being deleted is wrong in some way. Let me explain: in my watchlist I've noticed the deletion of important information. I've found that there was a discussion but it is ended already... And how should I have taken a part in this discussion without knowing about it? At least some notification on property discussion page should be written. And if a property with data is being deleted, some other property necessarily should take the flag. Infovarius (talk) 16:12, 1 June 2013 (UTC)

There is a watchlist notice on properties for deletion (and it has been there for some time).--Ymblanter (talk) 16:20, 1 June 2013 (UTC)

No loss of data, absolutely! The bot verified that State Anthem of the Russian Federation (Q1225991) already contained "audio (P51) → Russian Anthem chorus.ogg". --Ricordisamoa 16:24, 1 June 2013 (UTC)

We need notification about starting delete discussion on property talk page. Maybe for items too. Deletion page have too large messages count to add it to watch list. — Ivan A. Krestinin (talk) 19:11, 1 June 2013 (UTC)

How to classify items: lot's specific type properties or few generic ones?

In some discussions (e.g. this request of deletion) we need to decide how classify items. There is two possibility: a lot of specific properties, or few generic ones. I open this request of comment to try to take a decision. Please, add your comment.--Paperoastro (talk) 22:12, 1 June 2013 (UTC)

What to do when the name is needed for more than one entry?

Here's the specific issue but it is only an example of a wider one. I wanted to find the Spanish equivalent of en:Wikipedia:Changing username/Usurpations, so I went there and there was no interlanguage link for Spanish. I eventually found the equivalent Spanish page (with much more effort going another way, which flags the issue). I located it at es:Wikipedia:Cambiar el nombre de usuario and went to update the entry for the English at Q4615956, but when I tried I got an error message, the details of which are: "Site link Wikipedia:Cambiar el nombre de usuario already used by item Q4026973."

The problem, then, is that from the perspective of en.wikipedia.org, these are two different pages, and from the perspective of es.wikipedia.org, usurpation is a subsection of changing usernames, but someone coming from the English Wikipedia will not find the Spanish link when they go looking for it. There are many pages similarly situated. Can we really not link to an entry twice? And if not, I will be forced, if I want to correct the issue, to go back to the old system and add the Spanish link directly to the English page, which is a fragmentation of the service this site is supposed to provide that would lead to much confusion.--Fuhghettaboutit (talk) 00:03, 2 June 2013 (UTC)

You cannot link directly to one Spanish page from two different pages in another language. But you can have a Spanish redirect page which redirects es:Wikipedia:Cambiar el nombre de usuario and which are linked to by en:Wikipedia:Changing username/Usurpations. At the moment Wikidata will not allow you to add a redirect page to an item like Q4615956 (that will be changed later), but you are able to 1) Create a Spanish page about usurpation with nothing but a notice refering to the other page, 2) Add that little page to Q4615956, and 3) now edit the page so it is changed to a real redirect page. That way any page in Q4615956 about usurpation will indirectly link to the Spanish page about changing username. It is decided that it should be possible to add a redirect page to an item (without first adding a normal page, and then later change the page to a redirect page), but we are still waiting for that decision to be implemented. Byrial (talk) 04:14, 2 June 2013 (UTC)

Jurors 1–12; redux

As an admin, I've got a serious problem with this situation. I do not see a consensus for or against the properties and would like to continue discussion. My feeling is that they should be deleted. I don't see "I think it's the only way we can query different actors who played the same role (Juror 1)." as being persuasive, primarily because I see it as irrelevant whether person A played juror B in this context; nor is it really structural. (The point of structural was for things like unwritten about genuses and actors, not for qualifiers of who played what, especially when the qualifiers in this case are completely unlinked.) I would submit them for RfD but would rather see some more talk here first. --Izno (talk) 01:08, 1 June 2013 (UTC)

Role is used in infobox also if isn't not notable role, I don't think that is technically possible manage notable role in Wikidata and not notable role in Wikipedia. --ValterVB (talk) 08:33, 1 June 2013 (UTC)

We all agree that some actors should be linked. The disagreement is over how many. Options are:

1. all the main roles in the movie (State if you think juror 12 qualifies) Filceolaire (talk) 01:49, 1 June 2013 (UTC)

 Comment Personally I think we should follow whatever they do on the info boxes. Anyone know what that is? Filceolaire (talk) 01:49, 1 June 2013 (UTC)

I dont know. That can be a good first step, but the software is different here and they do always do it the same way in all languages. --Zolo (talk) 06:34, 1 June 2013 (UTC)

I have not seen the films and do not know about the importance of individual jurors, but "I think it's the only way we can query different actors who played the same role" sounds convincing to me. The main reason I see against creating many items is that it may make it a bit harder to fight vandalism, but the users/items ratio is so low that we need scalable ways to fight vandalism (the amount of vandalism is presumably much more related to the site's traffic than to the number of items). --Zolo (talk) 06:34, 1 June 2013 (UTC)

 Comment Though I think the jurors deserve their own items, I'm not sure if all other main roles do. The difference is that the jurors are not roles appear in only one film, they appear in several different book/TV/films. Creating items for them can link the same roles in different works together, I think that's what databases do. Meanwhile, if a role only appear in a single film, perhaps there is not much need to create a separate item.--Stevenliuyi (talk) 06:47, 1 June 2013 (UTC)

On second thought: Since we will allow items link to Wikipedia redirect pages and main roles of a film could have sitelinks redirected to the film article in Wikipedias, perhaps it will be ok to have items for all main roles. --Stevenliuyi (talk) 08:15, 1 June 2013 (UTC)

2. notable actors only (i.e. actors with a wikidata page) even if they just had a small role - so we can use wikidata to build filmography lists for them. Filceolaire (talk) 01:49, 1 June 2013 (UTC)

 Comment I'm not sure about this one either. I guess automatically building all lists in Category:Filmographies (Q7085993) is in the scope of phase 3, but creating tons of small roles may not be a good idea.--Stevenliuyi (talk) 06:47, 1 June 2013 (UTC)

3.Both

--Filceolaire (talk) 01:53, 1 June 2013 (UTC)

Er, I think I might have confused the people here (perhaps just Filce? :) with my use of "I do not see a consensus for or against the properties and would like to continue discussion.". I meant to use the word "items" rather than properties. (I have no objection to listing all of the actors, but each of the roles I do not see the value of.) A general "role = juror" seems appropriate here, for I can see no reason why we would need to distinguish in a query or infobox between which juror each person was. Was the person a juror in the film? Why, yes he was! Which one? Why do we care which? Where is the use case that demonstrates the value of the statement from a database point of view?

Consider for example a different use case where there are people who acted as "policeman" in a particular film, and there were three such persons. What value does it give us to say "oh, he was policeman 1", "that man was policeman 2", etc? --Izno (talk) 16:50, 1 June 2013 (UTC)

First, of course we don't care the policemen if they're not special, and we should use generic "policeman" in such cases. But meanwhile, the jurors we are talking about are main roles in a very famous and classic film (along with several different derived works), just like we should use The Doctor (Q34358) for the roles in Doctor Who instead of generic "doctor", and we should use Man with No Name (Q596978) for the roles in Dollars Trilogy instead of generic item such as "John Doe". Second, the numbers 1-12 we use are not randomly picked, they have been used since the original drama written by Reginald Rose (see [1]). --Stevenliuyi (talk) 17:47, 1 June 2013 (UTC)

Yes, the film in good and notable and classic, etc. The roles themselves outside of the film are not (and as a side note, it's likely that they are spoken about in congregation rather than as individual roles).

The only reason we associate the good Doctor with is because there's a specific item with links about the Doctor himself. The same is true of Man With No Name. We're trying to build structured knowledge here, and part of that is keying off what the pedias have chosen to write articles on. Not a single one has written an article on the individual jurors (though maybe it's possible that they could for each).

As for randomly, so?... That's irrelevant, quite frankly. --Izno (talk) 18:42, 1 June 2013 (UTC)

But having sitelinks is not the only criteria for having items here, we also have two other criteria at Wikidata:Notability. Linking same roles in different works is exactly the structured knowledge we are building, and it meets the third criteria of WD:N. Besides, I think a character listed in American Film Institute's 100 Years...100 Heroes & Villains definitely meets the second criteria of WD:N. Furthermore, as I said above, the items will have sitelinks once we can add redirect pages as sitelinks. --Stevenliuyi (talk) 19:05, 1 June 2013 (UTC)

The number of criteria is true, but your idea of what the third criterion was meant to be is flawed. It was made to capture items which must be in place to link item-with-links-A to item-with-links-B, such as genera in the tree of life without items. Your use here is for item-with-links-A to item-without-links-C...

Your notion of the reason why we want to redirects is also not quite good. The reason we want to be able to do that is because some pages, like lists of characters, have "sub" items which are not notable on one particular Wikipedia but are on another. The notion that either of those would be good reasons just to add an item is odd. --Izno (talk) 20:25, 1 June 2013 (UTC)

1) When two actors (item-with-links-A & B) played the same role (item-without-links-C), we need item-without-links-C to link item-with-links-A and item-with-links-B together, that's what the third criteria is about. Why do we want two actors linked together? I agree with Tobias1984's comment below that users may want to query such lists, just like we have list of actors who have played Sherlock Holmes (Q6471730) and list of actors who have played Santa Claus (Q11811801); 2) For the redirects, I think now we don't have any guideline on when redirects should be used or not (the only consensus on RfC is about the change of software). It's an issue we will discuss later. --Stevenliuyi (talk) 21:36, 1 June 2013 (UTC)

How are not the characters of a movie or a fiction and their bindings to the actor who played them not structured knowlege ? Their is quite some things to do with those information if they are in the database, such as statistics or study over the occupation, the sex of those characters in fiction, if we know them. item creation on wikipedia is almost free, it's not as if we had to write a complete article about them. You seem to reason as if wikidata was just a structured mirror of wikipedia with less informations, why should that be ? TomT0m (talk) 19:36, 1 June 2013 (UTC)

Is it possible that some of us have a systemic bias towards bodies of information like film, literature study, etc...? I mainly contribute to Naturwissenschaften, and I also thought to myself "why should we make items for those 12 dudes from that old movie?", but maybe the question should be "what if somebody in 5 years want to query all the actors that played the 5th juror in all the versions of this movie". Or what if somebody wants to query all the people that played hamlet in the 20th century". The question should be "Can I think of a single query that would be useful to somebody?" and not "Is this particular item notable. --Tobias1984 (talk) 19:46, 1 June 2013 (UTC)

These are fun queries, but I can think of a single query that everyone will like. So that as a criterion for keeping something or not doesn't seem like a good one. --Izno (talk) 20:25, 1 June 2013 (UTC)

"item creation on wikipedia is almost free, it's not as if we had to write a complete article about them." is incorrect in my mind, because maintenance takes two things: Items to be maintained, and people to maintain them. With over 12 million items now, we will have our hands full as it is. A reliance on bots will only take us so far, because there are a lot of things that humans must do that bots cannot... --Izno (talk) 20:25, 1 June 2013 (UTC)

You should also count time spent on discussion about that topic, whether they are general or about a particular case on that matter into maintenance time. Time spent by users to try to advocate their usecase, endless discussion, time needed to delete and asking question which could be sometime be plenty of time longer that creation. There is also frustration from users who see their contribution deleted. Too restrictive criterium comes also with a cost, which is difficult to evaluate. imho we should'nt forget that users and social dynamics are essential to the success of this kind of crowd projects. We should'nt risk to break that by beeing too restrictive, with maybe little gain on maintenance, their is already plenty of items, is plenty + plenty of items more difficult ? Is the (hypothetical) gain in maintenance more interesting than the potential cost in interesting usecases (there isplenty of them we cannot even think of yet - "eh, maybe we could do this with wikidata !" or not, they just did not want the data we could use ...)? TomT0m (talk) 21:04, 1 June 2013 (UTC)

The main issue regarding notability on Wikidata right now is our inability to reference and source statements. Until we can add references to items there is no way to judge accurately whether an item passes a Wikidata version of General Notability Guidelines. All we can do right now to judge notability is to look at what Wikipedia finds notable. Wikidata may have a lower threashold for GNG than Wikipedia in the end, but without references it is very difficult to judge notability. I hope that referencing is introduced soon. Del_♉sion23 (talk) 00:49, 2 June 2013 (UTC)

Actually mapping the wikipedia requirements to another projects seems to me a very bad idea. If I look at the wikipedia introduction, I see no mention of notability, mainly verifiability. Let's not close too much doors by setting to strong requirements and lets play around a little so that this project find its own way and uses. TomT0m (talk) 13:18, 2 June 2013 (UTC)

What is the P107 (P107) for historical nations ?

For historical nations like First French Empire (Q71084)、Kingdom of Prussia (Q27306)、Song dynasty (Q7462), what are their P107 (P107)? I saw some use geographical feature (Q618123)(Austria-Hungary (Q28513)) and some use organization (Q43229)(Qing Dynasty (Q8733)) --凡其_Fanchy 17:06, 1 June 2013 (UTC)

Probably the same as it is for current countries. πr² (t • c) 20:24, 1 June 2013 (UTC)

Not sure about the exact rules, but items that had/have a geographical area (for example in form of national boundaries) get geographical feature (Q618123). -- Make (talk) 06:50, 2 June 2013 (UTC) – PS: found an English description of GND ontology [2] which confirms that countries, religious territories, territorial corporate body, territorial administrative unit, etc. all belong to main class "Place or geographic name" and therefor get "geographical feature" in Wikidata P107. -- Make (talk) 07:16, 2 June 2013 (UTC)

Changed per Make --凡其_Fanchy 17:43, 2 June 2013 (UTC)

Advanced search by properties

In my humble opinion, one of weakness of Wikidata is poor search feature. I think it would be better to make advanced search like librarys and major search engine using AND/OR logics over properties. For example, if you search <Office held> "President of the United States" AND <date of birth> 1940~1950 (timespan search for TimeValue), system would return the President of the U.S. born between 1940 and 1950. (That's George W. Bush!) Is there any plan to develop such feature? Thank you. Kwj2772 (talk) 20:23, 1 June 2013 (UTC)

Advanced search will be supported via queries, which are currently being developed. Emw (talk) 18:30, 2 June 2013 (UTC)

Requests for comment that can be closed

I have listed 2 Requests for comment that can be closed on Wikidata talk:Requests for comment. Outcome: devs to allow sitelinks to wikipedia redirect pages. Filceolaire (talk) 09:52, 1 June 2013 (UTC)

Then just close them, this is the easiest.--Ymblanter (talk) 10:13, 1 June 2013 (UTC)

 Done Filceolaire (talk) 22:42, 2 June 2013 (UTC)

Introducing SamoaBot Delinker

It's a brand new service, read more on that page. --Ricordisamoa 08:36, 4 June 2013 (UTC)

What does the service do? On the page I can read command syntax, but the page doesn't say what the command will do with the from and to items. Byrial (talk) 08:53, 4 June 2013 (UTC)

I see on the commands page Replace all occurrences of (no label) (Q5081911) with Virginia pulchra (Q3560692) because "test" as stated by Ricordisamoa (A), So I am guessing this is like commons delinked, that can either swap a deleted entity for another, or just remove a deleted entity from everywhere? ·addshore· ^{talk to me!} 08:58, 4 June 2013 (UTC)

It would be good to integrate this option to the Merge gadget, so that the merge would not just transfer all into from one item to another one, but also replace the links from items.--Ymblanter (talk) 10:21, 4 June 2013 (UTC)

I agree with Ymblanter above, also might it be an idea to create a new bot account for this specific task? This way if anyone makes a mistake the edits would be easier to spot and revert rather than been mixed in with the rest of SamoaBots edits! ·addshore· ^{talk to me!} 10:50, 4 June 2013 (UTC)

Also I have semi protected [[User:SamoaBot/Delinker/commands] for now, might it be an idea to create some sort of access list to restrict the use of the bot? ·addshore· ^{talk to me!} 10:52, 4 June 2013 (UTC)

Exactly what Addshore said: "swap a deleted entity for another". It is still experimental, and meant for extensive replacements only. For <100 replacements, anyone would use Merge.js, of course: I'm working on it. Regards, --Ricordisamoa 11:04, 4 June 2013 (UTC)

Q13416711: Wikipedia disambiguation page

This item which I have just created can be used in "instance of" statements. --4th-otaku (talk) 11:07, 4 June 2013 (UTC)

Properties for wikipedia pages that don't reference single wikidata items are being discussed on Wikidata:Requests for comment/Non-article items for property:p107. Filceolaire (talk) 14:24, 4 June 2013 (UTC)

Wikimedia disambiguation page (Q13416711) is a dup in two ways:

1) We already have Wikimedia disambiguation page (Q4167410) that can be used in "instance of" statements.

2) For Wikidata main type (P107) there is Q11651459.

--Kolja21 (talk) 00:00, 6 June 2013 (UTC)

Link FA or GA

Can we move link FA or GA to wikidata?--Cheers! (talk) 04:36, 5 June 2013 (UTC)

Not at the moment. See Bugzilla:40810. --Stryn (talk) 06:32, 5 June 2013 (UTC)

A case study : athletics

Athletics (sport) is an interesting topic. It is a sport, in which competition is a set of events, such as throw events, running events etc. , by definition.

I want to start a discussion about how we model that into wikidata using help:basic membership properties.

First a few item related to this topic : athletics (Q542), for the sport itself, athletics at the 1896 Summer Olympics (Q339297), for an example of a competition of this sport, athletics at the 2008 Summer Paralympics - men's club throw F32/51 (Q4814879) which is an example of a particular club throwing (paralympic) event, and throwing (Q3216963), which corresponding article is about throwing in athetics, and club throw (Q3216966), which is about club throwing. I could also add that there exists a "athletics events" category on Wikipedia to classify those events.

Clearly athletics at the 2008 Summer Paralympics - men's club throw F32/51 (Q4814879) (the paralympic club throw of the olympics games is an instance of club throwing event. I'm not sure it is an instance of club throwing in general thow. Should we have two items for club throwing and for club throwing event ?

club throwing events are instances of athletics events, so clearly <club throwing event> is a subclass of athletics events. Same question : are athletics events athletics themselves, or should we have an item which would identify to the wp category itself, club throwing events ? Then <athletics (Q542)> would be composed of this <athletics events>.

I also think that <athletics at the 2008 Summer Paralympics - men's club throw F32/51 (Q4814879)> is a part of <the 2012 paralympics athletics>.

Does this make sense ? TomT0m (talk) 16:59, 2 June 2013 (UTC)

I edited your post to use the Q item template. Hope you don't mind. Filceolaire (talk) 13:01, 3 June 2013 (UTC)

Au contraire, I should have done that from the beginning :). I'm starting to wonder why my message seems to be gone in space, is it so much out of scope, totally unanderstandable or totally uninteresting :) ? TomT0m (talk) 17:57, 3 June 2013 (UTC)

I think it corresponds to the way things are currently done, though I feel that "part of" could be somewhat clearer (see also Property_talk:P361#Neutrons). --~~

As I see it, the paralympic club throwing is part of (P361) the paralympics but it is also an instance of (P31) club throwing which is a subclass of (P279) athletics. I'm not sure we need to separate club throwing events and athletics events from club throwing and athletics.

It may be useful to replace instance of (P31) here with 'type of athletics event' as we have done for some other basic categories, to better match the infoboxes and make it easier for editors to find the right items. Filceolaire (talk) 15:00, 4 June 2013 (UTC)

There is a proposal for a new "Sport" property under consideration which would do this. Filceolaire (talk) 06:19, 7 June 2013 (UTC)

Please review the "Guidelines for sourcing statements" before June 15

After almost 2 months of deliberations, we are aiming to close the RfC on References and Sources on June 15. The result of the discussions has been condensed into the proposed Guidelines for sourcing staments.

The implications of these guidelines are:

• All statements in Wikidata should be sourced, except in specific cases (common knowledge, easy verification through linked external source, or when the item itself represents a source)
• Sources (books, articles, trusted databases, media) fulfill notability criteria for item creation.
• If the source references a specific edition of a book then it is acceptable to create an item for the edition too.
• Web pages do not require an item, only the Web Page property (as soon <datatypes-type-iri> is available). However it is advised to add Title, Author and Quote to help find the article again if the url changes.

Some Q&A clarifications:

• What happens with translations? Will each Wikipedia language article link to a different item? NO, editions and translations will not be used for linking Wikipedia articles, unless the Wikipedia article is specifically about an edition or translation. Wikipedia articles will link to the base item as now, but the book infoboxes will have to be modified to feature an edition, either entered manually or automatically chosen based on the language of existing linked editions.
• To create an item for each edition is a pain in the ass. True, that is why Bugzilla: 49067 • 49068 are suggested to make life easier to Wikidata users.
• Can I enter ALL editions of a book? No, create only items for those editions that are going to be used either as sources, or for infobox data.
• I want to cite multiple editions of book X, but edition 42 was split by forces of evil in 127 fragments, whose first words combined form an ode to the beauty of data... help! Extreme cases will be decided on a case-by-case basis either on Help:Sources or Wikidata:Books task force.

--Micru (talk) 22:10, 2 June 2013 (UTC)

It is possible for a statement to have multiple sources and for the sources to have a qualifier property for the language so the various language wikipedias can select a source in their language if available. (Lua can do that. Can't it?) Filceolaire (talk) 13:31, 3 June 2013 (UTC)

Yes, it is possible to have several sources for an statement and each one can be in a different language (either specified as a qualifier or in the item linked). It should be possible to write a module that would give priority to the source in the language matching the Wikipedia where it is being used. That is still to be done (not sure if it has a bugzilla report, but it should have one).--Micru (talk) 14:26, 3 June 2013 (UTC)

• So what happens with web pages that have items already anyway? --Yair rand (talk) 22:25, 2 June 2013 (UTC)

• It depends. Can you point to one example? And how many cases are they?--Micru (talk) 22:57, 2 June 2013 (UTC)

• The section about online databases should also have the "point in time (P585)" statement. --Tobias1984 (talk) 11:07, 3 June 2013 (UTC)

 Done Filceolaire (talk) 13:22, 3 June 2013 (UTC)

• Some thinks: references format in Q8012976 (it is given as sample) has one large defect. The value is not verifiable. Suggested approach is similar to Wikipedia`s approach. But Wikidata is another project. Data from Wikidata must not be designed for human only, its must be designed for computers too. One example: I imported only 3500 values of COSPAR ID (P247) property from Wikipedia. I find at least 20 errors in these data using automatic verification procedures. I think 0.5% error rate is very bad result. This example shows that Wikipedia`s sourcing approach is ineffective in large data missives management tasks. I suggest to use this approach on non-main basis. Main approach must be based on links to external databases as I think. — Ivan A. Krestinin (talk) 18:25, 3 June 2013 (UTC)

Maybe preference for sources with links like doi can be added in the guideline. The journal source in Q8012976 in fact has a database url (I didn't find a valid identification method for the database) . And I have proposed to create a property with IRI type for it. --凡其_Fanchy 02:21, 4 June 2013 (UTC)

• That sounds like valid point. But still, there are some subjects where databases are inadequate. Beside, text sources are useful for humans when they provide qualifications/background about the claim. So perhaps we should recommend to have both text sources for humans and database sources for machine sanity checks. --Zolo (talk) 20:32, 3 June 2013 (UTC)

• I've added a English source to the example Chenqiao Coup (Q8012976). Feel free to improve it. --Stevenliuyi (talk) 19:59, 3 June 2013 (UTC)
  • Excellent! I have added the language property, so later on a script can be selected automatically which source to display depending on which Wikipedia the claim is used.--Micru (talk) 21:01, 3 June 2013 (UTC)

What to do with unsourced statements

• What do we do with statements that are unsourced? In particular, should we ask bot operators who mass imported unsourced statements to undo their edits? For instance, Dexbot (talk • contribs • logs) has added many date of birth/death info with no source other than Wikipedia. I believe we should be quite strict about this if we want to build the project on a sound basis. Pichpich (talk) 01:39, 3 June 2013 (UTC)
  • I think for now we could cut the importers some slack and let most of them to stay so we have the opportunity to source the statements properly. Then we could raise the standards, if needed, in the nearby future. FallingGravity (talk) 03:45, 3 June 2013 (UTC)
    • If we want to motive users to add sources, there is other ways, such as displaying unsourced statements in pedias and infoboxes a little differently and unpleasantly, an equivalent of redlinks for missing pages ... when there is no source, a human must do the job, we do not have Watson :) 08:23, 3 June 2013 (UTC)

In my opinion there are two kinds of unsourced statements:

• The ones that don't need source (they fall into any of the exceptions suggested in the guidelines)
• They really need a source (imported from Wikipedia doesn't count as such).

For the second case we could add a qualifier stated in (P248) plus Template:Citation needed (Q5312535) (or a specific item?), which should display the citation needed template when it is used in Wikipedia. I am also in favor of using annoying colors to attract more activity ;) --Micru (talk) 14:17, 3 June 2013 (UTC)

We need to distinguish between the occasional unsourced statement added by a well-intended newbie and mass additions of unsourced statements by bots. For the former, some combination of stated in (P248) and Template:Citation needed (Q5312535) makes sense but we absolutely shouldn't knowingly import unsourced statements and paint infoboxes with all sorts of colours as a result. I'm pretty sure that Wikipedia editors wouldn't be too pleased to see their infoboxes messed up just because we decided to authorize a bot to do something that's contrary to our own guidelines. Pichpich (talk) 15:27, 3 June 2013 (UTC)

I'm not sure that stated in (P248) plus Template:Citation needed (Q5312535) is a good idea because it'll require a big work of maintenance to add it to every statements that needs it. A better way is, I think, to let templates and modules check if, for statement main properties that need a source, there is no sources (that is nearly equivalent). Tpt (talk) 16:11, 3 June 2013 (UTC)

How would templates differentiate statements that need a source from statements that don't?--Micru (talk) 17:00, 3 June 2013 (UTC)

Hum, good question. Maybe from the main property? Example: VIAF identifier -> no needed source, date of birth -> source needed. Tpt (talk) 17:31, 3 June 2013 (UTC)

• We have to stop all unsourced data import and we have to be clear about that: unsourced data will be deleted in a near future. Even data added without sourced by newbies will be deleted: we let wikipedia without strong policy about sourcing and we see the results now in wikidata. The properties which don't require a source have to be listed because it will be a mess and a time consuming task to discuss each time the necessity of a source or not. Then bots can be trained to detect unsourced data and to list them. Snipre (talk) 19:14, 3 June 2013 (UTC)

I agree that all unsourced non-trivial data should be removed or sourced. But because well-intended newbies typically add a handful of statements, finding sources for these statements rather than deleting them is both feasible and nice to newbies. Bots (such as Dexbot recently) add thousands if not tens of thousands of statements and the only practical solution to such a mess is to ask the bot operator to undo the additions. I also believe we should urgently change the wording of Wikidata:Bots which simply says "Add sources to any statement that is added" without explaining what an acceptable source is. It should be the responsibility of bot owners to show that they are either importing statements so simple that they don't need a reliable source or that they are importing statements from a reliable source. Pichpich (talk) 21:09, 3 June 2013 (UTC)

Until this discussion has yielded a clear policy on citations, and the datatype "url" is available, it is too early to start a discussion about deleting statements. Nobody is going to put a lot of work into sources if one of the most important datatypes is missing and it is not yet clear if a lot of the current source-statements have to be redone. In the future I would like the "imported from Wikipedia"-sourced statements to be highlighted orange and the unsourced statements to be highlighted red, so statements needing work would stick out. --Tobias1984 (talk) 21:56, 3 June 2013 (UTC)

Why is it too early to delete bot-added statements? Undoing those edits is completely trivial and they never were really approved of to start with. Pichpich (talk) 22:21, 3 June 2013 (UTC)

 Comment See related proposal to tweak the bot policy. Pichpich (talk) 01:13, 4 June 2013 (UTC)

It is too early to delete but we can already warn contributors that unsourced will be deleted. Snipre (talk) 09:22, 5 June 2013 (UTC)

As a not-totally newbie, and a librarian, I added dozens of dates (birth/death) to items, from reliable source (BNF Authority file for ex.), but I did not find how to add the source to the property… how must I do in such cases ? there is not item for this source… should I create it ? how ? I think this must also be explained to "human" contributors, since it is neither obvious, neither easy :) --Hsarrazin (talk) 13:38, 4 June 2013 (UTC)

Ideally we'd want the link to the precise page but for now I think you can use imported from. Pichpich (talk) 14:02, 4 June 2013 (UTC)

Of course, I thought of "imported from"... my problem is "what to do when the Source does not exist in wikidata ?" - how should I create it ? what info do I need to input, etc. :)

for an example Q255921 - I put the source Bibliothèque Nationale de France, but in reality, it's "wrong" - the real source is the Authority file of BnF, which does not exist in wikidata… so what ? should I add it ? and if so, how ? --Hsarrazin (talk) 14:45, 4 June 2013 (UTC)

Ah yes... It's true that using Bibliothèque Nationale de France is a bit sloppy but I guess we could do that for now. Creating an item for the BNF's database is closer to what we want although it's still imprecise. You should also check out this proposal for using a bot to import parts of the BNF data. As far as I can tell, the exact format for sourcing has not been decided but there are doubts on whether this is even compatible with Wikidata's free license. Pichpich (talk) 15:18, 4 June 2013 (UTC)

I created this source-item Tectonic map and overall architecture of the Alpine orogen (Q13416617) from this page source-source. Should I wait for the URL datatype to source this or should it say "stated in" and create an item called "SpringerLink"? I have to create all the authors apart from the first one. How should those be sourced? Also with the URL? --Tobias1984 (talk) 15:28, 4 June 2013 (UTC)

But it is from a journal called "Swiss Journal of Geosciences"(Eclogae Geologicae Helvetiae ). The issn is for the journal. SpringerLink is the website of the publisher. The item itself is the source. With the doi link, it can be verified. So no need to source it. Just refer to it with <stated in> Tectonic map and overall architecture of the Alpine orogen (Q13416617) --凡其_Fanchy 16:54, 4 June 2013 (UTC)

If the article is part of a book, then it shouldn't be "instance of book".--Micru (talk) 18:01, 4 June 2013 (UTC)

I don't get it either. Somebody says its an instance of a book, somebody removed the publisher. This will need a lot of explaining and checking because it will only be useful if everybody does it in the same way. --Tobias1984 (talk) 19:48, 4 June 2013 (UTC)

I removed the publisher, because it is more appropriate to be stated in the journal item Swiss Journal of Geosciences (Q13416933)( all articles from the journal are published by the publisher ). Generally I wish the source of statements of wikidata items should be mostly wikidata items too. (other than pure URL, a url not corresponding to any journal articles, books or something else that can be recorded in wikidata)--凡其_Fanchy 20:28, 4 June 2013 (UTC)

And you agree that all the authors of the article should be created? --Tobias1984 (talk) 20:54, 4 June 2013 (UTC)

Yes, currently we need to leave the article item to create the author items. if this bug49068 solved, that process will be fast.--凡其_Fanchy 21:24, 4 June 2013 (UTC)

An article is part of (P361) a scientific journal (Q5633421) or a magazine. An edition is an instance of (P31) the original (first edition) which is an instance of (P31) a book (Q571) book (no item, though we also have reference work (Q13136). Filceolaire (talk) 01:04, 5 June 2013 (UTC). Editted Filceolaire (talk) 13:16, 5 June 2013 (UTC)

If this wiki were made five or six years ago, I had no objection about deleting non-trivial data imported from Wikipedia but now We have tons of important information that need to be imported ASAP. Wikipedia is one of our sister projects we should trust their people, and wikipedians want to use wikidata information. My idea is import this information from WP and ask people (users of WP or WD, that doesn't matter for me) to change this source to something more reliable. I can write a code to harvest sources too but It's too dangerous to run Amir (talk) 16:48, 4 June 2013 (UTC)

I would agree with Amir - it's not because the data come from wp that they are not reliable… we should keep them, and progressively convert wp sources to the original (or more "reliable") sources… that would be long, but certainly better than delete all unsourced data, which would reduce the amount of available data to a very small percentage of what has been collected… what would be the interest of the project, then ? --Hsarrazin (talk) 16:59, 4 June 2013 (UTC)

Wikipedia is full of wonderful editors (such as myself!) but it is not a reliable source despite its efforts to come close to that. It has come close to that because it has increasingly insisted on proper sourcing. If we blindly import import massive amounts of non-trivial data, we'll not only go against Wikidata's mission statement, we'll also see a collapse in the support for using Wikidata statements in Wikipedia articles. Different wikis have different sourcing policies but citing de.wiki to support a fact on en.wiki is considered a big no-no. By extension using a piece of information of Wikidata gathered on de.wiki will equally be frowned upon. There's already a significant group of editors who are very skeptical of Phase 2 features and we don't want to give them a "why would we import unsourced crap" argument. There's no rush here: it's quicker to just let bots run wild and have a large crappy database but what we need is a database with credibility. Pichpich (talk) 17:47, 4 June 2013 (UTC)

well, I agree AND disagree… partly because I don't really understand what you call "trivial" data and non-trivial data… if you could give me examples, I would be very glad…

also I did not say we should blindly import, I said we should not delete what has already been imported and work on it, which is not exactly the same :) - I perfectly agree that a database full of crap is useless, but an empty database is too…

the biggest origin of the problem, I think, is, data have been massively imported before defining a proper sourcing policy…

as for myself, I do not import blindly data, I verify them one by one, and add them by hand, BUT I have a severe problem to indicate the source, as it is not really explained how to "create" a source…

these should be the priorities to establish… : 1 - what is a "proper" source - 2 - how to add it to wd if it does not exist - 3 - how to use it... - 4 - make a clear help page for contributors… --Hsarrazin (talk) 18:47, 4 June 2013 (UTC)

In the proposed policy, there are exceptions to the sourcing requirements and that's what I'm referring to when I talk of trivial data. It's not uninteresting data, but it's data that is so basic and impossible to get wrong that sourcing it is overkill. The way I see it, this data (and there's still a lot of it to import) is the backbone of the database: we need it, we need bots to import it, we need to figure out smart ways of getting it all and we need to develop tools to verify that it's error-free or as close as we can get to that. So far, almost all of the statement added by bots are trivial and I'm certainly not suggesting that any of that should be deleted. To a certain extent, I think the lack of a sourcing policy was not really a problem until some bots started to import more complicated statements. Pichpich (talk) 19:01, 4 June 2013 (UTC)

Importing these data in this scale takes at least years if we don't want to use bots. I have an idea to let bots add these data if one of these two conditions has been satisfied: 1-if data in WP is sourced (the bot can check that but checking the statement is stated in the source or not, It's not something that can be done easily and by bot) 2-if the article exists in other languages of WP bot must check that the statement is stated in that WPs too or not(actually not all of them, 4 biggest wiki is enough). I think Germans wouldn't mind if what we are harvesting from English WP is already mentioned in their wiki. If we work on latter (the option I prefer more) it's better because we don't add more data in that Wikis, we just check the data is already exist or not Amir (talk) 19:45, 4 June 2013 (UTC)

Of course it takes time to do things right but are we short on time? We could significantly speed up the development of pt.wiki if we machine-translated articles from en.wiki and in many cases, the translations wouldn't even be that bad. We don't do it because pt.wiki has standards. Similarly, we should use bots as much as we can without violating the basic promise that Wikidata supports the notion of verifiability. Pichpich (talk) 19:53, 4 June 2013 (UTC)

We have the same situation in almost all of wikis, Persian is same too but if we want to be a useless and empty database that users of WP have to add information manually. I think they prefer to use the old system. My suggestion (the latter one) won't violate any policies in their wikis because we won't add anything so we don't need to reference them. we are just transporting them from a wiki to another whether they are properly sourced or notAmir (talk) 20:11, 4 June 2013 (UTC)

But the choice is not "empty database of reliable data" vs "gigantic database of unreliable data". There are plenty of sources from which a considerable amount of reliable data can be harvested and that's where we need to start. I also don't think we should be so pessimistic about what people can do manually: after all, humans wrote most of Wikipedia and that hasn't turned out so bad. Pichpich (talk) 20:33, 4 June 2013 (UTC)

Look at early versions of Pedias, you will not find so many sources. The chance of Wikidata is that Pedias already have big communities with a strong culture of sourcing their claims, but it came with years, with incentive to source such as ref needed or unsourced article templates. Wikidata is a new project, its goals are unclear to many users, its community is (right now) smaller, user needs to learn new concepts, the interface is unfinished. People could stop at the beginning with a bad feeling and nether come back if we set standards to high at this moment. TomT0m (talk) 20:53, 4 June 2013 (UTC)

I'm not proposing to go crazy on individual editors that add unreferenced or poorly referenced statements. I want to prevent bots from importing literally millions of unsourced statements in clear contradiction with the proposed guideline. I don't think that's too much to ask. Pichpich (talk) 21:01, 4 June 2013 (UTC)

Be careful when you compare Wikipedia and Wikidata. Creating of articles on Wikipedia is exciting activity. But is exciting activity manual database creation? — Ivan A. Krestinin (talk) 22:09, 4 June 2013 (UTC)

Of course it is! I am having a lot of fun :) Btw, I think it is a big danger to "take data only and not give back". Wikidata is supposed to grow organically together with Wikipedia. Importing too much data without using it in Wikipedia would make the project grow apart instead of together.--Micru (talk) 01:17, 5 June 2013 (UTC)

I see a lot of users; in Pedias, referencing using formated string and not using templates at all for that. This goes beyond sourcing claims in wikidata but for them to change their habits and use Wikidata for that purpose will need more than a few guidelines, it will need good interfacing, maybe more, such as easing their lives. I think a good chance that their reference is already in the database will be a good starting point, so preimporting books and articles with some criteria might be something good. TomT0m (talk) 10:03, 5 June 2013 (UTC)

After thinking about it for a while, the main problem is that the concept of sourcing in Wikipedia is totally different to that of Wikidata. In Wikipedia the reference/source is "unattached", meaning that while it might be (spatially) near the statement that it supports, there is no logical link between both. In Wikidata there is a clear link, and that strength is simultaneously a difficulty, because it means that there will be need to replicate the concept in Wikipedia if we want to do a smooth transition. For instance it would help if "Template:Birth date" would include a machine readable citation, that way the transition would be much effective, importing both the claim and the source. Any thoughts about this?--Micru (talk) 13:32, 5 June 2013 (UTC)

I think if we want people of Wikipedia to come and help us. It's better to work on citation instead of boring job of adding data (which is hard to work on when you don't have anything). I can tell my bot to harvest citations of material but problem is my bot has to check the data is stated in the original source or not, and this is not what a bot can do, I can harvest sources blindly and make people to check about that if you want Amir (talk) 14:44, 5 June 2013 (UTC)

Good point and this echoes TomT0m's comment on the interface. I'm not sure how to do this but it would be nice to have some easy way of providing one source for many statements. For instance, even a short biography of a politician (for example) will simultaneously be able to confirm date/place of birth/death, party membership, political positions held, alma mater and so on. You could easily extract 20 statements from that and adding the same reference for each of them is horribly tedious. Pichpich (talk) 15:00, 5 June 2013 (UTC)

I guess we could have two columns, one for statement and one for sources (or book or article). Once a source is added, one click on it would select it, then we could select statements it would apply to. It might be also useful to add an easy way to add annotations on a couple (statement, edition) such as a page number, on each statements (maybe with a similar interface that we have now to add a source or a qualifier) TomT0m (talk) 15:09, 5 June 2013 (UTC) - EDIT - actually this would work very well with the idea of source and property suggestion. TomT0m (talk) 15:13, 5 June 2013 (UTC)

That's a pretty good idea and ideally, developers could start thinking about implementing something like this. In the meantime, some competent script writer might be able to get some crude approximation to this. Pichpich (talk) 15:27, 5 June 2013 (UTC)

I also like the idea, and if it could be combined with an option to show->select->import any machine readable sources being used in the corresponding Wikipedia article that would be even better.--Micru (talk) 15:58, 5 June 2013 (UTC)

Option 1: Accept to import unsourced data into Wikidata that has been approved to be shown in Wikipedia as unsourced

After hearing both sides of the discussion about bot imports, I think we need to find a solution that pleases everyone, if not totally, at least partially. Both arguments might be true, "more editors might be attracted by large quantities of data" vs. "more editors can be attracted by high quality of data", we don't know which one will be more right on the long term, therefore everyone should be reasonable in their wishes. At least I think that we share the wish to attract more editors to Wikidata, so that should be our primary aim.

If we want more editors to come and to help sourcing statements (like those imported by bots), first of all make sure that we have all the properties needed for sourcing the statements that you are importing from Wikipedia or other sources. Try to source a few items manually with the described methods. The web page data type might take a while, but maybe meanwhile you can give a hand writing the documentation, clarifying cases, and enhancing help pages?

In order to grow organically both accepting unsourced data, but with the aim to source it, it would be good to make sure that Wikipedians want to use the data that is imported into Wikidata, even if they have to display it with [citation needed] templates. It is something that will have to be explained in the Wikipedias, that without their help (and the annoyance of having unsourced statements), it would be hard for Wikidata to reach its goal and to grow in number of participants. If that is acceptable, my suggested workflow for importing data from Wikipedia would be:

1. Discuss in Wikidata if the data being mass imported would need sources
2. If so, ask in at least one local Wikipedia for permission to replace their data with linked data to Wikidata
3. The data linked in Wikipedia should display the [citation needed] template
4. If that is acceptable for at least one Wikipedia, then it is acceptable to import that data into Wikidata
5. As the data gets sourced, collaborate spreading it to other Wikipedias

In my opinion that procedure would:

• make contributors in Wikipedia conscious that their help is needed for sourcing imported statements
• aim to increase the number of sourced statements in Wikidata
• spread the sourced statements to other Wikipedias, so that the community at large benefits from this work

I hope this proposal serves as an initial step towards a compromise.--Micru (talk) 19:09, 4 June 2013 (UTC)

You might have a hard time convincing local wikis to replace their sourced data with unsourced data that comes with a citation needed template. Instead, you could convince local wikis to display some sort of "help move this tidbit of info to Wikidata". This helps to attract editors to Wikidata who, in turn, might further promote Wikidata on their local wikis. It's important to realize that adding info is the fun and exciting part and that sourcing info is the tedious part. If we let bots do the fun part, the odds of attracting editors to do only the tedious part won't be that good. Pichpich (talk) 19:59, 4 June 2013 (UTC)

On it.wiki, we already and massively use Wikidata statements in templates, such as {{Controllo di autorità}}, and even {{Thesaurus BNCF}} which makes use of BNCF Thesaurus ID (P508) since its creation. --Ricordisamoa 21:48, 4 June 2013 (UTC)

And that's great! These statements don't need to be sourced and they were added almost entirely by bots. Nobody is suggesting that we stop this type of development. Pichpich (talk) 03:23, 5 June 2013 (UTC)

 Oppose I think we should start with importing data which has reliable sources so we have something good to offer the wikipedias. After that (when they can see some value in wikidata) we can start adding the data to which we will need to ask them to add sources by hand. This will change your workflow sequence> Filceolaire (talk) 13:24, 5 June 2013 (UTC)

Option 2: Prepare data and citation in Wikipedia before importing them into Wikidata

This option would mean that data is prepared in Wikipedia before importing it into Wikidata. It would require to have joint templates in Wikipedia for claims and their sources, something that would be equivalent to the way Wikidata sources the information. Example: now in en-wp "Template:Birth date" contains only the birth date of a person without the source for that claim, it could be extended to add sources to it, or a new "Template:Cite claim" could be created with would have as parameters the birth date template and the citation template.--Micru (talk) 13:44, 5 June 2013 (UTC)

It might be difficult to put this in place but the idea has a few interesting features. First it allows editors to contribute to Wikidata without ever setting foot on Wikidata and this is important because Wikidata is not user-friendly at all. Also it could be a fairly quick way of validating a lot of data since the effort for Wikipedia editors would be relatively small. Pichpich (talk) 16:42, 5 June 2013 (UTC)

The hardest part is to convert something that is not machine readable into something that it is, because a bot won't have it easy to convert text where the author name is written into a link to the corresponding author item. It could work to a certain extent with web link references, or references that offer some anchor to get reliable data (like ISBN), in other cases more intense human intervention will be needed linking to the right author, the right publishing house, etc. In any case, for the near future there will be the need to develop some tools for Wikipedia citation templates that can interact directly with Wikidata.--Micru (talk) 19:00, 5 June 2013 (UTC)

Option 3: Add extra namespace for sourced only data

This Namespace can be accessed with a different prefix in Wikidata. Problem solved for everyone. --FischX (talk) 15:18, 6 June 2013 (UTC)

I don't think this would work since each page has a mixture of sourced and unsourced data and some data that doesn't need sources. Filceolaire (talk) 06:23, 7 June 2013 (UTC)

Citation Workflow

Something that seems to work (and will benefit from wikidata) to source statements on pedias is citing by doi or by isbn, with a bot that creates later a template by importing all the information. We could replicate this workflow on Wikidata by just adding a doi or isbn with maybe pages properties. Do someone knows of these bots and their owners ? TomT0m (talk) 11:47, 5 June 2013 (UTC)

I just started a discussion about that on the academic journals project on enwiki feel free to add your thoughts. TomT0m (talk) 14:23, 5 June 2013 (UTC)

Based on the conversations about sources I have send some ideas about sources to the mailing list.--Micru (talk) 14:05, 6 June 2013 (UTC)

Reopen a pending proposal

Looking at the pending proposals I noticed that Wikidata:Property_proposal/Pending#Official_name_.2F_Name_.2F_Nom_.2F is listed as approved with multilingual text datatype. I feel that this should be monolingual text type (we don't want people making up new versions of official names in other languages). How should I go about reopening this discussion.

I did raise this in the original proposal discussion and I thought I had consensus on my side but..... Filceolaire (talk) 08:57, 6 June 2013 (UTC)

Why shouldn't there be official names in other languages? Canada has an official name in German, which is Kanada. The sources for official names are dictionaries or atlantes in each language. Otherwise the property would have to be named "Official name, in language spoken by most people in that place". But what would we do with mulit-lingual cities, countries etc... --Tobias1984 (talk) 09:10, 6 June 2013 (UTC)

It was also my feeling that the consensus was that official name should be monolingual text, and that there should a separate statement for each language, so I am also surprised to see this. Not many posted about the data type, but those who did seemed to agree about monolingual text. The main reason for that datatype is that you may need to have different qualifiers (for instance from and to dates) and sources for each official name. Byrial (talk) 21:08, 6 June 2013 (UTC)

Tobias: The source of official names is not a dictionary. It is the government of the country. That is what makes them official. Many countries have official names in more than one language (e.g. for multi-lingual cities, countries etc. as you said) but not in all of the languages we can handle here on wikidata. Filceolaire (talk) 05:14, 7 June 2013 (UTC)

Large donation by Yandex

Hi everyone,

I'm happy to let you know that Yandex, an internet company from Russia, made a donation of 150000 Euro to Wikimedia Deutschland for further development of the core of Wikidata. It's great to see more companies stepping up in not only using Wikidata but actively supporting its development. The official press release is at https://www.wikimedia.de/wiki/Pressemitteilungen/PM_06_13_Wikidata_Yandex

Please let me know if you have any questions.

Cheers --Lydia Pintscher (WMDE) (talk) 09:14, 6 June 2013 (UTC)

This is great, Yandex is one of the few Russian companies who are really interested in serving the customers and not in getting money from them for nothing or in money laundering.--Ymblanter (talk) 09:55, 6 June 2013 (UTC)

Great, but plz don't spend all 150000 for cakes ;-) --Ricordisamoa 10:52, 6 June 2013 (UTC)

Haha. Comment by anonymous developer: But whyyyyyyyyy? :P --Lydia Pintscher (WMDE) (talk) 11:07, 6 June 2013 (UTC)

Because we need you healthy. Even anonymous developers.--Ymblanter (talk) 12:03, 6 June 2013 (UTC)

 woo! :) ·addshore· ^{talk to me!} 12:28, 6 June 2013 (UTC)

Awesome! Nice to see someone stepping forward with that kind of donation - hopefully there will be more of that in the future as well. Ajraddatz (Talk) 21:01, 6 June 2013 (UTC)

Looking for help to check some editions

Hi, before May 15, 2013 World Cup 2010 delete a lot of links from many pages like Q41819, Q438993, and others. I can't check these actions, and I don't know if actions are ok or wrong editions (but are suspects editions). For exemple, here, he/she deletes some good links. Can somebody help me to check the user editions, please? Jmvkrecords ⚜ Intra Talk 19:10, 6 June 2013 (UTC)

It seems he/she has been deleting incorrect links to fawiki but in doing so also deleted a lot of good links, i have already corrected some of his/her actions. I am currently busy with restoring the links to Q52174, which means merging a lot of pages. - Foxie001 (talk) 20:11, 6 June 2013 (UTC)

Thank you for your help, Jmvkrecords ⚜ Intra Talk 20:14, 6 June 2013 (UTC)

We should be thanking you for discovering these edits. Think al the wrong edits have now been reverted. Luckily for us this user seems to have started to understand how things work on wikidata since May 15. - Foxie001 (talk) 20:50, 6 June 2013 (UTC)

language links shortcuts

I was talking with someone at the hackathon who suggested that the software create links directly to wikipedia articles. i.e. http://www.wikidata.org/wiki/Q1/en or something similar which would redirect you straight to http://en.wikipedia.org/wiki/Universe... Of course there are many different ways that this could be implemented...

• http://www.wikidata.org/wiki/Q1/en
• http://www.wikidata.org/wiki/Q1/site/en
• http://www.wikidata.org/wiki/Q1?visit=en
• http://www.wikidata.org/wiki/Q1:en
• http://www.wikidata.org/wiki/en:Q1

etc. Any thoughts? ·Add§hore· ^{Talk To Me!} 23:08, 27 May 2013 (UTC)

The last would be natural, I suppose. Infovarius (talk) 07:30, 28 May 2013 (UTC)

(Un)fortunately we can't prevent the redirection of interwiki links ("www.wikidata.org/wiki/en:Q1" is automatically resolved to "en.wikipedia.org/wiki/Q1"), but User:Ricordisamoa/SitelinkSubpages.js works perfectly with the 1st and the 4th format. --Ricordisamoa 08:41, 28 May 2013 (UTC)

Is this something that could be implemented across wikidata? :) ·Add§hore· ^{Talk To Me!} 21:54, 31 May 2013 (UTC)

Anyone can use it in his common.js, or it could be made a gadget. --Ricordisamoa 15:48, 2 June 2013 (UTC)

Hmm the initial thought was that then Wikidata could be used as a place to link directly to wikipedia articles on a specific subject without having to worry that they may change name, Using wikidata and a unique object for the request and asking for the article in a specific language forwarding you to the page from other external pages (i.e. not logged in users with a .js) ·addshore· ^{talk to me!} 19:43, 2 June 2013 (UTC)

A real HTTP redirect? --Ricordisamoa 05:34, 3 June 2013 (UTC)

Yes! :) ·addshore· ^{talk to me!} 08:22, 3 June 2013 (UTC)

The suggestion was inspired by services such as K-samsök in Sweden. If you want the rdf you go to http://kulturarvsdata.se/LSH/objects/7787. But by adding the html/-prefix (http://kulturarvsdata.se/LSH/objects/html/7787) you end up at the relevant museum page. The benefit apart from protecting against linkrot is that the human-readable and the machine-readable information share the same naming structure making it easy to switch between the two without having to parse the page or send query to the api. Since wikidata additionally contains a one-to many relationship for data to human-readable the gain here would be even larger.

Museums I work with frequently want to store the Wikipedia links for various artists/events/artworks. Rather than storing the changeable article titles I've been trying to get them to use the wikidata identifiers instead. The step which is missing for them is an easy way of going straight from there to the artcle in the relevant language. /Lokal Profil (talk) 09:53, 3 June 2013 (UTC)

I may file a bug on bugzilla :) ·addshore· ^{talk to me!} 17:37, 8 June 2013 (UTC)

Echo?

Echo... echo... echo...

Do we feel like enabling the Notifications ("Echo") extension? Personally I'm a big fan of it. Allows editors to know when their changes are reverted, when they're mentioned somewhere, and when a page they create is linked to. (The last of which could be very useful here.) Also has a "thanks" feature, which fosters WikiLove, and could be a nice way to cross cultural/linguistic boundaries on a multilingual project like this. — PinkAmpers&^{(Je vous invite à me parler)} 14:00, 4 June 2013 (UTC)

Yes please. I would like to have this too. Filceolaire (talk) 14:26, 4 June 2013 (UTC)

O_o no Vogone talk 15:26, 4 June 2013 (UTC)

Especially here on Wikidata, we would probably just get spammed with notifications, especially admins and users who create many items. Furthermore, it seems more like something for facebook to me (like/thank buttons for edits). Vogone talk 15:28, 4 June 2013 (UTC)

I'd love it! opposing below·addshore· ^{talk to me!} 15:29, 4 June 2013 (UTC)

I agree with Addshore. Plus if people don't like being ping when they are mentioned, disable it. Don't like being pinged when your page is linked to? Disable it. Don't want to be thanked and notified? Disable it. No edit revert? Disable it. It simply provides control to the user about what they want to be notified about plus it allows email notifications for more thing. Personally, I fully agree with adding it to Wikidata and I agree with what PinkAmpersand said Also has a "thanks" feature, which fosters WikiLove, and could be a nice way to cross cultural/linguistic boundaries on a multilingual project like this. John F. Lewis (talk) 15:35, 4 June 2013 (UTC)

Why do we even have watchlists then? Vogone talk 15:43, 4 June 2013 (UTC)

Echo will eventually be automatically enabled on Wikidata, and all WMF projects for that matter. So, enabling it now would mean that the wikidatians would be testing the extension, just like English Wikipedia is doing right now. I am fine with that.--Snaevar (talk) 16:00, 4 June 2013 (UTC)

Yes turn it on. If someone don't want the notifications, then it is easy enough to turn them off in Special:Preferences#mw-prefsection-echo. Jeblad (talk) 16:21, 4 June 2013 (UTC)

I tried to disable it completely on enwiki, but it does not seem possible. Furthermore, I don't see why a more aggressive version of Special:Watchlist should be tested here … Vogone talk 17:32, 4 June 2013 (UTC)

I don't really like Echo specifically, but I rather do like the idea of Wikidata becoming a place where cool new stuff gets tested before going to Wikipedia and the other projects. --Yair rand (talk) 16:34, 4 June 2013 (UTC)

 Support enabling Echo, even if only as a test. I can see how some aspects of it wouldn't work on Wikidata as well as they would on other wikis, but it's worth a shot. TCN7JM 17:27, 4 June 2013 (UTC)

 Support. Personally I don't find it very useful but there's no good reason to deny it to those who want it. Mushroom (talk) 17:46, 4 June 2013 (UTC)

 Support. Tpt (talk) 17:58, 4 June 2013 (UTC)

I like it, but I  Oppose until there's an opt-out for those who don't like it.--Jasper Deng (talk) 17:59, 4 June 2013 (UTC)

Um, you do realize that it can just be disabled for individual users via Special:Preferences? --Jakob ^{Scream about} _{the things I've broken} 18:11, 4 June 2013 (UTC)

Well, in all fairness, at least the way it's set up on En, you can't disable it completely. You still get talkpage notifications the new way no matter what. I'm not sure if that can be changed on a per-project basis, though. I can't get on IRC at the moment, but when I do I'll see if I can find Ironholds. — PinkAmpers&^{(Je vous invite à me parler)} 20:35, 4 June 2013 (UTC)

It's probably set up that way because with the death of the Orange Bar of Doom () there is no other way to get talk page messages. --Jakob ^{Scream about} _{the things I've broken} 12:28, 5 June 2013 (UTC)

 Weak support: not a must-have, but could enhance some users. --Ricordisamoa 18:03, 4 June 2013 (UTC)

 Support -- I initially was against the Echo system, but I've actually kind of come to like it. If you don't like it, you turn it off, if you do you keep it on, so what's the problem? --Jakob ^{Scream about} _{the things I've broken} 18:11, 4 June 2013 (UTC)

There is no way to turn it off completely. --Rschen7754 23:17, 4 June 2013 (UTC)

Has it been localized properly for a multilingual wiki? --Rschen7754 19:34, 4 June 2013 (UTC)

Hmm. It appears not. :( That is indeed an issue. — PinkAmpers&^{(Je vous invite à me parler)} 20:38, 4 June 2013 (UTC)

 Support -- Great idea; the feature allows for easier collaboration on current projects --JustBerry (talk) 21:02, 4 June 2013 (UTC)

•  Oppose for now, I tested this great feature (I love it) on a my wiki for some languages, It has some problems in translating and i18n (specially for rtl langs). if we use this on English WP I wouldn't mind but this wiki is international (interlingual is a better word) wiki so We have to solve issues before enabling it :) Amir (talk) 21:19, 4 June 2013 (UTC)

•  Oppose localization issues for now. --Rschen7754 23:18, 4 June 2013 (UTC)
•  Oppose Wikidata is one of the more multilingual projects, so let's hold off on this until localization has improved (and perhaps a complete opt-out for those who don't like it) Ajraddatz (Talk) 00:05, 5 June 2013 (UTC)
• Indeed localization issues would be an issue!  Oppose ·addshore· ^{talk to me!} 08:44, 5 June 2013 (UTC)
•  Support when localization is fixed --Paperoastro (talk) 17:37, 5 June 2013 (UTC)
• I agree with the localization concerns, so... any objection to this being closed as an on-hold consensus to implement Echo once it has better multilingual support? — PinkAmpers&^{(Je vous invite à me parler)} 12:46, 5 June 2013 (UTC)

   Support --Ricordisamoa 12:56, 5 June 2013 (UTC)

   Support I could go for that. StevenJ81 (talk) 14:14, 5 June 2013 (UTC)

   Support. Sounds good. --Yair rand (talk) 15:52, 5 June 2013 (UTC)

   Disagree The consensus can always change and localization is not the only issue. Vogone talk 18:05, 5 June 2013 (UTC)

Cf. m:Wikiafication. πr² (t • c) 15:35, 5 June 2013 (UTC)

Indeed weird. Vogone talk 18:07, 5 June 2013 (UTC)

That's literally one of the grumpiest essays I've ever read. — PinkAmpers&^{(Je vous invite à me parler)} 18:55, 5 June 2013 (UTC)

•  Support, once localization is fixed. -- Ypnypn (talk) 15:46, 5 June 2013 (UTC)
•  Comment – I just completed the Danish translation of the Echo extension at translatewiki.net because of this discussion. Normally I will not translate an extension unless that it is used on a wiki there Danish is the main language or on a multilingual wiki like Wikidata. If other translators do similar, you cannot expect it to be widely translated before there is a need for the translation. BTW, you can see the actual translation status here. Byrial (talk) 06:13, 6 June 2013 (UTC)

Should we make a list of languages Echo is localized in? So far there's English, Danish, Hebrew, ... what else?

Keep in mind we don't need to wait until it's localized in 250 languages; that may not happen for years. -- Ypnypn (talk) 17:44, 6 June 2013 (UTC)

No, it may not happen before the actual use gives a need to translate as I said. As for the list of languages, see the link I gave to translation status. (Currently 12 languages are 100 % done, and some more are mostly done). Byrial (talk) 21:15, 6 June 2013 (UTC)

Okay, I've been in touch with Ironholds and Fabrice about the potential logistics of this; Fabrice says that there are plans to deploy to Meta later this month, and then to some other big sites like fr.wp and de.wp after the global Visual Editor deployment in July, and that probably "we could try to take on Wikidata in the second or third phase, depending on the complexity of the issues involved for your site". Personally, I think that if the devolopers are confident they can get it localized well enough for Meta, it should be good enough for us as well. Do others agree with this? — PinkAmpers&^{(Je vous invite à me parler)} 12:54, 7 June 2013 (UTC)

I would personally like to see the localized version in action and judge for myself then. Ajraddatz (Talk) 17:07, 8 June 2013 (UTC)

Constraint issue

On GNIS Feature ID (P590), there's a single-value constraint (Template:Constraint:Single value) that I wanted to remove but has sparked discussion. Would anyone be so kind as to give their thoughts at Property talk:P590#Removed single value constraint? It'd be helpful to hear from a third party. Thanks. (Additional: This may be relevant to other properties with this constraint, such as original language of film or TV show (P364).) Mrwojo (talk) 20:52, 7 June 2013 (UTC)

Labels in other languages

Until Snow Blizzard helpfully told me to add Babel tags to my userpage, I've never been able to see or edit item labels and descriptions in languages other than English. The problem is, there are no instructions on WD to tell us that we must put Bable tags onto our userpages! My question is, surely we should put up a button somewhere (eg. next to item descriptions) telling people to add Babel tags if they want to edit descriptions in other languages?

Also, how do I add item aliases for languages other than English? I've got my Babel tag but those still don't appear. Deryck Chan (talk) 22:48, 2 June 2013 (UTC)

The only way to edit aliases is to use the labelLister gadget in your preferences. That will also give you access to languages other than those your Babel boxes allow you to edit. --Izno (talk) 01:30, 3 June 2013 (UTC)

Actually, we have a page about language issues: it is Help:Multilingual --Michgrig (talk) 08:13, 3 June 2013 (UTC)

I've filed this as bugzilla:49079. We need to make it more obvious that this box exists and how to get it. Please vote there if this is important for you. --Lydia Pintscher (WMDE) (talk) 10:25, 3 June 2013 (UTC)

Thanks Lydia. Deryck Chan (talk) 10:55, 3 June 2013 (UTC)

I've added information about it in Help:Label#Notes. A thing to do is maybe to add a "tips" section in the help main page that would highlight things like that. What do you think about it? Tpt (talk) 12:00, 3 June 2013 (UTC)

In any case, users should get in the habit of putting babel-boxen on every multilingual site they use, since it helps people find users who speak a given language. -- Ypnypn (talk) 17:56, 3 June 2013 (UTC)

This isn't obvious to me at all. Deryck Chan (talk) 22:57, 5 June 2013 (UTC)

I would tackle this problem by changing the MediaWiki:Wikibase-label-edit-placeholder message to "Enter label in $1" where "$1" would be the name of the language. Then, I would add to the MediaWiki:Wikibase-label-input-help-message an short instruction how to change the language in ULS. By doing that, they gray text in the label field would become "Enter label in English", which would tell the users that they should only enter an english label. I hope that they then go to hover the question mark next to the label field where there would be instruction of how to change the language in ULS. When they have done that, they can enter the label in the language they chose in ULS. I would skip any instructions for the babel box, as that solution only works for logged-in users. This solution should be obvious enough, and the same thing should be done with descriptions.--Snaevar (talk) 14:06, 9 June 2013 (UTC)

Pointing out potential confusion

Is there a smart way of pointing out potential confusion between two items that can easily be mistaken for one another? For instance B.G. and B.G. Knocc Out are two different American rappers and one can expect that this will lead to incorrect statements. I was thinking of changing the descriptions to "American rapper (not to be confused with B.G. Knocc Out)" and "American rapper (not to be confused with B.G.)" but that's not ideal. Does anyone have a better idea? Pichpich (talk) 15:04, 9 June 2013 (UTC)

I thought of such property, but the confusion may be language-dependent. --Ricordisamoa 15:19, 9 June 2013 (UTC)

Test Wikidata

We now have our own Test Wikidata, similar to Test Wikipedia! See test.wikidata.org to access it. --Rschen7754 09:17, 7 June 2013 (UTC)

 Like ·addshore· ^{talk to me!} 10:24, 7 June 2013 (UTC)

And also http://wikidata.beta.wmflabs.org --β₁₆ - (talk) 10:54, 7 June 2013 (UTC)

Please do not use the latter one. It is only for selenium testing. Editing there potentially interferes with that which would be very bad. It shouldn't actually be public. --Lydia Pintscher (WMDE) (talk) 11:15, 7 June 2013 (UTC)

What exactly means "selenium testing"? And what means "interferes with it"? And: Which site is more up-to-date: the selenium test or the new test.wikidata.org? Where will new code/features be implemented first? --Nightwish62 (talk) 21:15, 8 June 2013 (UTC)

I guess it refers to this. It means may an automated test raise false-alarm just because an user edited a page that a test-case doesn't expect a change on it. –ebraminio^talk 07:10, 9 June 2013 (UTC)

Selenium is a framework for automated testing. A large number of small code sequences are using this framework for testing the Wikibase system. This is an alternative to manual testing, which is very time consuming. If everything works out all is well, otherwise some part of the system are broken. There are also other test systems, to test other parts of the system like Javascript and individual classes. Jeblad (talk) 13:15, 9 June 2013 (UTC)

For early feature testing please continue to use http://wikidata-test-repo.wikimedia.de/wiki/Testwiki:Main_Page This has experimental mode enabled and will have the newest stuff that can be tested. --Lydia Pintscher (WMDE) (talk) 08:24, 10 June 2013 (UTC)

Ah, there are even three test environments? I didn't was aware of this. Maybe it would be good to have all test sites listed together with its purpose somewhere in the Help:Contents?! --Nightwish62 (talk) 21:55, 10 June 2013 (UTC)

Property

Can someone create a property <Portal topic>? It's been proposed for a week already. Ypnypn (talk) 21:56, 10 June 2013 (UTC)

It seems people are opposing it now.  Hazard-SJ  ✈  02:03, 11 June 2013 (UTC)

Sourcing dates from a database already identified...

Is this way of sourcing dates correct ? Vincent Dethier (Q7931760) or Carlo Battisti (Q3659048)

It would be a simple and efficient way to source dates, directly from AC notices… but all notices in VIAF are not yet added in wd, for ex : SELIBR or NLI (National Libr. of Israel). Would it be possible to add them ? --Hsarrazin (talk) 08:19, 7 June 2013 (UTC)

IMHO, it would be better to put stated in (P248) --> Library of Congress Control Number (Q620946) or Library of Congress (Q131454) Library of Congress Subject Headings (Q1823134). Ayack (talk) 09:16, 7 June 2013 (UTC)

Are you sure that authority records of persons are part of Library of Congress Subject Headings (Q1823134)? --Kam Solusar (talk) 19:56, 7 June 2013 (UTC)

The guidelines is under construction in Wikidata:Requests_for_comment/References_and_sources#Guidelines. So for database we have

Trusted database

1. Make sure the database is an accepted source by the Wikidata community and has an approved property to reference to its contents.
2. Source your statement with stated in stated in (P248) for the name of the database. Add the ID property to refer to a specific register of the database and as of point in time (P585) to confirm the date the information was retrieved.

Snipre (talk) 11:35, 7 June 2013 (UTC)

Ok, Snipre - there is still a pb Bibliothèque nationale de France (Q193563) is not for the Authority control file of the BNF but for the Library itsel, which is not at all the same thing - it would be necessary to create an ID for the Authority database itself, like for the LCCN (VIAF is already an database ;)) - that was why I tried to make a direct link to the Authority data … --Hsarrazin (talk) 12:32, 11 June 2013 (UTC)

IMHO authority files shouldn't be used as sources. Those records are mainly used to identify persons/works/objects and distinguish between persons/objects of the same name. But they take information like dates of birth and death from other sources, IMO most of the time without further verification. If anything, the works stated in the authority record as sources for those dates should be used, not the authority record itself. There are enough cases, where authority records even include several different dates from different sources or dates from sources like IMDb or even Wikipedia. --Kam Solusar (talk) 19:56, 7 June 2013 (UTC)

The discussion at Wikidata:Requests_for_comment/Time_DataType_Properties#Date_retrieved has identified a problem with using point in time (P585) as a qualifier for sources.

If we have a population figure for 2009 then it should have qualifier point in time (P585) '2009' but we also need a property to identify when that info was retrieved from the database.

New property "date retrieved" has been proposed as a qualifier for info sourced from databases. Filceolaire (talk) 11:58, 8 June 2013 (UTC)

There is no a problem: "as of" can be used as qualifier of the statement and as "access date" in the source section without any problem because these data are added at different levels in the database structure. And for source, if you provide a date of publication, you don't need to provide the access date. So different dates can be added but there is never possibility to have 2 dates in the same level. Snipre (talk) 17:58, 8 June 2013 (UTC)

Except that means you are using point in time (P585) with two different meanings. That would be confusing, so I don't think we should do it. Filceolaire (talk) 19:51, 8 June 2013 (UTC)

Confusing, perhaps but as you have only this property this can't be a problem. But if you add a new property for sure some people will use the wrong property. Confusion occurs when you have different possibilities, if you have only one possibility even if the sense is no the best one you will use the only property you have. Snipre (talk) 11:26, 10 June 2013 (UTC)

Details on the Geographic coordinate error

Tracked in Bugzilla
Bug 49415
Resolved fixed

It was discovered a short time ago that the Geographic coordinate datatype was converting inputs made in the decimal style system into minute/second system incorrectly. For example, the location of Massachusetts Institute of Technology is 42.35982, -71.09211 in the decimal system and 42°21′35.35″N, 71°5′31.6″W in the minute/second system, however if 42.35982, -71.09211 is entered as a value, it is converted to 42°21'35.35"N, 72°54'28.4"W, which is correct in the north value but incorrect in the west value. Until this can be fixed, it would be best not to use the already existing properties that use the Geographic coordinate datatype or create any new properties using that datatype. While there is a chance that a patch could seamlessly fix the issue, there is also a chance that the fix could be more involved and require all values using the the Geographic coordinate datatype to be reentered.

Thank you for your cooperation, Sven Manguard Wha? 22:32, 10 June 2013 (UTC)

• What projection is this in and why was DMS chosen? Just some thoughts from a person who works with geographic data all day --Guerillero | Talk 01:18, 11 June 2013 (UTC)
  • Just an update, the problem is significantly worse than initially envisioned; the issue is not one of converting from decimals to minute/second, it's one of Wikidata just doing really weird things across the board trying to handle west. This is complicated by the fact that the system wants to default to arcminute, even when it's given arcsecond level information. Further info on Bugzilla. Sven Manguard Wha? 01:27, 11 June 2013 (UTC)
    • Properties using the Geographic coordinate datatype have been temporarily deleted. The property can still be found on the test platform, though, at test.wikidata.org. Sven Manguard Wha? 02:36, 11 June 2013 (UTC)

Update: We're working on a fix. Sorry for the issues and thanks for being patient. --Lydia Pintscher (WMDE) (talk) 10:14, 11 June 2013 (UTC)

Update 2: We've deployed a fix on http://wikidata-test-repo.wikimedia.de/wiki (login is demo/test) and it'd be great if you could give this some thorough testing. There is a property using the geocoordinate datatype called location. If there are no other major issues we'll try to push an update to the live system here in a few hours. --Lydia Pintscher (WMDE) (talk) 11:09, 11 June 2013 (UTC)

Update 3: We've deployed a fix. This means bugzilla:49415 is now fixed. Additionally thanks to Tpt bugzilla:49386 is now also fixed. --Lydia Pintscher (WMDE) (talk) 16:27, 11 June 2013 (UTC)

deleted by 127.0.0.1 without deletion log?

Help:Editing/zh-hant was "deleted" by 127.0.0.1 but there is nothing in [3].--GZWDer (talk) 10:31, 11 June 2013 (UTC)

Ugh. This is bug 49066. Bad news is one of the patches to fix the bug didn't get merged to wmf6, good news is we're now on a one-week deployment schedule, so we should get the fix by the 17th, when wmf7 comes out. As for who actually deleted this page... let me do some digging and see if I can find out. Normally there's a log entry somewhere related that gives a clue. — PinkAmpers&^{(Je vous invite à me parler)} 11:27, 11 June 2013 (UTC)

Ahh. Looks like it was The Anonymouse (talk • contribs • logs). Did you have a question about the rationale for deleting it, or were you just commenting on the technical side? — PinkAmpers&^{(Je vous invite à me parler)} 11:29, 11 June 2013 (UTC)

I think GZWDer is aware about who deleted the page: Wikidata:Requests_for_deletions/Archive/2013/06/07#Useless_zh-hans_and_zh-hant_pages. --Stryn (talk) 11:34, 11 June 2013 (UTC)

Oh, okay, lol. Well, yeah, guess we just have to sit tight until that patch gets merged. — PinkAmpers&^{(Je vous invite à me parler)} 11:47, 11 June 2013 (UTC)

Heh, I saw 127.0.0.1 in the deletion log too, and I also was wondering what was going on. Thanks for the info. The Anonymouse (talk) 18:01, 11 June 2013 (UTC)

Time datatype available and short overview of next steps

Heya folks :)

We just enabled the time datatype \o/ This means it is now possible to create properties that can be used to indicate when something happened. A lot of time-related properties are already proposed and should be created soon. It'll then for example be possible to indicate that Curiosity was sent on its way to Mars on November 26, 2011. It'll of course also be possible to use this as a qualifier to indicate when a certain statement was valid for example. As usual please let me know about any issues you're seeing after this update.

As many of you have asked me what comes next here's a quick overview: We'll be working on more datatypes. Geocoordinate, number, url, monolingual text, multilingual text and numbers with units are left. Geocoordinate is being worked on right now. Then ordering of statements is planned and then ranks (to indicate that a statement is deprecated or preferred). In parallel to all this queries (phase 3 basically) are being worked on.

Cheers --Lydia Pintscher (WMDE) (talk) 19:09, 29 May 2013 (UTC)

Curiosity is an impressing Example, Lydia - no dates ... --Succu (talk) 19:33, 29 May 2013 (UTC)

Good news! I've created date of birth and date of death. Here is a real example: Jean-François Champollion. Tpt (talk) 19:37, 29 May 2013 (UTC)

Thanks Tpt, I already had a try at Q528064 and found that it was possible to input the dates as in commons "YYYY-MM-DD" - but I really find the output format very disturbing… (mars 29, 1825^Gregorian)

Do you think it be possible to "localize" it (i.e. display it according to the language or preference of the user) ? --Hsarrazin (talk) 20:12, 29 May 2013 (UTC)

I agree that this should be done. For example, you would be able to choose between "December 25, 2012" and "25 December 2012". Del_♉sion23 (talk) 21:07, 29 May 2013 (UTC)

Please follow bugzilla:48962 for that. --Lydia Pintscher (WMDE) (talk) 10:00, 30 May 2013 (UTC)

I know that no dates are in there yet ;-) It was a possible example. Someone with property creator rights needs to create the necessary property first of course. --Lydia Pintscher (WMDE) (talk) 19:39, 29 May 2013 (UTC)

Are geographic shapefiles such as KML still planned? --Rschen7754 19:45, 29 May 2013 (UTC)

They are not off the table but the current state is: let's see how the above list develops/is used once done and then see if and how we do geographic shapefiles. --Lydia Pintscher (WMDE) (talk) 19:51, 29 May 2013 (UTC)

Is it possible to just add "year of birth" instead of "date of birth"? Loads of articles on Swedish Wikipedia are categorized by year of birth. If that is a possible option, our friends, the bots, could add loads of birth years. --abbedabb^talk 20:01, 29 May 2013 (UTC)

The time datatype support date with a precision between the second and the gigayear. So, you can add "date of birth" with as value a date that has only a precision of a year, it'll works fine. But, I think that bots should take care before of Persondata templates of the English and German Wikipedia that contains full dates of birth and death of a lot of people. Tpt (talk) 20:09, 29 May 2013 (UTC)

Hi Lydia! Are there any plans for "complex strings" that can support the full range of mathematical and chemical type setting? Would be nice if something like MathML could be entered into such a datatype and Wikidata would display the correct formatting. --Tobias1984 (talk) 20:20, 29 May 2013 (UTC)

In the future those should be possible, yes. It's not high on the priority list right now though. If someone wants to work on it please let me know. --Lydia Pintscher (WMDE) (talk) 10:03, 30 May 2013 (UTC)

My bot is almost ready to import date of birth (P569) and date of death (P570): is the relevant API already available and working? --Ricordisamoa 20:26, 29 May 2013 (UTC)

Based on... --Succu (talk)

I'm not sure I'm comfortable with this. In fact, I'm pretty sure I'm against importing data that needs to be sourced when we have no mechanism in place to handle references appropriately. It's one thing to import statements that convey data which isn't referenced because no one in their right mind would contest it ("London Calling" is an album, "London Calling is an album by The Clash", "The Clash is a rock band", "Joe Strummer is a member of The Clash", "Joe Strummer is a man"). In principle, the date of birth of a person shouldn't be included in a Wikipedia article without a proper reference although in practice this is unfortunately not always the case. Importing blindly these bits of data is just wrong and basically turns Wikidata into a free-for-all-who-needs-references mess. This bot shouldn't be authorized. Pichpich (talk) 21:55, 29 May 2013 (UTC)

Nontrival facts from Wikipedia should only be imported, referenced with at least one reliable source. Conny (talk) 08:51, 30 May 2013 (UTC).

More data types than those listed can be planned afterwards. Shapefiles, Chemical formulas, colors -- all kind of things. We should probably be moving towards a process of suggestions and prioritizing their implementation. But the list is definitively not a closed list -- merely what we currently plan. --Denny (talk) 20:33, 29 May 2013 (UTC)

Great! But I would like to plead for giving more priority to the URL-Datatype, because this is needed for Sources. It also seems to be an easy one, compared to Geocoordinate, multilingual text and numbers with units. -- MichaelSchoenitzer (talk) 20:36, 29 May 2013 (UTC)

Agree we have to provide possibility for sourcing before any large data import. Snipre (talk) 21:34, 29 May 2013 (UTC)

Also for me it is better to wait URL datatype. --Paperoastro (talk) 22:12, 29 May 2013 (UTC)

I've brought this up and will let you know as soon as I have an answer. Denny is currently traveling so I don't know when that'll be unfortunately. --Lydia Pintscher (WMDE) (talk) 11:21, 3 June 2013 (UTC)

I've created Property:P576 for the date of dissolution of an organisation. There should probably be one for the date of foundation too. Del_♉sion23 (talk) 21:23, 29 May 2013 (UTC)

Carl Sagan (Q410) now has date of birth (P569) and date of death (P570). But please stop creating all those properties, it's better to wait for comments. IMHO inception (P571) and time of discovery or invention (P575) overlap each other. --Ricordisamoa 22:39, 29 May 2013 (UTC)

You are right, but time pending property is already void! The problem is that the creation of most of these properties was discussed months ago and so people assume that they can be created! --Paperoastro (talk) 22:46, 29 May 2013 (UTC)

Well, if I write about opening of railway station, what date should I use: discovery date or creation date?--Ahonc (talk) 17:59, 30 May 2013 (UTC)

As for now, the WD:Property proposal/Pending#Awaiting TimeValue datatype section is empty. However, there are 3 proposed properties of TimeValue datatype in WD:Property proposal/Generic#Qualifiers section (from, to, as of) with enough comments and enough support to already be created. Can somebody with property creation rights take care of them? --Shlomo (talk) 07:55, 30 May 2013 (UTC)

Lydia, any example of the time datatype in action for qualifiers? --DarTar (talk) 22:43, 29 May 2013 (UTC)

I've not seen one yet. Anyone else? --Lydia Pintscher (WMDE) (talk) 10:07, 30 May 2013 (UTC)

I added some qualifiers for George Washington Q23 (see his "office held" statements. Kudos to you, Lydia! Nicely done! DavidJHowe (talk) 14:06, 1 June 2013 (UTC)

Also, when will this be available for inclusion in WP articles? --Ricordisamoa 22:44, 29 May 2013 (UTC)

Inclusion via Lua should work already. For the parser function please follow bugzilla:48937. --Lydia Pintscher (WMDE) (talk) 10:07, 30 May 2013 (UTC)

Is inception (P571) usable for items about cities? I feel like "date established" would be better wording, but I suppose if this property works, that can just be added as an alias. TCN7JM 06:17, 30 May 2013 (UTC)

start time (P580), end time (P582), and point in time (P585) were created.--Saehrimnir (talk) 12:59, 30 May 2013 (UTC)

If you enter "4 January", it is understood as January in the year 4. Should this be considered a bug? -- Ypnypn (talk) 15:18, 30 May 2013 (UTC)

Not in the Way the Datatyp works right now by requiring at least a year and getting more precise from there.--Saehrimnir (talk) 15:43, 30 May 2013 (UTC)

So en example for the datatyp as qualifier is now Margaret Thatcher (Q7416) when will it be possible to define actual times down to the second?--Saehrimnir (talk) 16:20, 30 May 2013 (UTC)

I don't have a due date for that yet unfortunately but it's on the todo list. --Lydia Pintscher (WMDE) (talk) 11:40, 31 May 2013 (UTC)

Excellent, thanks: I used it here. Two more questions:

• how would I represent an item having the same property in two distinct time intervals? Giorgio Napolitano was President of Italy for two consecutive mandates, how should I represent this? Would that be the same property with two sets of start_date/end_date qualifiers or two distinct President of Italy properties, each with its own date range qualifier?
• how do I represent "to date"? Is an open interval with only a start_date be implicitly interpreted as "the item still has that property to date"?

Thanks --DarTar (talk) 21:38, 30 May 2013 (UTC)

For the first: Probably the second option. For the sescond: That depends on the properties that are being agreed on here. --Lydia Pintscher (WMDE) (talk) 11:40, 31 May 2013 (UTC)

Datetype poperties do not work for me in uk.wikipedia. I added here properties P569 and P570 (for Taras Shevchenko (Q134958)) but in infobox nothing shows instead of dates.--Ahonc (talk) 17:59, 30 May 2013 (UTC)

It does not seem to work on en.wikipedia and nl.wikipedia. Is is supposed to work on the clients? HenkvD (talk) 18:39, 30 May 2013 (UTC)

Please see bugzilla:48937 for progress on that. --Lydia Pintscher (WMDE) (talk) 11:40, 31 May 2013 (UTC)

The superscripts aren't localized (at least in Hebrew). Will they be? -- Ypnypn (talk) 18:16, 30 May 2013 (UTC)

I'll need to ask where the issue is exactly. Thanks for bringing it up. --Lydia Pintscher (WMDE) (talk) 11:40, 31 May 2013 (UTC)

It's currently hard-coded and not translatable. I filed bugzilla:49080 to have this fixed. --Lydia Pintscher (WMDE) (talk) 11:27, 3 June 2013 (UTC)

Could we get the url datatype moved up ahead of the geo coordinates please? Filceolaire (talk) 17:50, 31 May 2013 (UTC)

I've brought it up and will let you know when I hear something about this. --Lydia Pintscher (WMDE) (talk) 11:24, 3 June 2013 (UTC)

As promised some update on the URL datatype: Geocoordinates is basically pretty much done in a first version and should be deployed next week already. URLs will be worked on in the next sprints - however it is a bit more complicated than it looks from the outside because we really need to check the input for this datatype and that requires some ugly work in the background code still. We do realize however that it is important to have it. So in essence: Hopefully soon but unfortunately not in the next days. --Lydia Pintscher (WMDE) (talk) 10:25, 7 June 2013 (UTC)

Will URLs be set up to work with the abusefilter properly? I'd just prefer not to open the door up to tons of linkspam --Rschen7754 10:39, 7 June 2013 (UTC)

I've just filed bugzilla:49306 so we keep this in mind. --Lydia Pintscher (WMDE) (talk) 13:00, 7 June 2013 (UTC)

It's really nice to have a date type with variable precision and support for Gregorian and Julian calendars. How should we represent dates before the Julian era? For example Julius Caesar (Q1048) was obviously born before his own calendar reform. I listed his birth date as July 100 BCE (Julian) but that looks odd. According to en:Roman calendar#Converting pre-Julian dates, even his death date is possibly one day off compared to the modern interpretation of the Julian calendar. Quoting that page about the Roman calendar, "Finding the exact Julian equivalent of a pre-Julian date is complex." — experts wanted! My hunch would be to eventually support ancient calendars of various cultures to express dates in their contemporary form. — JFG ^talk 03:17, 12 June 2013 (UTC)

The way you've done it looks fine to me for now. More calendar models can be added. Anyone who wants to work on that please get in touch with me. --Lydia Pintscher (WMDE) (talk) 09:31, 12 June 2013 (UTC)

Redlinks in Wikipedias

I have no idea if this is the right place for such a proposal, or if this has already been proposed a million times - but I have a proposal for what Wikidata could be able to do. That will require code changes however.

In smaller Wikipedias, there are often a lot of red links leading to articles which do exist in other, bigger Wikipedias. A reader might be able to understand these articles in some other language, so it could be useful to have a link to Wikidata beside the red link.

I could imagine this being implemented e.g. by allowing nonexistent articles to be added to Wikidata entries. That way, if a reader clicks on a red link which is linked to a Wikidata entry, they could see a message "this article does not exist yet in our language, but it does exist in the following languages". Obviously these nonexistent links shouldn't be displayed normally on Wikidata pages, just in a special (possibly hidden) section. That would also help those who create redlinks determine which title other people used for the same item.

Another way could be a special wiki syntax, such as: [[d:Q6091479|A2 bridge over Ebro|the bridge over Ebro]] - this could show up as the bridge over Ebro^{other languages}. Or even listing the languages the page exists in instead of just "other languages". On eo.wikipedia, some months ago (pre-Wikidata) we had a dispute if we want to link to en.wikipedia where the article doesn't exist in Esperanto yet; this could be a solution that wouldn't favor English over other languages.

Any opinions? Any ideas for a better place to propose this? Of course this could also be implemented through a template on local Wikipedias, but this seems like a cleaner proposal. darkweasel94 (talk) 08:38, 11 June 2013 (UTC)

Huh. Sounds like a good idea to me... perhaps on an opt-in basis for the individual wikis. Of course, this would probably require an RFC, and then go into the category of RFC consensus that require major technical changes that will take forever to implement... but I like the idea nonetheless. For the time being, though, you can always create a template that goes [[{{{1}}}|{{{2}}}]]{{#if:{{{id|}}}|<sup>[[d:q{{{id|}}}|[other languages]]]</sup>}}. That doesn't solve the problem of letting people creating articles automatically know that the article exists in other languages, but it addresses your final point. — PinkAmpers&^{(Je vous invite à me parler)} 11:41, 11 June 2013 (UTC)

Good that somebody agrees, and thanks for the implementation idea (though I haven't even discussed it yet on eowiki, so I don't know what people think there). Are you more familiar than me with the processes needed to bring this to the attention of the wider community, and then possibly the developers? Is this best done on Wikidata or on Meta? darkweasel94 (talk) 17:32, 11 June 2013 (UTC)

This sounds like a matter for individual wikipedias to me. If you can get one wikipedia interested then it could pioneer this then publicise it on Meta and maybe others will follow. Filceolaire (talk) 20:03, 11 June 2013 (UTC)

Need of a general concept for properties

There are different issues concerning the property creation and this need a clear decision of the community.:

• Inheritance. Does an item defined as an "instance of" or a "subclass of" of another item inherit some characteristics of the above element ? Example: If Florida is defined to be in US and Miami is defined as a city in Florida, do we need to say that Miami is in US ?
• Bottom-up or top down. Do we need to list all states in the item of United States of America (Q30) ? Or mentioning in each state item the membership to United States of America (Q30) is enough ? Snipre (talk) 01:48, 7 June 2013 (UTC)

If it is just a matter for a community decision then I would !vote for

• Inheritance - information to be provided on the state level is available at the city level by following the properties to the state level. Duplicated info is minimised.
• Bottom-up as there are nearly always more low level items than high-level ones and this keeps down the number of statements and makes the items easier to manage.

Having said that I would like a statement from the developers on what they think about this. Filceolaire (talk) 05:31, 7 June 2013 (UTC)

 Support I agree with Filceolaire - inheritance seems simpler, and would greatly reduce the number of properties to insert in each item, and bottom-up seems also the simpler - the list of all cities in each country would be really long and unreadable - while adding the country and the instance of on each city would make it easy to list by request… :) --Hsarrazin (talk) 08:43, 7 June 2013 (UTC)

 Support The entity suggester might be something similar to instantiation, since it will suggest the properties most used for that kind of items. For the bottom-up I would put a reasonable limit, say that if there are more than 5 sub-items, then do only bottom-up. Ideally there should be a section to show how many items of a certain kind are linking to the item. For the "actor" item, it would be "XXXX instances of actor", for the US "50 parts of US", and so on.--Micru (talk) 11:47, 7 June 2013 (UTC)

 Support for both Inheritance and Bottom-up.--Saehrimnir (talk) 18:04, 7 June 2013 (UTC)

 Support I asked similar question here.--Ahonc (talk) 13:42, 8 June 2013 (UTC)

 Support Bottom up makes more sense. It would probably see the demise of properties such as Property:P150. Del_♉sion23 (talk) 14:30, 8 June 2013 (UTC)

 Support —★PοωερZ_talk 14:37, 8 June 2013 (UTC)

 Comment - Both suggestions can reduce the number of statements for the current state. But think about historic changes. Single cities can switch countries many times during war. If the country is inherited from the state then we would loose vital data resolution. If a whole state switches sides during a war, it would be a good thing if we could inherit that information for all the cities. Maybe this will need a whole new interface function that can say "statement A is valid for all items that are a subclass of this item" or "statement B is only valid for this item and should be excluded from bottom-up inheritance". --Tobias1984 (talk) 16:36, 8 June 2013 (UTC)

If a country changed sides in a war, couldn't we just use a time value to indicate what the allegiance was during a certain time interval? Del_♉sion23 (talk) 17:23, 8 June 2013 (UTC)

Single cities don't change sides in a war. They are occupied but are still part of the country they started in until the peace treaty recognises their change of status (if any). This is why Jerusalem is usually classified as a city in Israeli occupied Palestine and not recognised as a city in Israel. The change in status, when it happens can then be shown by start/end date qualifiers to the statements.

Far more common than a change of status due to a war is a change due to local government reorganisation. Date qualifiers can deal with these as well. Filceolaire (talk) 20:38, 8 June 2013 (UTC)

All I'm trying to say is that inheritance of properties is not that simple and does not always begin at the same level of detail. --Tobias1984 (talk) 20:43, 8 June 2013 (UTC)

• The fundamental principles by which Wikidata operates? Like Wikipedia:Five pillars? 1 pillar: basis - Set theory? Fractaler (talk) 10:08, 9 June 2013 (UTC)

• I think the basis for Wikidata's approach to structured data should be relevant W3C recommendations for the Semantic Web, like RDF, RDFS and OWL. In notable ways, Wikidata is already based on those recommendations:

• the developers have committed to exporting data in RDF,
• the item-property-value triplets that constitute claims are clearly derived from RDF subject-predicate-object triplets,
• instance of (P31) and subclass of (P279) are based on core properties from RDF and RDFS.

In turn, RDF, RDFS and OWL are based on description logics, which incorporate many components of set theory. Emw (talk) 01:51, 13 June 2013 (UTC)

• I don't know if this is duable, but what about some kind of reciprocical transclusion? That is, whenever we put a relationship between two items, the second item would automatically receive the complementary statement: in adding Alabama to the United Stated, the item Alabama gain a statement country:US. While the bottom-up way makes more sense, top-down may be easier to manage. For instance, I'm currently working to set up all the demes of ancient Athens per phyle: I have a clearer view of what I've done and what remain to be done when I work in a top-down view. Alexander Doria (talk) 12:08, 9 June 2013 (UTC)

IMO, the functionality of "What links here?" needs to be much expanded and improved for Wikidata. Top-down properties should be displayed in the "child item", and bottom-up properties should be displayed in the "parent item". Today you can use "What links here" for that, but the data is not organized in any way, or displayed in any meaningful manner. You'll have to open all "What links here?" links in order to see what they actually say about the item in question. What we need is the data from "What links here?" on display in the item itself, with info about sorted by what properties they are linked via, qualifiers, sources, etc. - Soulkeeper (talk) 15:49, 10 June 2013 (UTC)

Yes I'm definitely agreeing. While it's stupid to do twice the same thing, we should defenitely keep tracks of the relationship in both ways. Bots might not care, but human does… Alexander Doria (talk) 22:35, 10 June 2013 (UTC)

• I think we should discuss the creation of Wikidata:Properties and Help:Properties (both links to Wikidata:List of properties, therefore blue). One to define foundational rules of how our property system should work, the other as a guide for the use of properties in general and a bit of information about the most basic properties, e.g. instance of (P31), subclass of (P279), etc. —★PοωερZ_talk 16:27, 10 June 2013 (UTC)
• I have asked for a clarification about the property model. In my opinion it would be a great addition if it could be configured per property, some of them will work better as bottom-up, others as top-down, and most might not need it.--Micru (talk) 03:08, 12 June 2013 (UTC)

Comment from the dev team: There is no inheritance built into the system (at least for the foreseeable future). If you want this bots will have to do it for specific cases since inheritance quickly gets to the point where it becomes tricky to do automagically. About top-down vs bottom-up: Both is fine really. The only thing you need to keep in mind as far as I can tell is that it is currently not possible in a Wikipedia article to access data from an item that is not the one connected with the article. That might have some influence on where you want to put certain data. --Lydia Pintscher (WMDE) (talk) 12:46, 12 June 2013 (UTC)

In the future, will be possible in a Wikipedia article to access data from an item that is not the one connected with the article? It's a feature in planning? --β₁₆ - (talk) 15:42, 12 June 2013 (UTC)

It is a planned feature (bugzilla:47930) but I can't tell how soon it'll be possible. Figuring out how to update all pages that use certain data that was just changed on Wikidata without killing the servers is one of the challenges there. --Lydia Pintscher (WMDE) (talk) 16:42, 12 June 2013 (UTC)

Would it be possible to allow access to items directly connected to the main article item? That would mean a more reduced set of items to worry about.--Micru (talk) 18:30, 12 June 2013 (UTC)

And regarding "About top-down vs bottom-up: Both is fine really.", what does that "is fine" means? Can we consider it as a feature on the to-do list that could be available soon? :) --Micru (talk) 23:04, 12 June 2013 (UTC)

I think we should explore a few questions:

• Are there mechanisms for specifying inheritance available from relevant W3C recommendations like OWL? Which?
• Do other large ontologies handle property inheritance? How?

Inheritance seems like it would be a solved problem for larger, more mature ontology implementations. We actively avoid reinventing the wheel wherever possible, and look for solutions that make Wikidata interoperable with the rest of the Semantic Web. Emw (talk) 01:38, 13 June 2013 (UTC)

adding descriptions in statements

(Re-posted request) For human contributors it would be extremely helpful to see the descriptions when viewing statements of an item. Currently, a reader looking at the item Afterplay can't tell if the statement "author is Brian Kelly" makes sense because there's no way to tell which of the twelve items named Brian Kelly the statement is pointing to. Pichpich (talk) 20:28, 10 June 2013 (UTC)

In my opinion, the description should be shown in the title text. --Yair rand (talk) 20:38, 10 June 2013 (UTC)

 Support --Tobias1984 (talk) 09:41, 11 June 2013 (UTC)

Hi guys, I've created User:Bene*/descriptions.js. Write the following line into your common.js:

importScript( 'User:Bene*/descriptions.js' ); // [[User:Bene*/descriptions.js]]

If you like it, we can also make it a gadget. Regards, -- Bene* ^t_a^l_k 21:42, 11 June 2013 (UTC)

 Support - thank you for creating this and please make it a gadget :) --Tobias1984 (talk) 09:20, 12 June 2013 (UTC)

 Support Thanks for doing this, super useful!--Micru (talk) 18:53, 12 June 2013 (UTC)

 Support super! Holger1959 (talk) 19:57, 12 June 2013 (UTC)

 Support yeah! Not only do I think it should be a gadget, I think it should be on by default. I'm convinced that this makes life easier for newbies. Pichpich (talk) 06:10, 13 June 2013 (UTC)

 Support for default. --Saehrimnir (talk) 14:43, 20 June 2013 (UTC)

Proposal for phase 4: unify and centralize categories

Hi, I've been contributing to the Spanish Wikipedia for some years, and a great deal has been on categorization. I believe that Wikidata can solve many of the problems that plague the categorization system in Wikipedia and other Wikimedia projects, so I'd like to propose that the phase 4 of Wikidata focuses on just that. Here I'd like to give some of the main reasons why I think this is a good idea, but without entering into technical details. If I find support, I will create a page in Wikidata to discuss this further. I will focus on Wikipedia, but much of what I say can be applied to other projects too.

One of the oldest and most annoying problems with categories is that if one wants to change the name of a category, one has to create a new category with the right name, then go one by one to all the articles, remove the old category and add the new one. This is because articles are categorized from within the articles themselves, and not from within the category pages. When there are too many articles in one category, of course, a bot must be recruited to do the job, and in some Wikipedias there is even a category of categories waiting to be renamed. So this is a big maintenance issue. If articles were categorized from Wikidata, renaming or deleting a category would be as easy as it should be.

A second reason for moving categories into Wikidata, is that it could allow all Wikipedias in all languages to share one centralized, unified category system. Nowadays, different Wikipedias differ on their ways of categorizing articles. However, hardly any of these differences are language related. Rather, they are the result of having evolved independently. If there were one centralized, unified category system, we could join the efforts of all the categorizers in all the languages, and also save enormous amounts of work. For example, right now, I'm possibly the only person who every now and then corrects and improves the categories of Philosophy and Logic in the Spanish Wikipedia. But there are 200 others who do the same thing in 200 other languages. Centralizing and unifying the category system would allow us to collaborate, save work, and would lead to a more active and thus more healthy discussion on the best way to categorize articles.

A third reason for centralizing and unifying the category system is that it would prevent the usually poor categorization of new articles. Suppose someone creates a small article in the Spanish Wikipedia about some technical topic in logic, and loosely categorizes it into the very general category of Logic (this happens very often, and to every main category). Then it falls into people like me to categorize it into more precise subcategories. However, new articles usually have an equivalent version in other Wikipedias, where they are already better categorized. If categories were centralized and unified in Wikidata, new articles could be automatically categorized based on the central category system, thus avoiding loose and sometimes plain wrong categorizations. I would also help to greatly reduce the category of uncategorized articles in all languages.

These are the three main reasons I can think of for wanting to centralize and unify the category system through Wikidata. As to the technical aspects of such a feat, I have a few ideas, but it only makes sense to start discussing that if the community agrees on the proposal. So thanks for reading, and please let me know your thoughts on this! --Luis Felipe Schenone (talk) 16:07, 2 June 2013 (UTC)

•  Support - Centralized categories would be practical. --Tobias1984 (talk) 16:39, 2 June 2013 (UTC)
• Alternative suggestion: get rid of categories. I just cannot imagine what they can do that cannot be better done through Wikidata and automatically compiled lists. --Zolo (talk) 16:51, 2 June 2013 (UTC)

  True, categories are just a relationship beetween an article in a language and a category, without specifying the meaning of this relationship, and wikidata can do that. Although there is a mismatch beetween items and article, so if we want to refer to an article in a specific language, we will have to do something like qualifying those relationship. Plus categories can play the role of maintenance categories, role which does not seem to be at this moment something that the community seems to accept : wikidata as a pure technical tool. TomT0m (talk) 17:06, 2 June 2013 (UTC)

  If someone wants to take up bugzilla:40810, it "needs volunteer" , I guess it would greatly help with using Wikidata as an alternative to maintenance categories. --Zolo (talk) 21:26, 2 June 2013 (UTC)

• Luis, I think there is broad agreement that Wikidata can offer a solution to categorization issues. As Zolo suggests, I think the solution to maintenance problems with categories might not be centralizing them on Wikidata, but rather replacing them with something more novel. Categories are essentially queries on a set of pre-defined properties. The manual maintenance that has been required to curate Wikipedia's category system seems like it could be largely eliminated once Wikidata queries are deployed. Emw (talk) 18:53, 2 June 2013 (UTC)

  I'd get rid of categories, myself—at least non-administrative ones. One very big problem with categories is that they represent a piece of Wikipedia that isn't always easily prone to consensus- and reliable-source-driven conclusion.

  Take, for example, the perennially controversial topic of Jerusalem. (NOTE: Please do not start substantive discussion on that topic here. I'm just illustrating!) Someone categorizes it as a "City in Israel". Or a "World Capital City". Then you start fights: is it? isn't it? says who? and so forth. Sometimes, such disagreements and discussions are necessary and appropriate on Wikipedia. But sometimes, they don't really add anything.

  Getting rid of (substantive) categories would, in my view, eliminate a big source of conflict that does very little in pushing the overall project (or series of projects) forward. StevenJ81 (talk) 19:05, 2 June 2013 (UTC)

• First of all, while your proposal is quite interesting, the next phase of the highest priority that I see is including sister Wikimedia sites to Wikidata: Commons, Wikisource, Wiktionary! Infovarius (talk) 19:44, 2 June 2013 (UTC)

  Phase 3 is to be the development of queries which should be able to produce lists similar to categories except much more flexible. If you can query any property or selection of properties (including properties such as which wikipedia) with AND and OR as options then this should be an effective replacement for the categories and all done in phase 3! Filceolaire (talk) 21:26, 2 June 2013 (UTC)

  I agree now that it would be better to completely replace categories with queries. I'm thinking that the "See also" sections would be appropriate places for the community to put related queries, but that would be a thing for the community to decide, when the time comes. --Luis Felipe Schenone (talk) 09:22, 5 June 2013 (UTC)

• There are various terrible ideas here. A relatively small number of basic categories might be agreed, but not all. How many does en have compared to any mid-size wp (one answer is certainly - too many)? Does en have to lose all the extra one, or does somebody have to translate into say Arabic all the thousands of categories they will never need. Queries are fine for the data you have set up on Wikidata (if it is correctly assembled from the article, and correct in the first place), but they are many categories it will not cover, and few of our readers will really be interested enough to get a query going, or know how to. Johnbod (talk) 03:31, 6 June 2013 (UTC)

• Maybe you are misunderstanding. As I currently understand it, categories will be changed in this way: Instead of having to put the category link on each page you will just create a category page and type in the query. Also, simple searches could generate lists and categories without the reader needing any programming knowledge. Searches returning dynamic content are appearing all over the web (e.g. http://www.wolframalpha.com/input/?i=population+in+mexico+city). --Tobias1984 (talk) 06:13, 6 June 2013 (UTC)

"Categories" compiled from query searches of text will be useless; categories complied from metadata will be inadequate for the foreseeable future as the metadata will only cover a few of the categories many articles have. Johnbod (talk) 17:26, 6 June 2013 (UTC)

I don't know John. I can foresee quite a lot of stuff. For instance, I can foresee metadata covering all the category information and allowing us to use queries to create arbitrary 'cross-category' categories instead of the fixed ones we have now. With a form to create new queries (automatically populated from the infobox properties) the queries don't need to be 'agreed' in advance. Each reader can create their own as they need it and discard it as quickly. It might take years but the existing category system can run in parallel in the meantime. Filceolaire (talk) 06:11, 7 June 2013 (UTC)

• I agree with Filceolaire, a database of properties will be the best. I'm glad we discuss to change this obsolete categorization system. --Hiperfelix (talk) 15:30, 9 June 2013 (UTC)

• Maybe my brains have turned too much into bone, but now it desired to me to say  Oppose. Categories have their troubles, lots of them, but they can be made manually by ways uneasy to automate. Well, "Personalii by alphabet" are would be nice to get rid of, but what one will do with "Landmarks of Moscow" or, a case really out of any controversy, "Moscow"? If one will think about replacing categories with WD, first what is to be thought is what will replace their free inclusion structure. Another question: now categories can be added by just putting a template. For iwiki such mechanism was uncommon, but there are still moaning about that it's too far to go to another site for dealing with them instead of typing them in the same window you are entering the text. For categories, adding by templates are common; each article decides itself to what to belong. Thus, we'll need bots fiercely working to take information from templates and put it into db. And the last question is project chauvenism. Each lang-project has its own history and ways of organizing information, and it doesn't want suddenly to get into alien stuctures. Categories en:Category:LGBT musicians from Russia and en:Category:Jewish scientists don't have Russian iwiki, and by consensus mustn't. Of course WD is to be filled by non-controversal content, but I pretend a roar which will rise over my home project if one offers to centralize category system. Ignatus (talk) 08:54, 13 June 2013 (UTC)

Properties for sourcing statements

In the "brief guidelines for sourcing statements", discussed here recently, there were a number of proposed properties. Could these be created now please?

• edition
• edition of

These properties are needed for editions of books.

• date retrieved

This property is needed for web sites and online databases.

That leaves just the 'web site' property still to be created. This is waiting for the URL datatype. Filceolaire (talk) 22:19, 9 June 2013 (UTC)

Before creation we need more comments because these two properties are not going in the direction of the different discussions following the proposals: no specific property similar to instance of or subclass of, and use the bottom-up concept for data structure: no link from the genaral item to the specific items, only mention of the general item in the specific tems. I just want to avoid a fast creation followed by a long discussion in the property deletion request two days after the creation. Snipre (talk) 11:37, 10 June 2013 (UTC)

My reading of Wikidata:Requests for comment/How to classify items: lots of specific type properties or a few generic ones? is that there is no consensus for a few generic properties. In fact I believe the balance of comments is in favour of lots of specific type properties.

If having specific properties similar to 'instance of' and 'subclass of' makes queries more dificuly then that is a problem to address in phase 3 by, for instance, introducing a new 'subproperty' so properties similar to 'instance of' (for example) can be identified as such and included in 'subclass of' queries. Filceolaire (talk) 18:10, 10 June 2013 (UTC)

Your impression is the inverse of the experience made about property in wikidata: I just cite the examples of the administrative divisions which started at the begining with some specific properties before an important merge into a small properties set. Snipre (talk) 22:52, 10 June 2013 (UTC)

Again for me is important to have an unique way to create property, few and general or a lot and specific, but first we have to select one. The main decision is in my opinion depending if we will go in the direction of semantic or not. If yes, we need to select the system with few and general properties according to the W3C standards;. Snipre (talk) 22:53, 10 June 2013 (UTC)

I think I was the person that first proposed 'is in administrative unit' and 'type of administrative unit' as properties. I proposed them because it got round the problem of trying to define first/second/third level units. There doesn't seem to be any support for replacing these properties with 'part of' and 'instance of', even though they are pretty much synonyms. We have got properties which are specific enough to do the job but no more specific than that.

Similarly I believe the properties above are those needed to do the job and I believe this is what was agreed in the references discussion. Filceolaire (talk) 07:17, 11 June 2013 (UTC)

From what I see in the property deletion requests is that we need to clarify the general guidelines for property before going to the creation step or at least to have a large consensus beyond the usual property users. Going to fast is a very bad thing: once the property is created there will be a deletion request which will take days and nobody will know if we can use the property or not and this is a big problem for a property which will propose in a main guideline of wikidata. Snipre (talk) 11:50, 11 June 2013 (UTC)

And I, having been the one pushing for the properties to be created, now see a problem with 'edition'.

On the one hand the book references discussion is proposing to use this on book pages to list editions of the book which don't have their own page - i.e. with string or monolingual text datatype.

On the other hand the same discussion is proposing to use this on book pages to link to editions with their own wikidata pages - i.e. with item datatype.

The solution that occurs to me is that this property should take 'string' datatype. The proposed 'edition of' property should be used to link back from edition pages and the 'edition' property could have a 'dedicated page' property to link to items for editions, if necessary. OK?

Now I'm going to amend the 'edition ' property proposal to change the datatype to string. Filceolaire (talk) 20:24, 11 June 2013 (UTC)

"the book references discussion is proposing to use this on book pages to list editions". Could you please link the conversation? I couldn't find it anywhere... I hope that you are not referring to the experimental option "with qualifiers"... that one was dismissed because it doesn't allow to point to a specific edition.--Micru (talk) 03:20, 12 June 2013 (UTC)

The discusssion is at Wikidata:Requests for comment/References and sources. The consensus there is that editions of a book which are referred to in sources should have their own wikidata pages but editions which are not referred to in sources should not have their own wikidata pages (unless they have their own wikipedia page) and should be described by a statement in the WD: page for the book. Filceolaire (talk) 05:09, 12 June 2013 (UTC)

The consensus was to create items that are needed. If you need an item to represent an edition used to source an statement, create it, and for extension also for infoboxes (it will be needed so each language wikipedia can represent their preferred edition).

What I don't understand is why do you want to have 2 different models? And why do you think edition data should be allowed if it is not going to be used?--Micru (talk) 15:47, 12 June 2013 (UTC)

Why would we ban edition data from being added to the main page for a book? Filceolaire (talk) 16:52, 12 June 2013 (UTC)

There is no need to ban, but to keep data usable by infoboxes it is easier to have only one model... as soon as they can fetch data from 2 separate items.--Micru (talk) 18:09, 12 June 2013 (UTC)

I've just noticed we have already got edition number (P393) with string datatype which can be used for editions without items, if necessary, so I've switched back to supporting 'Edition" with item datatype. as Micru's comment above.

I think these three properties now have consensus to be created. Filceolaire (talk) 08:13, 13 June 2013 (UTC)

UnconnectedPages and touch.py

There is a client side special page (examples w:en:Special:UnconnectedPages [not fixed], w:no:Special:UnconnectedPages [fixed]) that lists all pages without correct setup of the article-item relation. This page also lists a lot of spurious pages due to how the relation was created earlier. To fix this bot operators can run the script touch.py (part of pywikipediabot) for all pages at the project. It should be noted that only one bot should be used for this as it will trigger a rerendring of the page, which is a slightly heavy operation and when a lot of pages are rerendered it creates a fairly big load on the client servers. So please do run touch.py, but only one per project. After this is done only the unconnected pages should remain in the list. Most of them will be without langlinks, but some will have weird colliding langlinks. Jeblad (talk) 11:40, 4 June 2013 (UTC)

It works! --Ricordisamoa 13:44, 4 June 2013 (UTC)

Jeblad, did you only implement the special page and not the corrosponding api part? If the api part is implemented it's just another api call and you don't have to rerender all the pages on a Wikipedia..... bug Multichill (talk) 15:50, 4 June 2013 (UTC)

Ok, just did some queries (SELECT COUNT(page_title) FROM page LEFT JOIN page_props ON page_id=pp_page AND pp_propname = 'wikibase_item' WHERE page_namespace=0 AND page_is_redirect=0 AND pp_propname IS NULL ORDER BY page_title ASC ;). At nlwiki it's 325830 out of 1.574.030 and enwiki it's 430084 out of 4,248,565. That's a lot of pages to touch. Maybe better to do this serverside? Run the query once and submit the pages (slowly) to the jobqueue for invalidation? Multichill (talk) 16:09, 4 June 2013 (UTC)

@Multichill first part make sort of sense (yes a special page can be made into an API call), but last part doesn't (always touch the page? ..eh?). I didn't put any effort into making this callable through the API. Perhaps its a good idea, I don't know. A lot of the articles do not have registered page properties even if they do have associated items, and thats the reason why they are listed now, not because the item relation is missing. That is a fault that can be easily rectified by a nulledit. This is not something that shall not be done in the future, it is so because we didn't do it like that when we started and it will take months before all articles are updated. It does not make sense to touch articles from the special page itself, the special page simply report a state for the article and this state is now wrong for a lot of pages. Jeblad (talk) 16:17, 4 June 2013 (UTC)

I am happy to purge everything with 'forcelinkupdate' (which seems to do the job) if it is really needed? ·addshore· ^{talk to me!} 18:24, 4 June 2013 (UTC)

Just throwing some numbers together, this would take days. ·addshore· ^{talk to me!} 18:33, 4 June 2013 (UTC)

...And we finally got rid of all "(12345) ..." Asteroids! --Ricordisamoa 21:18, 4 June 2013 (UTC)

O_o? ·addshore· ^{talk to me!} 08:45, 5 June 2013 (UTC)

What I'm saying is that it would be a waste of resources to nulledit all the pages in a Wikipedia. If the api would have been implemented it could be used as input for the bot so that only 325830 instead of 1.574.030 need to be touched. Now I just did this query and my bot is now running on this list (touch.py -lang:nl -file:articles_not_wikidata.txt). I'm not proud of it, but it works. It sure beats running touch.py -start:! . Judging from the numbers it looks like someone already did de, fr and it. Multichill (talk) 21:04, 9 June 2013 (UTC)

Awesome, well I doubt the 'touches' will cause any drastic effects anywhere :) so keep it up! :D ·addshore· ^{talk to me!} 13:37, 12 June 2013 (UTC)

I'm instead using some sort of screen-scraping (with BeautifulSoup) to get en:Special:UnconnectedPages; also, done some from it:Special:UnconnectedPages. --Ricordisamoa 22:59, 13 June 2013 (UTC)

More than one interwiki per language ?

Would it be possible to allow the addition of more than one interwiki link in a given language? The only reason I see for not having this already is that the majority of Wikipedias have only one article per subject, but what if a Wikipedia allows to have more than one article for the same subject? Amqui (talk) 18:05, 11 June 2013 (UTC)

Huh? Why would they want to have more than one article about one subject? Are you thinking of any specific Wikipedia, or is the question purely hypothetical? Byrial (talk) 19:03, 11 June 2013 (UTC)

There are situations when different Wikipedias have differents sets of articles (many of the situations mention, e.g., here are of this category). But allowing more than one interwiki link will result in a mess. You talk about situations with one article - two articles. But there can be situations with two articles in one language correspond to three articles in another language (and one article in the third language). It would be simply unbearable. --Michgrig (talk) 19:27, 11 June 2013 (UTC)

The articles in different Wikipedias may have all variations of overlaping subjects, and that has been discussed numerous times. But that is different than one Wikipedia allowing two articles about the same subject. Byrial (talk) 19:40, 11 June 2013 (UTC)

I thought that 'no forking' is one of the basic rules in every Wikipedia. So I didn't even think about this possibility :) Am I not right? --Michgrig (talk) 19:47, 11 June 2013 (UTC)

I call this the Bonnie and Clyde (Q219937) problem. Some wikipedias have an article on Bonnie and Clyde while others have separate articles on Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). We have agreed that the devs will amend the software so we can link to redirect pages as well as linking to articles. This should, in most cases, solve this problem. Filceolaire (talk) 19:55, 11 June 2013 (UTC)

There is a property for this case, but some people want to delete it.JAn Dudík (talk) 20:09, 11 June 2013 (UTC)

It's reciprocal and therefore redundant, no information would be lost. —★PοωερZ_talk 20:25, 11 June 2013 (UTC)

The question isn't hypothetical. Some Wikipedias in small languages where the language isn't as codified as bigger languages like English may have the exact same subject in different dialects, or even only for languages that use different scripts, they may have the same subject written in each script. An example of that is w:cr:ᒥᒋᓯᐤ and w:cr:Mikisiw ka wapictikwanetc, both are about the bald eagle. Amqui (talk) 21:20, 12 June 2013 (UTC)

Also similar to the problem of Incubator. --MF-W 21:26, 12 June 2013 (UTC)

Maybe a solution would be to allow to use more than one "language name" per project. It would work for the Incubator problem as well as Wikipedias with more than one dialect or different scripts. We would use different "language names", but the interwiki links themselves would point to the same project. Using the above example, the interwiki table for "bald eagle" could contain "ᒥᒋᓯᐤ" for "Iyiyiw-Ayimuwin (syllabics)" and "Mikisiw ka wapictikwanetc" for "Atikamekw", but both would point to crwiki. It wasn't really doable with the previous way to handle interwikis, but with Wikidata I think it is implementable. Amqui (talk) 19:36, 13 June 2013 (UTC)

Working guidelines for Wikidata:Properties for deletion

As one of the few people that's been closing properties for deletion in the past few weeks, I've been making up the rules pretty much as I go. It's not that I want to be doing it, it's just that there's never been any real effort to set up a deletion policy for properties. Therefore I propose that the following guidelines be put into place:

• Whomever nominates a property for deletion must inform the property creator and the property proposer (the person that suggested it at Wikidata:Property proposal) that the property is up for deletion. While it would be considered a courtesy to inform relevant task forces, that is not required.
• Property for deletion discussions are closed whenever a consensus is reached, or when the closing admin determines that it would be impossible for consensus to develop (usually if after several weeks, opinions are still split). If the closing admin determines that it would be impossible for consensus to develop in the deletion session, they can suggest an RfC be held to resolve the issue.
  • As a general statement, discussions should run for a minimum of three days, even when there is a clear consensus for keeping or deleting an item, however discussions can be closed earlier if a property is in the wrong datatype, was created in error (and creator nominates for deletion immediately after creating it), or if the property creation guidelines were unambiguously not followed (if, for example, a property was created with no prior discussion or the property's proposal had no support).
  • Unlike deletion discussions on other projects, there is not a set cut off date at which point the discussion is supposed to end. If it takes six weeks for the discussion to pan out, it takes six weeks for it to pan out.
• There is no formal appeals process for property for deletion discussions. If someone contests a "keep" result, they can always renominate it for deletion, however they are discouraged from doing so without a strong reason or immediately following a previous discussion's closing. If someone contests a "delete" vote, and it has only been a few days since the deletion, they are encouraged to explain their reasoning for keeping the item (having it restored) below the closed discussion, and then bringing their post to the closing admin's attention. The closing admin can then make a decision to reopen the discussion. If the closing admin chooses not to reopen the discussion, or if significant time has passed since the deletion, the property can always be proposed again, through the Wikidata:Property proposal process.

I believe that this is a reasonable set of guidelines for the area. Property deletion discussions are often some of the most complex discussions on the project, and sometimes can be highly impactful. I believe this strikes a good balance between giving people a framework to work from and not constraining the process too much in red tape.

Thoughts? Sven Manguard Wha? 20:34, 12 June 2013 (UTC)

Personally I agree with all but perhaps the notice about nomination for deletion could be more centralised rather than tracking the property creator and proposer? John F. Lewis (talk) 20:40, 12 June 2013 (UTC)

 Support - Clear and well written. I would personally inform task forces if it looks like it is an important property for them. --Tobias1984 (talk) 21:32, 12 June 2013 (UTC)

Notification on property talk page is required. And we need some idea how to trace and fix property usage in Wikipedia. — Ivan A. Krestinin (talk) 21:45, 12 June 2013 (UTC)

Looks good, I do wish there was a way we could properly notify Wikipedia's that are using properties before they get deleted. Legoktm (talk) 22:08, 12 June 2013 (UTC)

I'd be willing to settle for being able to see where properties are being used off of Wikidata. I don't know how to do that. Sven Manguard Wha? 22:24, 12 June 2013 (UTC)

 Support with the suggestions of Ivan A. Krestinin and Tobias1984. --Paperoastro (talk) 10:12, 13 June 2013 (UTC)

 Support, too. I'm planning a bot script to notify the creators of such properties. --Ricordisamoa 22:52, 13 June 2013 (UTC)

Wikipedia Category Items which do not have wikipedia articles

I found an item which corresponds to a Wikipedia category ( Category:Religious buildings and structures (Q5655238) ) which seems really fine (not surprisingly) to be used with subclass and instance of relationship. The problem is that I do not know of a policy related to using those items which seems to be competing with items which corresponds to aticles on the main wp namespaces. This one does not seem to be (and even if it has the question deserve an answer). What do we do in those cases ? TomT0m (talk) 09:18, 13 June 2013 (UTC)

I would use structure of worship (Q1370598) instead of the category item. I have added the alias "religious building" to the item so it can be found more easily.--Micru (talk) 17:27, 13 June 2013 (UTC)

Ok, but as I said the question remains for other examples, for example there is a Catholic religious building category. or Q13328939. There is a main article template in wikipedia to link categories to their main articles. Can we use items for catégories whithout a main articles ? I'm starting to think that actually wikipedias categories with a main article and this wikipedia articles should be linked to the same items. So we could have, per item and per language link zéro or one wp article plus zéro or one categories. TomT0m (talk) 20:14, 13 June 2013 (UTC)

It may convenient to be able to have one article per namespace per language, but absent software changes, I do not think we should ever use "category-items" the same way as "main-items, as it is messy, and tedious to update if the main-item gets created afterwards. --Zolo (talk) 21:35, 13 June 2013 (UTC)

Problem in Wikidata:Administrators/Timeline

Hi, When I enable Persian language in wikidata, the administrators timeline gets a error and doesn'n show correctly.(see image)

Javad|Talk (19 Khordad 1392) 12:32, 9 June 2013 (UTC)

Unicode support in the Timeline extension hasn't been fully enabled yet. Please see mw:Extension:EasyTimeline#Unicode. --Ricordisamoa 14:17, 9 June 2013 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. "RESOLVED WONTFIX" --Ricordisamoa 22:26, 9 June 2013 (UTC)

This was the case with Gujarati and Bengali also I pointed that out and User:Byrial solved it.--Vyom25 (talk) 06:33, 10 June 2013 (UTC)

Unfortunately this is not the same. I prevented the current date used by the chart from be localized. What gives errors here, is translation of the legend, and I guess that you also will have problems if you translate the legend to Gujarati. Byrial (talk) 07:17, 10 June 2013 (UTC)

Well, I looked some more at the Persian translation, and it seems that the error messages was caused by something as simple as having spaces instead of underscores. I replaced the spaces and now the error message has disappeared, but the legend is rendered in the chart as empty boxes. The chart is a PNG image, and I cannot fix that the program making the image cannot render Persian letters. Byrial (talk) 08:05, 10 June 2013 (UTC)

I think I messed something...I see Gujarati legend on English page of Admin timeline and I see English legend on Gujarati page. But you are right about underscores. At least Gujarati text is visible.--Vyom25 (talk) 17:30, 10 June 2013 (UTC)

No, it was not something you did. The legend followed the selected interface language independent of the language of the viewed page. I changed that at Template:AdminsChart so the legend will now depend on the language version of the page which includes the template (that will normally be Wikidata:Administrators/Timeline or one the translations of that page). Byrial (talk) 20:44, 10 June 2013 (UTC)

It's only Persian. Beside Germanic languages and Indic languages; Japanese and Korean doesn't have the legends translated. Is it a right to left script thing? Because that's the only thing different between Persian and others.--Vyom25 (talk) 10:35, 11 June 2013 (UTC)

It may be. I don't know. We will see which works when more translation is done. Byrial (talk) 10:45, 12 June 2013 (UTC)

please see this this bug leaves more than 6 years!188.159.203.75 05:02, 13 June 2013 (UTC)

This appears to be irrelevant to this particular discussion.--Jasper Deng (talk) 05:09, 13 June 2013 (UTC)

may be this one is relevant188.158.216.225 13:14, 14 June 2013 (UTC)

Yes, It looks relevant and looks quiet unsolved. From reading comments there my suspicion about right to left scripts was partially correct.--Vyom25 (talk) 06:21, 15 June 2013 (UTC)

Lua calls to Wikibase give Script Errors

See mw:Thread:Extension talk:Scribunto/Lua calls to Wikibase give Script Errors. Helder 18:40, 13 June 2013 (UTC)

The problem isn't Wikibase, it's his code. To start with, in the functions m.id, m.label and m.page he needs to change the global variable p to m (p.entity should be m.entity, p.id should be m.id and so on).--Snaevar (talk) 10:32, 14 June 2013 (UTC)

Request for split?

I know there is a site "request for merge". But is there also one for splitting request? I found that Q125348 is about two different persons. But I'm not able to fix it by myself. --Nightwish62 (talk) 20:17, 13 June 2013 (UTC)

In a case like this where there aren't many pages linked, it's easy to manually. I created Q13445660 and moved the nl.wiki individual to that item. As far as I understand, this solves the problem. Cheers, Pichpich (talk) 21:23, 13 June 2013 (UTC)

Where the pages are complicated, you should list the item at WD:IC in my opinion. --Izno (talk) 21:34, 13 June 2013 (UTC)

Thank to you both. --Nightwish62 (talk) 19:52, 14 June 2013 (UTC)

The need for a BLP policy

I know the idea has been thrown around before but I think it's time to get a proper policy about biographies (or in our case items) of living people. Way back in March, the bot request Wikidata:Requests for permissions/Bot/Dexbot 2 green-lighted the importation from en.wiki of statements about a person's sexual orientation and thousands of such claims were added, including for items of living people. Obviously, bots cannot check that a claim on en.wiki is properly referenced and although (thank god) sexual orientation is not as controversial as it was even a few years ago, it's still a delicate matter and a potential breach of privacy. On de.wiki, nobody would allow a claim about someone's sexual orientation (in particular if it's a living person) when the only reference is en.wiki. So we shouldn't allow a similar statement on Wikidata that is blindly imported from en.wiki and it would be nice to codify this a little bit. Pichpich (talk) 22:33, 13 June 2013 (UTC)

I agree that we need this. Should we start by copying from the policy on material about living persons on a Wikimedia content project (Q4663389) pages from the various wikipedias and then edit them here? Filceolaire (talk) 20:16, 14 June 2013 (UTC)

From what it sounds like, the issue here is how various Wikipedias have different standards for what is and isn't includable around living people. We could take the easy route out and thus model a BLP policy based on the strictest one present on a Wikipedia, but IMO a better route would be to create another long winded RFC for our own community to decide for itself. I would personally be OK with any claims added, so long as there is an appropriate reference for them on at least one project. Unfortunately, that isn't possible to do via bot right now, but that could at least be a starting point for human-added claims. In the mean time, perhaps bots could stop adding such potentially controversial claims? Ajraddatz (Talk) 23:29, 14 June 2013 (UTC)

A prerequisite for a BLP policy is a verifiability policy, because BLP is all about verfiability with specific regard to living people.--Jasper Deng (talk) 23:35, 14 June 2013 (UTC)

Also, there exists a draft at Wikidata:Living people.--Jasper Deng (talk) 23:39, 14 June 2013 (UTC)

Well, we already have a notability policy which covers that. That draft looks pretty good - I'm a bit busy right now, but I'll take a more in-depth look in a bit. Ajraddatz (Talk) 23:47, 14 June 2013 (UTC)

@Jasper. Thanks for the pointer to the draft. It's true that we also need something resembling a verifiability policy but until we codify all that, we could still have a basic agreement along the lines of "adding controversial statements about living people without a solid reference = bad bad bad". Pichpich (talk) 03:34, 15 June 2013 (UTC)

Merge.js

Is it just me or has the gadget merge disappeared from wikidata. I dont know if a recent update of the gadget may be the cause of this - Foxie001 (talk) 17:03, 14 June 2013 (UTC)

Nope, still appears for me. Ajraddatz (Talk) 23:31, 14 June 2013 (UTC)

There was an error, but now it is  fixed and working. --Ricordisamoa 02:45, 15 June 2013 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Ricordisamoa 02:46, 15 June 2013 (UTC)

New reports for Wikidata

As you might know we have been maintaining a central report repository on the Toolserver for quite some time. Today we added two new reports:

• New pages that do not link to a Wikidata item yet. For example the Dutch Wikipedia: newpagevswikidata report
• All pages that do not link to a Wikidata item yet. For example French Wikipedia allpagesvswikidata report. These tables are not fully populated for all Wikipedia's yet, so you might get incorrect results.

Have fun. Multichill (talk) 21:13, 9 June 2013 (UTC)

These reports have the same false positives as Speciel:UnconnectedPages. Also connected pages are on the list until they are edited next time. Byrial (talk) 08:14, 10 June 2013 (UTC)

True, this will be corrected over time. The second one is a duplicated of the unconnected pages so it will probably disappear. Instead of that one we now have "Old pages that are not linked to from WikiData": Lists (max 1000) pages that were not created recently and that do not have a linked WikiData page yet. See for example this report. We should be able to reduce this report to no pages over time. Multichill (talk) 12:42, 15 June 2013 (UTC)

Determination of sex from pronoun usage in Wikipedia

Pichpich have suggested to use the occurrences of sex specific personal pronouns in Wikipedia articles to determine the sex of items of type person. I worked a little on that, and made User:Byrial/Use of he and she in enwiki‎ which shows the distribution of articles in English Wikipedia about persons with known sex after the difference between the number of occurrences of the words "he" and "she". The result is that this difference is a good indication of the sex of the person. I listed some of the cases where articles about male persons have most occurrences of "she", and where female persons have most occurrences of "he", and many of these cases is due to a wrong indication of the sex here at Wikidata. I made a similar analysis for articles at the Danish Wikipedia at da:Bruger:Byrial/han-hun which show similar results.

So now the question is if it would be acceptable to set a bot to automatically add sex statements to many thousands items where the difference between the numbers of "he" and "she" (or similar pronouns in other languages) is largest? Byrial (talk) 09:40, 14 June 2013 (UTC)

Nice work. One interesting feature is that this can help identify mistakes. If one looks at your list of paradoxes (males with too many 'she' and females with too many 'he'), you see the following

• list articles (these could easily be filtered out by removing any article whose title contains words like "characters", "list")
• articles about a couple or duo of some sort (again, can be filtered out by skipping articles with "and" in the title)
• articles about people whose name contains "he" or "she" (can be filtered out)
• articles who are currently labeled as male on Wikidata but who are actually female! In other words, your data isn't paradoxical, it's just identifying mistakes.

Out of the 36 articles which are currently tagged as male despite having more "she" occurrences, you find 1 list, 1 article about a couple, 1 person whose name contains the word "she", 25 people who are indeed women but are listed as male on Wikidata and 8 people who are indeed male. The second list is similar and I think this shows two things: first, this method is probably excellent if we set the threshold for being conclusive high enough (say |diff| >25). Second, this method could be very useful in identifying current mistakes and I think that's a nice feature. We know that the method of classifying using the first name is not perfect and we know the he/she method isn't perfect either but if we can manually check the few cases where the two methods disagree, the overall error rate will be excellent. Pichpich (talk) 15:06, 14 June 2013 (UTC)

If you are going to analyze a text for the subject's sex, to check for things like occupation sounds more promising to me. While in English, there's only a few cases where you can decide the sex from the occupation (like actor/actress), other languages like German or French do have that for almost any occupation, and often this can be detected without having a complete dictionary, as often typical suffixes like -in oder -euse are used. However, false positives still are possible, even if you just check the persondata etc. (like being "the son of the famous actress XYZ" doesn't make you a woman). But, when analyzing an rticle text like described, this should be considered, too. --YMS (talk) 15:29, 14 June 2013 (UTC)

True but only if you look at the first sentence or two. The fact that the word "actrice" appears in the second paragraph probably correlated pretty poorly with the subject's sex. I'm also skeptical about checking only for suffixes. For instance, the number of German words ending in -in (including the word "in" itself!) is too large to avoid tons of false positives. In any case, the method you suggest doesn't need to replace the he/she method. As I noted, having a variety of pretty good methods and using them simultaneously is the best way to get to 0% error. Pichpich (talk) 15:44, 14 June 2013 (UTC)

Using the genus for the occupation from Swedish can be misleading, since it can be the neutral genus. -- Lavallen (block) 17:08, 14 June 2013 (UTC)

The German Wikipedia has de:Kategorie:Mann or de:Kategorie:Frau in every biographical article. So no need to guess there. --91.67.136.169 01:50, 15 June 2013 (UTC)

This is true for 99% of biographies on de.wiki and IIRC there are already bots importing that info. The above is one of many plan Bs for the rest (including all the biographies that are not on de.wiki). Pichpich (talk) 01:57, 15 June 2013 (UTC)

Czech wikipedia have cs:kategori:Muži and cs:kategorie:Ženy too, and my bot imported these statements to all involved articles. JAn Dudík (talk) 19:22, 15 June 2013 (UTC)

Geocoordinates are here!

Heya folks :)

We've just deployed new code here. We fixed a few bugs, most notably:

• bugzilla:45244 - Shows statements from "oldid" version, not "diff" version
• Fixed a number of issues in translatable messages that made it hard to translate them

In addition to that there is also shiny new stuff:

• Bene* wrote a new special page to set language links without JavaScript enabled (Special:SetSiteLink)
• Made first version of the geocoordinates datatype available \o/ This means that you will be able to enter the coordinates of a city for example as soon as someone created the necessary property for it. (There are a few waiting on Wikidata:Property proposal.) It's still a bit wonky so please do let me know about any issues you find. We're already aware of:
  • bugzilla:49385 - cardinal directions in geocoordinate datatype are not localized
  • bugzilla:49386 - apostrophe issue in geocoordinate UI
  • bugzilla:49387 - property parser function needs to support geocoordinate datatype

Please subscribe to these bugs to stay up-to-date and please vote on the ones you care about most to help us prioritize. (You can find a list of all open bugs here.)

Cheers --Lydia Pintscher (WMDE) (talk) 18:48, 10 June 2013 (UTC)

coordinate location (P625) have been created. See, as example, KV1 (Q778902). Tpt (talk) 19:06, 10 June 2013 (UTC)

That's great ! Any idea about when (if ever) we will get the geoshape datatype ? I suppose this will affect how we use point coordinates. --Zolo (talk) 19:10, 10 June 2013 (UTC)

+1. If we are going to get geoshapes, then things like New York probably shouldn't be given point coordinates. Actually, point coordinates would probably be somewhat rare, as few things are so small that they can't be given a shape on a map. --Yair rand (talk) 19:31, 10 June 2013 (UTC)

They're on the list but not on the short-term list if that helps. --Lydia Pintscher (WMDE) (talk) 19:33, 10 June 2013 (UTC)

What happened to being able to specify a coordinate system, per m:Wikidata/Development/Representing_values#Coordinate? Was that idea abandoned, or is it planned for a later release? --Yair rand (talk) 19:14, 10 June 2013 (UTC)

This is an initial version. More elaborate things will follow. --Lydia Pintscher (WMDE) (talk) 19:34, 10 June 2013 (UTC)

Special:SetSiteLink allows to set links which are already in use on another item. (Example, this is already here: Q467402). --Stryn (talk) 19:17, 10 June 2013 (UTC)

Urgh. Not good. Bene* is looking into it. --Lydia Pintscher (WMDE) (talk) 19:34, 10 June 2013 (UTC)

This should be fixed now. Thanks for noticing this so quickly. --Lydia Pintscher (WMDE) (talk) 10:07, 11 June 2013 (UTC)

I don't think en:Selenographic coordinates, etc. should be a different datatype than geocoordinates. Is someone working on this issue? And what about elevation? —★PοωερZ_talk 19:24, 10 June 2013 (UTC)

They are not a different datatype. As I wrote above this is a first version. More will follow. --Lydia Pintscher (WMDE) (talk) 19:35, 10 June 2013 (UTC)

I tried to copypaste coordinates from Geohack in DMS format, but it does not understand them. If I copypaste coordinates in decimal format, it understands.--Ahonc (talk) 19:49, 10 June 2013 (UTC)

Does it use apostrophes or single quotes? --Rschen7754 19:51, 10 June 2013 (UTC)

It was 50° 27′ 0″ N, 30° 31′ 25″ E (copied from [4]). It does not recognized. But if copy 50.45°, 30.523611° it is recognized.--Ahonc (talk) 20:21, 10 June 2013 (UTC)

This should be the bug I mentioned in the initial post here? --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)

Hi Lydia! Thanks to all developers! In future elaboration will be possible to use also astronomical coordinates? --Paperoastro (talk) 21:01, 10 June 2013 (UTC)

The info I have on that is that it is still undecided. But I'll check with Denny when he's back from vacation. --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)

With pyrev:11636, geocoordinates can now be used in pywikibot's rewrite branch. I'm also working on implementing the GeoData API, so it should be 4-5 lines of code to import coordinates from a Wikipedia :) Legoktm (talk) 21:15, 10 June 2013 (UTC)

Nice :) --Lydia Pintscher (WMDE) (talk) 10:13, 11 June 2013 (UTC)

There are problems with GeoAPI: it does not allow to get precision. For example {{coord|56|0|N|190|0|E}} have precision 0.0166667, {{coord|56|N|190|E}} have precision 1. But GeoAPI returns equal results for these cases. Another problem is hi-precision values: GeoAPI truncates it. There is solution: analyze page`s source, but this is not 4-5 lines. — Ivan A. Krestinin (talk) 09:15, 16 June 2013 (UTC)

Need qualifier for indicate 'acting president'

I added some of the past head of governments of New York City, based on W:List_of_mayors_of_New_York_City. However, there was multiple time an acting president. I didn't know how I could indicate that, so I took the qualifier/property 'role' for the moment. Is there already a more appropriate qualifier or should we create one? In my opinion something like "as" would be good. --Nightwish62 (talk) 22:30, 11 June 2013 (UTC)

• Please do not use "role" for things other than to specify actors. It doesn't make any sense in non-English languages. --Yair rand (talk) 00:24, 12 June 2013 (UTC)
• Is position held (P39) not an option? Otherwise we have to think of a new property that can be broadly applied to such cases. --Tobias1984 (talk) 16:43, 12 June 2013 (UTC)
  • Thank you. I changed it to 'office held'. Hoever, I notice I did another fault. I entered "acting president", but it should be "acting mayor". But "acting mayor" didn't have any sitelink/item W:Acting_Mayor. I know there was a discussion if we could also use redirects, but I don't no what's the conclusion was? So what should I do? --Nightwish62 (talk) 21:00, 12 June 2013 (UTC)

• I think in this case it would be best to create a new item "acting mayor", set main type to "term", subclass of = "political office" or "mayor" and whatever else might look appropriate. For sources you can probably look for an "introduction to political science" text book, by searching "acting mayor" on a book search platform.
  By the way: You could create a task force page and write up some guidelines for political science. I'm sure more people would be interested. --Tobias1984 (talk) 21:26, 12 June 2013 (UTC)

• Ok, I created "acting mayor". But then I got confused about the term "acting". I'm a non-native English speaker and now I struggle with this word. dict.cc says "acting" means (in german) "amtierend" AND (!!) "stellvertretend". It also says "acting major" = "amtierender Bürgermeister" and "deputy mayor" = "stellvertretender Bürgermeister". So what's the right term for a mayor which takes the lead for a short time when the official mayor dies? Acting or deputy mayor? Wouldn't be the term "acting mayor" fit to all entries in this list (both: regular elected and as representative of)? On the other site, [W:Mayor#Acting_mayor]] explains exactly what I'm looking for, but the word "acting" didn't explicit tell it is in representative of someone else (stellvertretend)? --Nightwish62 (talk) 22:07, 12 June 2013 (UTC)

• Also auf Deutsch nennt man sowas doch Interimsregierung (i.d.F. Interimsbürgermeister). Die Übersetzung in Dict ist in dem Fall sogar falsch. Auf Englisch hab ich gesehen, dass man auch "provisional government" sagen kann. Man könnte also wahrscheinlich auch "provisional mayor" sagen, damit die Sache etwas klarer als mit "acting mayor" ist. --Tobias1984 (talk) 22:29, 12 June 2013 (UTC)
• Noch besser: Das Wort "Interim" wird auf Englisch auch verwendet. Ich mach das mal zur primären Beschreibung von interim mayor (Q13436054), dann sollte es auch keine Verwechslungen geben. mfg --Tobias1984 (talk) 22:38, 12 June 2013 (UTC)

• Tricky! I can imagine five or six different words in Swedish depending on time, circumstances and type of office. "acting mayor" would normally be "tillförordnad borgmästare". "acting king" would be "riksföreståndare". -- Lavallen (block) 15:17, 13 June 2013 (UTC)
• Danke für die Hilfe. Also welche der Übersetzungen genau auf dict.cc findest du falsch? Wenn man einfach mal googlet und die Begriffe in Anführungszeichen setzt, so ist "acting mayor" am meisten verwendet, dann kommt "interim mayor" und ganz am Schluss "provisional mayor". Ich denke, "interim mayor" ist am deutlichsten, aber verwendet wird wohl "acting mayor", den so lautet ja auch der Abschnitt in der Wikipedia (siehe Link oben). --46.255.169.80 18:54, 13 June 2013 (UTC)

• Ich denke die Übersetzung "acting mayor" zu "amtierender Bürgermeister" ist falsch. Es stimmt zwar, dass der Interimsbürgermeister auch amtierend ist, aber an erster Stelle ist er aus einer politischen Notsituation zu dem Amt gekommen. Wenn du willst kannst du den Titel ruhig auf "acting mayor" ändern. --Tobias1984 (talk) 19:24, 13 June 2013 (UTC)

That is a different thing, but still I think the value of "head of government" for New York City should be Mayor of New York City (Q785304), rather than a list of people who were mayors of New York. --Zolo (talk) 21:24, 13 June 2013 (UTC)

You said something I already thought too. It's an important question and one of the hundreds of how we should collect data. I'm not sure which way is the better one at moment. However, doing it your way, we could create about 10 millions+ new items for every city or municipality of the world. --Nightwish62 (talk) 14:12, 16 June 2013 (UTC)

Idea to improve the input box

Anyone who has added many claims to items knows that the input box can be pretty frustrating when there's lots of things with the same name. If someone wants to input "George Washington" into an item, chances are they mean George Washington (Q23) (the U.S. president), not George Washington (Q586680) (a television miniseries), or George Washington (Q2366114) (a businessman), but President Washington doesn't even appear in the first page of results from the dropdown. A simple way to resolve this would be to have the dropdown sort the items by the number of other items that link to them, since if an item has been linked to by many other items, it's probable that the user will be wanting to add another link to the same item. Since this isn't something that needs to be exactly up to date at all times, the count list could be cached and regenerated at some regular interval, perhaps once a week or so. It's probably not the ideal solution, but it's better than whatever method the box uses now. Thoughts? —Scott5114↗ [EXACT CHANGE ONLY] 00:44, 16 June 2013 (UTC)

I (or someone else) could write a JS patch for this, but I'd prefer to discuss it on bugzilla. --Ricordisamoa 02:38, 16 June 2013 (UTC)

I've been thinking the same and this would be particularly helpful when adding statements manually. For instance if one tries to add the statement that XYZ is an album, it's necessary to scroll down to "more" before finding Q482994 despite the fact that it has tens of thousands of incoming links. (In fact I'm curious: exactly how are those lists of items ranked? ID number?) Pichpich (talk) 03:03, 16 June 2013 (UTC)

I don't think it's ID number, since President Washington has an ID number of only 23, and yet he ends up way down the list (in fact, at the very bottom of the plain "George Washington"s before things that have other things behind "George Washington"). I can't discern any pattern at all from the ID numbers, actually, either ascending or descending by numerical value or alphabetical value of the digits, so I have no idea what order the box sorts them in. Whatever it is, the items do at least stay in a consistent order from day to day. I had considered opening a bug on Bugzilla for this, but figured it'd be a good idea to get input from Wikidata users behind it first so we can demonstrate to the devs that this is a desired change. —Scott5114↗ [EXACT CHANGE ONLY] 06:55, 16 June 2013 (UTC)

I support this idea 100%. A couple days ago I was updating the items for all of the U.S. states. I distinctly remember the item for the actual state of California being the very last "California" item before other things popped up, and it was like the third page of dropdowns. TCN7JM 07:18, 16 June 2013 (UTC)

 Support too. I also think this could avoid wrong edits, since not every item has a description. Sure, I know in this situation I've to check up the right item beforehand, but a new Wikidatia user could just pick the first one of the list. Even this is a wrong behavior, when sorting as descripted above, the chance is bigger he picks the right one by accident. --Nightwish62 (talk) 13:55, 16 June 2013 (UTC)

Guys, it'd be better if you added descriptions and proper aliases to items. It did work for me in my language and now I run into such problems way more rarely :) Infovarius (talk) 20:16, 16 June 2013 (UTC)

Aliases and descriptions are not a panacea. In the case of George Washington above, every one of the items in question is properly labeled "George Washington" since that is the name of all of them, and they all bear descriptions. It's just that Q23, the most prominent item with that name, is sorted to the bottom of the list, meaning one has to click "more" several times to get to it unless you just happen to know the item number. In fact, I've had to commit west (Q679) to memory because I use it so frequently and it's such a pain to get to in the dropdown. —Scott5114↗ [EXACT CHANGE ONLY] 22:16, 16 June 2013 (UTC)

That's inpiring, the item suggester should take into account our recent history of edition (and maybe its neighborhood). Another thing, what about a "bookmark item" gadget which would make some chosen items always available ? TomT0m (talk) 10:29, 17 June 2013 (UTC)

We have bugzilla:45351 for this issue. --Lydia Pintscher (WMDE) (talk) 09:34, 16 June 2013 (UTC)

tool for adding article to existing Wikidata item

Hello, I have used several times the tool which helps adding an article from el.wikipedia to an existing Wikidata item. The tool works fine and thank you to the developers.... however... it does not update the title of the item.

An example: I used the tool to add the el article to Wikidata, but then I had to come to Wikidata and also change the label. Since these are in principle the same, why not allow the tool to do it automatically and save us some time? --FocalPoint (talk) 07:10, 16 June 2013 (UTC)

 Support. I don't see any reason why not to make it automatically add the label also. --Stryn (talk) 08:35, 16 June 2013 (UTC)

For now you can use autoEdit. --Ricordisamoa 09:47, 16 June 2013 (UTC)

 Support I agree this should be automatic. --Napoleon.tan (talk) 16:16, 17 June 2013 (UTC)

Final vote on the Guidelines for sourcing statements

Final vote on the "Guidelines for sourcing statements" till June 24. Note that the guidelines are just a recommendation about how to source statements. The discussion whether bots should be required to source statements is a different matter and it will be discussed independently.--Micru (talk) 14:09, 17 June 2013 (UTC)

Links to freebase ?

Hello, Google has asked us about crosslinking with Freebase (Q1453477). Comments should go to Wikidata:Property proposal/Authority control#Freebase identifier. --Zolo (talk) 15:17, 17 June 2013 (UTC)

Wikidata:Requests for comment/Personal names

^ New RFC, please comment. --Yair rand (talk) 01:38, 18 June 2013 (UTC)

Sockpuppetry RfC

The RfC is not merely a proposed policy, but an attempt to develop a policy. See Wikidata:Requests for comment/Sockpuppetry guidelines.--Jasper Deng (talk) 04:18, 18 June 2013 (UTC)

Coordinates for streets

I'd notice that in some Wikipedias infoboxes for streets have two coordinates values: coordinates of beginning of street and coordinates of end of street (see uk:Хрещатик or ru:Крещатик). How to add them in WD? Create new properties or use qualifiers?--Ahonc (talk) 11:02, 17 June 2013 (UTC)

• I think new properties is better. Something like "coordinates of the beginning" and "coordinates of the end". Its can be used for rivers too. coordinate location (P625) will be used in {{coord|...|display=title}}. This construction does not allow multiple values. Property 625 is used for geometric center of such objects as settlements. I think it must be used for streets in the same context (geometric center of street is used in ruwiki, for example Северный проспект). — Ivan A. Krestinin (talk) 12:43, 17 June 2013 (UTC)

• I think it is the same of another usecase: we need one property (street coordinates) which value is an item to which are attached too coordinates properties. Of course it is the same as the editions items for books : we need to wait for user interface improvement related to handling nested items. TomT0m (talk) 15:47, 17 June 2013 (UTC)

• Interesting idea. But is there this idea in developer`s roadmap? If there is no then I suggest use two properties currently and convert its to nested properties then its will be available. — Ivan A. Krestinin (talk) 17:32, 17 June 2013 (UTC)

• Just to remark that this concerns all extended objects (e.g. rivers) as well as areas. Ideally, we should be able to track the whole object which does not have to be straight.--Ymblanter (talk) 17:47, 17 June 2013 (UTC)

• Whole object storing is another task as I think. River`s source and mouth are two very specific and very important points for example. If we will have all river`s points we must highlight and make easy data access to these two points anyway. / In Russian: Думаю, что сохранение всего объекта - немного другая задача. Исток и устье реки, например, - это очень специфичные и важные точки. Даже если мы будем иметь описание всего объекта, то нам всё равно нужно будет выделить эти две точки и обеспечить лёгкий доступ к ним потребителей информации. — Ivan A. Krestinin (talk) 18:38, 17 June 2013 (UTC)

• Indeed it is on the developers roadmap, I understood Denny and others had a talk to solve the problem of books and editions, users saying it would be tedious to create an item for all editions although it would match the logic around this kind of semantic database, and a better interface to edit items linked in the same page was cited as an interface improvements that would benefit not only this usecase but also the whole project, see [5]. TomT0m (talk) 17:59, 17 June 2013 (UTC)

This is not a very good idea to represent streets with coordinates - it's better to use geographic shapefiles for them in order to accurately represent the object. See the thread a ways up. --Rschen7754 08:48, 18 June 2013 (UTC)

FYI: I am not aware of any plans to do nested properties. --Lydia Pintscher (WMDE) (talk) 08:23, 18 June 2013 (UTC)

Restriction of sexual orientation (P91)

In my opinion some property (e.g. sexual orientation (P91)) have a restriction which are contrary to the purpose of Wikidata, as they demand (e.g.): "use IF AND ONLY IF they have stated it themselves, unambiguously, or it has been widely agreed upon by historians after their death".

But, this isn't what Wikidata was designed for. Wikidata is collecting statements, not facts! They don't have to be true, see this blog entry:

[...] Fortunately some of the roots of Wikidata lie in an EU research project called RENDER. The goal of this project is to explore and support the diversity of knowledge on the Web. RENDER discards the assumption of a simple, single truth – and this was inherited by the Wikidata data model. Instead of collecting facts, we collect statements. We define statements as claims that can have references. A reference supports the claim. [...] Without the ability to express a plurality of statements about an item – even if they are considered truths only by some and lies by others – Wikidata would fall short of one of the major pillars of Wikipedia, the Neutral Point of View and the possibility of integrating conflicting points of view. [...]

So I think we should remove the restriction and handle it like every other property too. --Nightwish62 (talk) 21:58, 17 June 2013 (UTC)

See various discussions about BLPs including WMF's relevant policy on it. It's also a bit odd that you're saying that our statements don't need to be true - we obviously want them to be. No, better to keep the restriction on P91. Ajraddatz (Talk) 22:01, 17 June 2013 (UTC)

I think you didn't read the blog. It's no odd opinion of myself, it's (as I mentioned) the purpose of Wikidata to collect statements, whatever they are true or not. Which BLP are you referring? this? They was written for Wikpedia and/or other sister project, but Wikidata has strong other requirements. --Nightwish62 (talk) 22:20, 17 June 2013 (UTC)

Ok, even better, I found this part on the Wikidata requirements:

The following requirements are not negotiable: [...]

• 7.Wikidata will not be about the truth, but about statements and their references. These can be contradictory.

So, the property restriction counteracts to the Wikidata policy! --Nightwish62 (talk) 22:33, 17 June 2013 (UTC)

I agree that we need to do a better job on documenting claims that are not necessarily true, which is why I proposed the "according to" property. However, I think that as we move forward in this regard, we should specifically set aside statements involving living or recently deceased people; to quote the WMF Board: "we have affirmed the need to take into account human dignity and respect for personal privacy when publishing biographies of living persons." I've strongly advocated against the deletion of the sexual orientation property, but I think it's important we maintain a policy of not stating things about living people that they've made it clear they don't want to be said. (For some things, like the "killed by" property, this can be circumvented if an unambiguous finding is made by a trustworthy institution [like a judgment by a court of law], but there's no real correlate of that in terms of sexual orientation). — PinkAmpers&^{(Je vous invite à me parler)} 00:47, 18 June 2013 (UTC)

Nightwish, that "Wikidata requirements" document that you cite was written 6 months before Wikidata ever existed and was never approved by anyone in the Wikidata community. If you read the much more relevant Wikidata:Introduction, you'll find the much much more nuanced sentence "Wikidata will record not just statements, but their sources, thus reflecting the diversity of knowledge available and supporting the notion of verifiability". Now verifiability is not explicitly defined but in every wiki, it assumes reliability of the sources. Pichpich (talk) 04:08, 18 June 2013 (UTC)

• See also Wikidata:Living people. This is one property that will likely be a magnet for violations of that.--Jasper Deng (talk) 00:53, 18 June 2013 (UTC)
  • I should also add that BLP concerns take precedence over that requirement. It's a foundation-level policy, and a common sense one. That one is non-negotiable.--Jasper Deng (talk) 01:03, 18 June 2013 (UTC)
• I personally interpret that line about Wikidata to mean what can be cited, not what people would consider the truth. Ultimately, unless we're coming from the standpoint of some post-modernists, there should be a truth to things, such as what someone's sexual orientation is. But I sidetrack. Jasper is right; the BLP issue overrules Wikidata's requirements. Ajraddatz (Talk) 03:48, 18 June 2013 (UTC)
• That blog post is phrased so poorly that it's hard to take seriously. I don't feel particularly bound by one dev's opinion and his blog post is prefaced with "The essays represent my personal opinion, and are not to be understood as the official opinion of Wikidata." Yes, we want to avoid debates about truth to some extent by using qualifiers and precise sources, but only to a certain extent. We do not want (and I'm sure Denny Vrandecic doesn't want) to have the statement "Justin Bieber is a moron" with the qualifier "according to TMZ", the statement "Barack Obama is a communist" with the qualifier "according to Sarah Palin" or the statement "Vladimir Putin is Santa Claus according to my own ass". So there will be a filter and this filter, as in other Wikimedia projects is the reliability of the source. Reliable sources can still disagree and we can reflect that. However if one takes the extreme "truth, who knows what is true?" attitude, we might as well hand over the keys of the project to every conspiracy theorist (JFK was murdered by the CIA), pseudo-scientist (Bigfoot is part of the fauna of the USA) and militant (Social security in the USA is a Ponzi scheme). All these statements have been made by various crackpots and if Wikidata decides that it can't make a distinction between crackpots and credible analysts, it will be laughed out of existence and more importantly it will never be used by Wikipedia because Wikipedia doesn't treat them equally. Pichpich (talk) 03:53, 18 June 2013 (UTC)
  • Heh, funny you should mention that, since currently JFK is listed as being killed by either Oswald or "unknown value" (and yes, I'm to blame for that). That's a good piece of why I think we need an "according to" property: There's a case where two major reliable sources (the Warren Commission and the House Select Committee on Assassinations, respectively) have reached totally contradictory conclusions, and it would be disingenuous and unreliable to only list one. Anyways, I think you make a very good point on the limits of entertaining multiple POVs, but it's worth noting that there are some legitimate (IMHO) applications. — PinkAmpers&^{(Je vous invite à me parler)} 07:13, 18 June 2013 (UTC)
• On a slightly different topic, I think sexual orientation is a perfectly legitimate property but I agree that it should be sourced properly (as the property's definition recommends), especially when dealing with living people and that Wikipedia itself shouldn't be considered as a sufficiently reliable source in such a case. Pichpich (talk) 03:58, 18 June 2013 (UTC)

It's no fair. Here some response of you:

• The blog is blog post is phrased so poorly that it's hard to take seriously
• The "Wikidata requirements" document was written 6 months before Wikidata ever existed and was never approved by anyone in the Wikidata community

But the "BLP issue overrules Wikidata's requirements", even if they are also wrote before Wikidata exist and they never consider Wikidata and the new requirements / difference to the other projects. Sure we shouldn't collect every statement, otherwise we could also import data directly from Stupipedia. "Vladimir Putin is Santa Claus according to my own ass" -> No. "JFK was murdered by CIA" -> Yes, as it even has an own Wikipedia article and is widely accept. Don't forget we'll have the possibility to rank statements. Those are not only to indicate old values, but for situation like this. --Nightwish62 (talk) 05:45, 18 June 2013 (UTC)

The theory that the CIA killed JFK is not widely accepted and it's important to note that the article you point to is called "CIA Kennedy assassination conspiracy theory" and not "CIA assassination of Kennedy". The line between Stupipedia and Conspiracypedia is very thin. Pichpich (talk) 10:56, 18 June 2013 (UTC)

In the long term I see us as having three sources of data, each of which has to be approached separately:

• Other databases that are open-source: Things like IBDb are going to have lots of useful information, but the veracity might get called into question. I don't think that publicly editable databases should ever hold the top ranking in statements, but they should be included. I'd love to see the ability to have both the source URL and the retrieval date accompany anything that comes from an online source, and especially think it applies here.

• Other databases that are privately curated (such as the CIA World Factbook or Wisertrade) and other "reliable third party sources" (bread and butter Wikipedia sources): I am of the mind that we pull together the large Wikipedias' policies on reliable third party sourcing, look at what works best from each of them, and create our own reliable third party sources guideline. I am also of the mind that, when available, information from up to date, reliable third party sources should be given top billing in statements.

• First party statements: If Ford Motors states in a press release that their new 2013 Pinto Hybrid gets 37 miles to the gallon, and a reliable third party source pegs it at 34 miles to the gallon, we should include the first party claim and the third party claim. Unlike Wikipedia, there should be no issue with using first party information, so long as it's clear that it is indeed first party information.

One thing that I deliberately didn't include in this is "imported from XX Wikipedia". I'd love to reach the point where we're bypassing that (useless) statement and directly citing the source that the Wikipedia article is using, and I think that the sooner we make that changeover, the better.

With all that in mind, I think that the current restriction might be a little bit harsh; If reliable third party sources say someone is homosexual, that can be listed, but it's important to make sure that people know that the utterances of Perez Hilton and the spewings of tabloids are not reliable sources. If the person in question self-identifies, that'd be a first party statement instead. Both have a place here (but again, Globe and co are not sources that should be used in statements on this project). Sven Manguard Wha? 06:15, 18 June 2013 (UTC)

Some clarification on Denny's blog post: He was writing about the general idea behind Wikidata and it being able to accommodate many different points of view. That does not mean we have to put everything into Wikidata just because it is out there. Common sense and resolutions by the board still hold. --Lydia Pintscher (WMDE) (talk) 08:11, 18 June 2013 (UTC)

Some more clarification on the requirements: Those are requirements for the development and what Wikidata needs to be capable of - not for what we actually put into it. --Lydia Pintscher (WMDE) (talk) 08:15, 18 June 2013 (UTC)

One big problem that people seem to be happy to ignore is the impact of this on queries and on the ability of Wikipedias to include info automatically taken from Wikidata. If queries about American communists start returning Obama and other Democrat politicians or if queries about murderers start returning everyone who has ever been accused of murder, we are screwed (and in the second example, we are completely irresponsible). A few people have pointed out that eventually queries will make Wikipedia's category system obsolete but this is only true if we distinguish reliable and unreliable sources. Pichpich (talk) 10:56, 18 June 2013 (UTC)

there are no reliable sources for nothing, there are trusted sources and less trusted sources and different opinions. But everything is Data and can be stored, searched and queried. --FischX (talk) 11:35, 18 June 2013 (UTC)

As Denny laid out here the plan is to at least initially only include statements marked as preferred in query results. I'd assume these would not include conspiracy theories and similar things. --Lydia Pintscher (WMDE) (talk) 11:53, 18 June 2013 (UTC)

@FischX This post-modern nonsense will kill Wikidata because it will be considered as, at best, a poor source of information and at worst the best place to find laughable data. There are objective truths. The Protocols of the Elders of Zion is an antisemitic hoax, Elvis is dead, man has walked on the moon but has never co-existed with dinosaurs. Opening the door to statements that argue otherwise drowns legitimate data into a sea of noise. Pichpich (talk) 11:58, 18 June 2013 (UTC)

This "post-modern nonsense" is simply best practice of administering data since ages. If or if not "There are objective truths" is not interesting at all for providing data - there are only relations, thats a fact - an objective truth for everyone seriously dealing with data. What kind of Data sourced by UN or Infowars or Stupidedia or what ever are allowed to query should be up to the wiki projects. Of course we should not allow people to import from stupid sources just for practical reasons and state of the software but technical there is no reason for not allowing a query "communist persons by opinion of Tea Party rednecks" --FischX (talk) 12:21, 18 June 2013 (UTC)

Best practice since ages? Come on... And if you want to disallow stupid sources, aren't you going against your own principles? From a practical perspective, we will never get sufficiently fine-grained sourcing to allow queries that distinguish statements made by Tea Party rednecks and of course there's the issue of defining what a redneck is. Maybe we need queries like "all people labeled as communists by someone labeled as a Tea party redneck by a person labeled as a communist." Pichpich (talk) 13:46, 18 June 2013 (UTC)

Yes, best practice - according to "Datenbanken, Konzepte und Sprachen" (Andreas Heuer 1995, Page 19) it dates back to the 70ies :-) and according to our devs they can do it in a user friendly way without knowing SQL. --FischX (talk) 21:41, 18 June 2013 (UTC)

@Nightwish. I think P91 is a bad Example fo your point because the restrictions are no restrictions, because the listed conditions are the only ways the sexual orientation of person can be established.--Saehrimnir (talk) 16:17, 18 June 2013 (UTC)

But that's Nightwish's point: we don't need to establish sexual orientation, we just need to establish that someone has stated something about the sexual orientation. There's no need to distinguish rumor from fact because Wikidata doesn't care about facts. Pichpich (talk) 16:44, 18 June 2013 (UTC)

Tell me the part where I've said we shouldn't distinguish rumor from facts. --Nightwish62 (talk) 18:03, 18 June 2013 (UTC)

The direct quote is "the purpose of Wikidata to collect statements, whatever they are true or not". Pichpich (talk) 19:11, 18 June 2013 (UTC)

Aha, either it's my English skill or your reading comprehension which doesn't let you understand. --Nightwish62 (talk) 20:04, 18 June 2013 (UTC)

I'm guessing it's your English. If Wikidata doesn't care whether a statement is true or not, then it must treat rumors and facts as valid statements. Pichpich (talk) 20:25, 18 June 2013 (UTC)

Pichpich and Nightwish62, if you cannot keep this conversation civil, I will ask you both to stop contributing to this discussion. I don't like the way you two are heading. Sven Manguard Wha? 20:32, 18 June 2013 (UTC)

I'm sorry, but to allege I'm not interested to a trustable database and assume statements I never made, makes me angry. --Nightwish62 (talk) 20:51, 18 June 2013 (UTC)

(my statement): Wikidata to collect statements, whatever they are true or not <-> (your "quote"): Wikidata doesn't care whether a statement is true or not --Nightwish62 (talk) 20:51, 18 June 2013 (UTC)

Both of you are at fault here. Two wrongs don't make a right.--Jasper Deng (talk) 20:58, 18 June 2013 (UTC)

• The quip about English was uncalled for and my sincere apologies to Nightwish about that. But there's an important conversation to be had here. Let's focus on a simple example about P91 and let's take a random celebrity say Tiger Woods (who as far as I understand is heterosexual). And now let's assume four sources for the statement "Tiger Woods is bisexual". Source number 1 is a man who claims on his Facebook page that he spent the last weekend in bed with Tiger Woods. Source number 2 is a blog post of a professional psychologist who says that he believes Tiger Woods is bisexual because of some reason or another (but has never met him). Source 3 is some tabloid (say Globe to follow Sven's example) which says "many believe Tiger Woods is bisexual". Source 4 is the autobiography of Tiger Woods. The question now is: should Wikidata collect any of these statements? Should it treat them in identical fashion? If not, how does Wikidata handle the difference between rumor and credible statement? For a more dramatic example, how do we handle the statement "the Holocaust is a hoax"? Sure, we can say "stated in en:Did Six Million Really Die?" and we might also add the qualifier "is complete bullshit according to all but a handful of discredited bozos" but from a public relations perspective, it's still a disaster for Wikidata. I can see the headline "Wikipedia's knowledge base knows that the Holocaust is a hoax". That would be unfair but "it's just a statement, we never said it was true" is not going to save us from ridicule. Pichpich (talk) 23:37, 18 June 2013 (UTC)

It's okay, I had provoke you and therefore my apology too. Only short to your questions:

• should Wikidata collect any of these statements? --> only those which are widespread and have many supporter / sources
• Should it treat them in identical fashion? --> no, certainly not.
• If not, how does Wikidata handle the difference between rumor and credible statement? --> ranking. One have the 'preferred' rank, the others the 'normal' or even 'obsolete' rank. --Nightwish62 (talk) 01:17, 19 June 2013 (UTC)

 Oppose the proposal from Nightwish to remove this restriction on sexual orientation (P91). This is a BLP issue and we should be extra careful so this should have restrictions which other items don't have. --Filceolaire (talk) 00:28, 19 June 2013 (UTC)

Gadget to insert property-value pair from clipboard

I think will be good idea to have gadget which allows to insert roperty-value pair from clipboard (for example in Property | Value format, numerical values could only be supported to avoid ambiguity). May be without saving. Such gadget will allow small scale automation where time to do thing manually is smaller then time to create bot. --EugeneZelenko (talk) 13:29, 18 June 2013 (UTC)

I use both User:Magnus Manske's wikidata_useful.js script and User:Goldzahn's The Brown Tool. Have a look at Wikidata:Tools as there are several gadgets and scripts for making Wikidata easier to work with. Harryboyles (talk) 05:54, 19 June 2013 (UTC)

How to express several periods through qualifiers?

I'd like to express that the Port Ellen Distillery (Q203404) was founded in 1820, closed in 1929, re-opened in 1966 and definitely closed in 1983. So, I added to instance of (P31) = whisky distillery (Q10373548) the qualifiers start time (P580) = 1820, end time (P582) = 1929, start time (P580) = 1966 and end time (P582) = 1983. But after saving, the chronological order is not respected :

• instance of (P31) = whisky distillery (Q10373548)
  • start time (P580) = 1820
  • start time (P580) = 1966
  • end time (P582) = 1929
  • end time (P582) = 1983

Is there another way to do it? Ayack (talk) 18:06, 18 June 2013 (UTC)

Check it now. I did two instances of whisky distillery, one with one set of dates, the other with the other set of dates. Sven Manguard Wha? 18:40, 18 June 2013 (UTC)

Perfect! I didn't know it was possible to add the same item twice to a same property. Thanks! Ayack (talk) 18:55, 18 June 2013 (UTC)

Blocking people

Can you unblock me? – The preceding unsigned comment was added by 203.184.53.105 (talk • contribs).

The English Wikipedia block, which you probably mean, is not under Wikidata's jurisdiction.--Jasper Deng (talk) 21:45, 18 June 2013 (UTC)

As above, you are not blocked here (this is shown by the fact that you can edit this page). The IP that you are editing from has been blocked from the English Wikipedia for Vandalism. Please see the talk page en:User_talk:203.184.53.105 for further details. ·addshore· ^{talk to me!} 22:08, 18 June 2013 (UTC)

Property image (P18) bug

Hi! on this page, the file name in the title bar of the preview image overlaps with the X to close the preview.--Kky (talk) 10:26, 15 June 2013 (UTC)

Yes, but the X button still works. I don't know if there's a good solution, other than to replace the name of the image with "image preview" or something like that, which I'm not sure is a great idea. Sven Manguard Wha? 17:26, 15 June 2013 (UTC)

I don't understand what you're talking about. Which "preview images"? Do you use any gadget? --77.239.41.207 22:11, 15 June 2013 (UTC)

See the little grey boxes right next to "HeatherGrahamByDimitriSarantis2011.jpg" at Q224026? Click those. Sven Manguard Wha? 22:36, 15 June 2013 (UTC)

That little grey box is made by the CommonsMedia gadget. There is no way to view the image directly by default. So any bugs in the way the image is shown, must be a bug in the gadget. Byrial (talk) 22:46, 15 June 2013 (UTC)

In IE10 I didn't have this preview button, in chrome it works? Is this bug also reported already? --Nightwish62 (talk) 13:47, 16 June 2013 (UTC)

 Question: Do you get any javascript error message in IE? -- Bene* ^t_a^l_k 18:30, 19 June 2013 (UTC)

Unable to edit with Firefox

For some reason I've lately been unable to edit items with Firefox. The [edit] links show up for the page title and description, but not for the actual interwiki links. Otherwise the page is loaded fine and there's nothing in the error console. I'm using Firefox 21.0. Anyone know how to fix this? Thanks. Jafeluv (talk) 10:37, 17 June 2013 (UTC)

I am just updating my version of firefox to see if I also have the issue. Do you have a screenshot? ·addshore· ^{talk to me!} 14:11, 17 June 2013 (UTC)

Added a screenshot displaying the issue. Jafeluv (talk) 06:31, 18 June 2013 (UTC)

I have not had any problems. Also FF 21.0. --Stryn (talk) 14:21, 17 June 2013 (UTC)

I also saw this in my firefox, the entity sometimes show up but sometimes stays as entity ID. I also saw a lot of javascript error in my firebug --Napoleon.tan (talk) 16:22, 17 June 2013 (UTC)

It works for me. This looks like a caching error, or something else messing your Javascript and CSS.--Jasper Deng (talk) 06:32, 18 June 2013 (UTC)

Hmm... Tried blanking my vector.js and CSS but that didn't help. Editing works fine with Chrome, just not with Firefox for some reason. Jafeluv (talk) 07:50, 18 June 2013 (UTC)

Other than clearing your browser cache, there's not much I can suggest - except that it might be a browser add-on.--Jasper Deng (talk) 08:03, 18 June 2013 (UTC)

I should have replied here sooner, I updated and nothing seems broken for me. Also after looking at your screenshot it would seem that you are also missing the sorting arrows for the columns. Could you perhaps load the page in firefox, got to view the source (right click view source), and paste it somewhere for us to see? (perhaps http://pastebin.ca/). If you want to try something extreme you could try reinstalling the whole browser! ·addshore· ^{talk to me!} 22:12, 18 June 2013 (UTC)

Uninstalling Firefox, deleting all saved data and then reinstalling fixed the problem. No idea what the issue was, but now I can edit again. Thanks! Jafeluv (talk) 07:14, 19 June 2013 (UTC)

Heh! It's a shame it had to go that far. Glad to see it resolved! ·addshore· ^{talk to me!} 08:56, 19 June 2013 (UTC)

Items without titles

Okay, so I patrol new pages at Wikipedia. When I see a new page that's good, I come over here to look for its corresponding item. I then make the item, seeing that no results show up at "Item by title" and I try to link the corresponding article in another language only to find that it is already linked in another item-with no title. Is there any way that making items without a title can be disabled? Citrusbowler (talk) 15:10, 19 June 2013 (UTC)

May be there are very few cases where items were created without title. May be you can't see them because they are in other languages (other then English). If the item doesn't have title in English it does not mean it is without title.--Vyom25 (talk) 18:52, 19 June 2013 (UTC)

For example; Q6080685 this is an item from your contribution. here you have added EN label. Now label or title already existed in TR (probably turkish) there since the creation of the item. But you can't see it because there is a system (personally speaking it's inconvenient) here that you can only see EN description as default and you have to add babels on user page to see other language titles and descriptions. From my user page you can get an idea that I can see (GU, EN, MR, HI, SA) titles.--Vyom25 (talk) 19:01, 19 June 2013 (UTC)

Q907941

The value does not comply with the property's definition.

The value's data value type "ununserializable" does not match the property's data type's data value type "globecoordinate".

--GZWDer (talk) 05:01, 20 June 2013 (UTC)

Next data type?

I hardly dare to ask it, because I already asked the same question in the past several times already. But now as we have geocoordinates, what is the next data type we could expect? I'm also missing the development roadmap which was promised since about Easter. --Nightwish62 (talk) 14:16, 16 June 2013 (UTC)

There is this blog entry from a while ago which I already linked here as well. As it says the priorities for the near future are more datatypes, queries and sisterprojects. They're all being worked on. Currently geocoordinate parsing is being improved and we're working on allowing to link to Wikivoyage as a first sisterproject. As for which datatype comes next: I hope URL but since that is a bit more complicated because of the needed input validation another one might come first (number probably). --Lydia Pintscher (WMDE) (talk) 10:11, 17 June 2013 (UTC)

Thank you. --Nightwish62 (talk) 12:28, 17 June 2013 (UTC)

And what about numeric datatype? It is also well-needed.--Ahonc (talk) 10:58, 17 June 2013 (UTC)

They're all needed ;-) Currently URL and number are the ones with the highest priority. --Lydia Pintscher (WMDE) (talk) 12:01, 17 June 2013 (UTC)

What's the difference between number and numeric? --Nightwish62 (talk) 12:28, 17 June 2013 (UTC)

There is none afaict. --Lydia Pintscher (WMDE) (talk) 12:30, 17 June 2013 (UTC)

Is there a unit of measurement for the numeric? like KM, mg, liter, etc? --Napoleon.tan (talk) 16:18, 17 June 2013 (UTC)

Yes that's planned. --Lydia Pintscher (WMDE) (talk) 09:41, 20 June 2013 (UTC)

GSoC Properties

Time sensitive request
The molecular biology task force needs 3 number-properties for GSoC which we could create as string-properties for now. I am still a little uncertain if those three properties could be merged into a single property with 3 qualifiers for the position in the sequence and 1 qualifier for the species. Can a few people vote on Genloc chapter, Genloc start and Genloc end? Thank you for helping out! (Link)--Tobias1984 (talk) 10:11, 18 June 2013 (UTC)
Two more properties
Link, and thank you for helping out. --Tobias1984 (talk) 15:11, 18 June 2013 (UTC)

For those that want to look at the project concerned: http://www.google-melange.com/gsoc/project/google/gsoc2013/chinmay26/24001 --Tobias1984 (talk) 18:24, 20 June 2013 (UTC)

Fictional calendars?

Will fictional calendars (like the one of Tolkiens legendarium) also be implemented one day to the time datatype or should we create something like "fictional date (start/end)" with string datatype? There are many fictional events which should also have a time statement, e.g. when the One Ring (Q19852) was forged, destroyed or who was carrying it at which moment. --Nightwish62 (talk) 21:15, 18 June 2013 (UTC)

I have no clue if it will be, but that would certainly be an interesting and useful feature. Ajraddatz (Talk) 21:52, 18 June 2013 (UTC)

See the video (about 39 minute mark) on the wikimedia foundation meeting may 2013 http://blog.wikimedia.org/2013/06/12/wikimedia-foundation-report-may-2013/, They are aware of adding other Calendar than Julian and Gregorian type. But the addition of alternative calendar's priority is low, so far we still have no basic type like numeric. I guess this would need to wait since non-fictional calendar are still not represented like Lunar Calendar, Japanese, Hebrew, etc. --Napoleon.tan (talk) 00:01, 19 June 2013 (UTC)

Automatic conversions are possible for the non-fictional calendars but not for some fictional calendars (though it is possible for others e.g. the Star trek calendar). --Filceolaire (talk) 00:36, 19 June 2013 (UTC)

Yeah, but that's my question. As far as I know is the Tolkien calendar convertible to a 'real' calendar like Gregorian. But I never heard a statement, if they will implement fictional calendar or not. If not, we could start searching alternative ways right now. Perhaps Lydia can check this up with the development team? And it's clear this would have really low priority, the question is just: Will convertible and/or not convertible calendars be implemented at all? --Nightwish62 (talk) 19:00, 19 June 2013 (UTC)

More calendar models can be implemented but are not on the list for the development team at this point. If someone wants to pick it up please let me know. --Lydia Pintscher (WMDE) (talk) 09:49, 20 June 2013 (UTC)

Misapplication of qualifiers

I fear this post will become long and be my second one this week which wouldn't give pleasure, however...

All started with my intend to add a 'voice actor' statement to some role. I didn't found any property, but I see the property was proposed already. As you can see in the discussion, there was uncertainty already how the statements should made. The first example wouldn't work, because there aren't 'sub-qualifiers' and as far as I know they aren't planned at all. So let's take a look to the second example:

   Statement Starring: Ali Larter
       Qualifier Role: Niki Sanders
       Qualifier Role: Tracey Strauss
   Statement Voice Actor: Tamura Maki
       Qualifier Language: Japanese Language
       Qualifier Role: Niki Sanders
       Qualifier Role: Tracey Strauss

In this example one actor has two roles. However, there could be other situations like:

• The actor was replaced be another actor
• The voice actor was replaced by another actor

Especially in long running series this wouldn't be a rare case. So we would need the 'start' and 'end' properties in addition. Again, since we don't have sub-qualifiers we would have repeat the 'base statement' multiple times with different qualifiers. Now, imagine the statement with changed actors and changed voice actors (not changed at the same time, so the time qualifier can't used for both together) and this for all dubbed languages. This would become really complex!

So I was already in bed when I was thinking about the problem, and then I realized, that the real problem is, that we've started using qualifiers wrong, e.g. the (pseudo)-qualifier 'role'. One sample: The Lord of the Rings: The Fellowship of the Ring (Q127367). As the word 'qualifiers' says, it should qualify the statement previously made. Let's see:

• <cast member> Elijah Wood --> this statement is true
• <cast member> Elijah Wood <role> Frodo Baggins --> this doesn't really qualify the statement, it even extend it

So the adding of the qualifier "<role> Frodo Baggins" doesn't change any in the relationship that Elijah Wood is a cast member. One example when an additional qualifier would be necessary is, when the cast member isn't seen in every edition of the movie. I didn't have a real example for this, but let's say actor XYZ is just seen in the directors cut, not in the normal version of the movie. So the statement should be: <cast member> XYZ <in> director cut,...or similar. Here, the adding of '<in> directors cut' really qualifies the statement previously made.

However, I think there are many qualifiers and their usage more, which doesn't really qualify a statement.

Back to the voice actor example. Considering the stuff above, this would mean, for a movie we have three top level properties cast member, role and voice actor, without any relationship within the statements itself. But as the role has the datatype 'item', e.g. Frodo Baggins has it's own item. So the Frodo Baggins item has also the cast member and the voice actor property, therefore a relationship can be made between all of them. At this moment no qualifiers was used yet, so it's free when the actor or the voice actor changes. This would solve problem. But the big drawback of this handling: It make no fun anymore to work within Wikidata directly. I don't have any 'table/list' where I can see all cast member and their related role. I would have to jump to the specific roles or query through all cast member / roles. The question is, if Wikidata should be a 'frontend' system, where 'users' directly browse around just for their pleasure, or it should just a backend system for Wikipedia, their sister projects and other external applications.

As for myself, I'd like to enter a movie name in Wikidata and have a list with cast member, roles, voice actors. Really. That's my motivation why I'm working on this project. But this should hide the fact that a.) we're using pseudo-qualifiers which aren't qualify anything b.) and therefore we have problems to make complex statements since we have just two 'levels' for statements (property and qualifiers) - see example above with changing actors, changing voice actors and language.

Feel free to comment. --Nightwish62 (talk) 01:09, 19 June 2013 (UTC)

I am not an expert in movie and/or series but I think voice actor isn't part of the original movie/serie and this can lead to a overloaded statement if you start to add all voice actors for each language. If you really want to add this information better adapt the translation concept used in book: create a new item for each "translated" movie/serie and add the voice actor without the main actor in the

Then for the roles where the actor is remplaced by another one, I think the best is to work like for book/editions: one item for the serie and one item for each season and you put the casting in the season items and not in the serie item. Usually the actor stays the same along the season and changes occur between seasons. Snipre (talk) 11:34, 19 June 2013 (UTC)

Thanks to your response. Did you have any example of the "translation concept used in book"? I'm not quite sure I understand you right, so I'd like to see a sample. However, this post is just to half about the voice actor problem,...I also wrote it because I'd like to know what other thinks about the usage of 'role' property as pseudo-qualifier. --Nightwish62 (talk) 19:06, 19 June 2013 (UTC)

See the guidelines proposed in Wikidata:Requests for comment/References and sources for books and editions. Snipre (talk) 12:16, 20 June 2013 (UTC)

Short update on URL datatype

Hey :)

I just bugged the developers for an update on the URL datatype. The hope is to have it deployed before Wikimania. And the plan is that this will be the next datatype to be deployed. --Lydia Pintscher (WMDE) (talk) 14:10, 19 June 2013 (UTC)

Free service for all non-hardcore wiki-fans, the event take place between 7. and 11. August 2013 :)

I also thought about enter the information to Wikidata, but I wasn't sure Q13375018 is the right one, since it links not to the normal article namespace? --Nightwish62 (talk) 19:16, 19 June 2013 (UTC)

In general, all of these project-space items need to be worked out. The current system makes no sense. -- Ypnypn (talk) 02:58, 20 June 2013 (UTC)

Well some of the scripts have taken to not automatically including the prefix in the labels, which is really annoying, since you almost always should include it, and makes everything more confusing. — PinkAmpers&^{(Je vous invite à me parler)} 03:13, 20 June 2013 (UTC)

8 more weeks till we can start entering web page sources. That is a bit disappointing.

How long till we can copypaste a source (or an entire statement) including all it's additional info (I've been told not to use the word 'qualifiers' for the additional info in sources). --Filceolaire (talk) 06:40, 20 June 2013 (UTC)

I can't tell, sorry. Some of that at least would have to be done by the community once URL datatype is available. --Lydia Pintscher (WMDE) (talk) 09:51, 20 June 2013 (UTC)

Question on how to use the P131 and P150

I would like to ask feedback on the uses of the P131 and P150. Was the intension of P150 and P131 really not to reciprocate? Please see the case below:

See my example for Japan (Q17)

   Japan (Q17) A                                        <-- an Admin Div?
       Tokyo (Q1490) B                       <-- an Admin Div
           Tokyo District (Q11524638) C                  <-- Not an Admin Div, a logical grouping only
               ward area of Tokyo (Q308891) D         <-- Not an Admin Div, a logical grouping only
                   Adachi-ku (Q213464) E                     <-- an Admin Div
                       Senju (Q11405341) F               <-- an Admin Div 
                   ...
               Western Tokyo (Q1323122)
                   Hachioji (Q208863)
                   ...
               Tokyo Islands (Q1138596)

1. A contains the administrative territorial entity (P150) B and B located in the administrative territorial entity (P131) A, assuming that A (instance of a country) is an administrative division

2. B contains the administrative territorial entity (P150) C but C located in the administrative territorial entity (P131) B is not true

3. C contains the administrative territorial entity (P150) D but D located in the administrative territorial entity (P131) C is not true

4. D contains the administrative territorial entity (P150) E and E located in the administrative territorial entity (P131) B

5. E contains the administrative territorial entity (P150) F and F located in the administrative territorial entity (P131) E and F located in the administrative territorial entity (P131) B

RFC1: For #2 and #3, they violates the reciprocity of the two property since C and D are subdivision but not administrative unit. But I was wondering if the P150 should really mean "subdivides into administrative division" instead of just "subdivide into anything"? I was thinking if we are not to limit the scope of P150 it can be very hard to use the data? I propose to limit the meaning of P150 to subdivide only to administrative division but this would cause list to grow for the parent node. What do you think guys?

RFC2: For #5 Since F is contained in both E and B, I would like to ask the community if they prefer to add the statement F located in the administrative territorial entity (P131) B even if this is implied with the statement F located in the administrative territorial entity (P131) E already? I think that F located in the administrative territorial entity (P131) B is not necessary. Does the community agree?

RFC3: For #1 can an instance of a country be considered an administrative division? There is some sort of unwritten rule where all geographical feature entity has country value, the administrative division of B's is redundant. Where B country (P17) A then B located in the administrative territorial entity (P131) A is redundant. Does the community agree?

--Napoleon.tan (talk) 17:27, 20 June 2013 (UTC)

But what difference between Admin Div and subdivision?--Ahonc (talk) 18:04, 20 June 2013 (UTC)

Let me clarify the label of the illustration. --Napoleon.tan (talk) 18:28, 20 June 2013 (UTC)

Worldbook

Hi, Recently I typed an older World fact book from Archive.org scans, and was wondering if anyone here had considered converting the World factbook to a format usable by Wikidata.

The World (fact)book, contains a huge amount of statistical data and it seems like that is something that should be in Wikidata. 80.176.129.180 11:33, 20 June 2013 (UTC)

This can be used as sources for statements but I think that for some data other sources can be more accurate: for some countries statistical data are provided by official organs with a better precision.  – The preceding unsigned comment was added by Snipre (talk • contribs).

That is an argument for marking the other source as preferred but I would still support having the CIA factbook data as well, especially if we can import it with a bot. Filceolaire (talk) 14:51, 20 June 2013 (UTC)

If you look at the data from the World fact book you will see that from a lot of countries there are estimations and not absolute values. That's why I prefer national data when there are available instead of a compilation of estimations done by a US agency. But I agree that for some cases when national data are not avaiélable or when there are suspicions about data quality, this is a good source. Conclusion: use it but avoid to import all data from it. 141.6.11.21 16:10, 20 June 2013 (UTC)

Estimations must be tagged as estimations yes, this is a good test case for the software to handle inconsistent sources but coordination with the development team is necessary. --FischX (talk) 23:54, 20 June 2013 (UTC)

"Deleted property" and "Deleted item"

Now all properties and items are showing "Deleted property" and "Deleted item", respectively. Anybody else see this? The Anonymouse (talk) 15:52, 20 June 2013 (UTC)

+1  — Felix Reimann (talk) 15:53, 20 June 2013 (UTC)

I was suppose to place this in the chat. me too but they are not deleted if you go to the property page directly --Napoleon.tan (talk) 15:57, 20 June 2013 (UTC)

Sorry folks. We just ran a script to rebuild a database table and that broke things. We're on it. Hopefully fixed soon. Sorry again! --Lydia Pintscher (WMDE) (talk) 15:59, 20 June 2013 (UTC)

Maybe someone wants to setup a sitenotice to this effect to warn users. Sorry! No data has been lost. --Denny Vrandečić (WMDE) (talk) 15:59, 20 June 2013 (UTC)

Done. Regards, — Moe Epsilon 16:08, 20 June 2013 (UTC)

Which also means we should be very careful with RfD at the moment. The best is just to not delete anything and to wait until things get in order.--Ymblanter (talk) 17:26, 20 June 2013 (UTC)

It is not fixed. All properties are marked as deleted, here. --Pyfisch (talk) 18:19, 20 June 2013 (UTC)

Update: The script is still running but more an more labels are in again. Things are getting better better \o/ Since I totally forgot to mention why we were doing this in the first place: It was to fix bugzilla:48506. --Lydia Pintscher (WMDE) (talk) 12:44, 21 June 2013 (UTC)

More than one interwiki per language ?

Would it be possible to allow the addition of more than one interwiki link in a given language? The only reason I see for not having this already is that the majority of Wikipedias have only one article per subject, but what if a Wikipedia allows to have more than one article for the same subject? Amqui (talk) 18:05, 11 June 2013 (UTC)

Huh? Why would they want to have more than one article about one subject? Are you thinking of any specific Wikipedia, or is the question purely hypothetical? Byrial (talk) 19:03, 11 June 2013 (UTC)

There are situations when different Wikipedias have differents sets of articles (many of the situations mention, e.g., here are of this category). But allowing more than one interwiki link will result in a mess. You talk about situations with one article - two articles. But there can be situations with two articles in one language correspond to three articles in another language (and one article in the third language). It would be simply unbearable. --Michgrig (talk) 19:27, 11 June 2013 (UTC)

The articles in different Wikipedias may have all variations of overlaping subjects, and that has been discussed numerous times. But that is different than one Wikipedia allowing two articles about the same subject. Byrial (talk) 19:40, 11 June 2013 (UTC)

I thought that 'no forking' is one of the basic rules in every Wikipedia. So I didn't even think about this possibility :) Am I not right? --Michgrig (talk) 19:47, 11 June 2013 (UTC)

I call this the Bonnie and Clyde (Q219937) problem. Some wikipedias have an article on Bonnie and Clyde while others have separate articles on Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). We have agreed that the devs will amend the software so we can link to redirect pages as well as linking to articles. This should, in most cases, solve this problem. Filceolaire (talk) 19:55, 11 June 2013 (UTC)

There is a property for this case, but some people want to delete it.JAn Dudík (talk) 20:09, 11 June 2013 (UTC)

It's reciprocal and therefore redundant, no information would be lost. —★PοωερZ_talk 20:25, 11 June 2013 (UTC)

The question isn't hypothetical. Some Wikipedias in small languages where the language isn't as codified as bigger languages like English may have the exact same subject in different dialects, or even only for languages that use different scripts, they may have the same subject written in each script. An example of that is w:cr:ᒥᒋᓯᐤ and w:cr:Mikisiw ka wapictikwanetc, both are about the bald eagle. Amqui (talk) 21:20, 12 June 2013 (UTC)

Also similar to the problem of Incubator. --MF-W 21:26, 12 June 2013 (UTC)

Maybe a solution would be to allow to use more than one "language name" per project. It would work for the Incubator problem as well as Wikipedias with more than one dialect or different scripts. We would use different "language names", but the interwiki links themselves would point to the same project. Using the above example, the interwiki table for "bald eagle" could contain "ᒥᒋᓯᐤ" for "Iyiyiw-Ayimuwin (syllabics)" and "Mikisiw ka wapictikwanetc" for "Atikamekw", but both would point to crwiki. It wasn't really doable with the previous way to handle interwikis, but with Wikidata I think it is implementable. Amqui (talk) 19:36, 13 June 2013 (UTC)

Note sure why this discussion has been archived since no solution had been found... Amqui (talk) 03:28, 21 June 2013 (UTC)

I can also think of the same subject with the article written for different publics (for example in math, article for mathematician and for public). TomT0m (talk) 09:28, 21 June 2013 (UTC)

An earlier discussion of the problem: Wikidata talk:Interwiki conflicts#Sibling_conflicts. --AVRS (talk) 10:02, 21 June 2013 (UTC)

To some degree links to language variants can solve this, but it would need further thoughts because it has some nasty implications. That is duplicate linkage can be difficult to avoid, and then all templates in the clients must handle multiple items. Which basically makes the complexity explode due to a fringe case. It is also possible to link to especially marked redirects, the Bonnie and Clyde problem, but to link to redirects in general would create a mess. Still note that the Bonnie and Clyde problem is not the same as the article fork due to language variants. To make some of the lookup work properly it is necessary to identify a single article on the client, and without a single unique title this will fail. And yes, it has been discussed several times in the past. Jeblad (talk) 10:25, 21 June 2013 (UTC)

How to use property where is qualifiers?

On the Finnish Wikipedia we have in fi:Suomi following code: [[]]. But we want that it shows only the current capital (Helsinki), not Turku, which is also on Q33. How it's possible to do this? --Stryn (talk) 10:38, 21 June 2013 (UTC)

There is no simple way to do that, but you could do it with Lua. You should import a to your wiki en:Module:PropertyLink, and then instead of [[{{#property:p36}}]] you could do {{#invoke:PropertyLink|property|p36}} (the link is added by the module. Eran (talk) 12:30, 21 June 2013 (UTC)

Thank you! --Stryn (talk) 13:04, 21 June 2013 (UTC)

redirect item

Is there currently any way to redirect and point one item at another? ·addshore· ^{talk to me!} 13:03, 21 June 2013 (UTC)

Heh! https://bugzilla.wikimedia.org/show_bug.cgi?id=38962 ! It would be great if we could get some more input on this! :) ·addshore· ^{talk to me!} 13:21, 21 June 2013 (UTC)

Error with property access

Q11596563: can't access properties from Wikipedia sections: {{#property:P377}} returns nothing (checked in preview ru, en). What's this? Ignatus (talk) 18:32, 21 June 2013 (UTC)

Result

Aah, read the red text on the top. Let's hope for the best. Closed. Ignatus (talk) 20:40, 21 June 2013 (UTC)

Site link already used by item

Finnish wikipedias Hamppu article has been linked to english wikipedias article Cannabis sativa when the corresponding article should be Hemp. en:Hemp is linked to fi:Hamppu. Wikidata has an item Q7150699 but it doesn't seem have as many language links as en:Hemp does. Is it the right item? I tried to add fi:Hamppu to Q7150699 but I got error "Site link Hamppu already used by item Q26726." Can site be linked only in one item in wikidata? If so then it's a quite a nuisance when different language wikis don't have uniformistically corresponding articles. en:Cannabis sativa could have link to fi:Hamppu but fi:Hamppu should be linked to en:Hemp. --Custoo (talk) 19:33, 21 June 2013 (UTC)

The lead section and infobox of the Finnish article are for the plant - "Hamppu (Cannabis sativa) on hamppukasvien (Cannabaceae)", where "hamppukasvien" is a link to the article corresponding to Q156338 - not just the industrial uses of it, so the current Wikidata link looks correct - or maybe Q79817 (Cannabis), unless a separate Finnish article is needed for that? Links have to be removed from one item before they can be added to another in Wikidata, and as far as I know it's possible to add links within an article so that more than one article can link to a page (which is how the fi.wikipedia and others appear in the en.wikipedia article), but not for one article to contain language links to multiple pages in one language. Peter James (talk) 22:25, 21 June 2013 (UTC)

Coordinates gadget

Hello, can maybe one of the JS programmers write a gadget which displays next to coordinate statements a link to OSM and maybe other online maps displaying this coordinate? --Pyfisch (talk) 18:13, 17 June 2013 (UTC)

It is currently being discussed in MediaWiki talk:Gadget-AuthorityControl.js. --Ricordisamoa 11:37, 22 June 2013 (UTC)

A page related to modelisation question in wikidata

A few question (by me among others) on this chat are related to modelisation. Project Chat moves to quickly to be a good place to be a reference on this question. We need something more organised : I propose to open a wikidata:Modelisation page for that matter to

• centralise modelisation discussion (from this chat, but also from discussion pages of properties, the information is a little bit of everywhere)
• start a FAQ and exemples (general and domain specific) to help newbies
• be a central points for best practice recipies

TomT0m (talk) 11:19, 19 June 2013 (UTC)

What is modelisation ? If I understand correctly better call that "Good statement practice" (GSP) but here we risk to concentrate hundreds of examples in one page leading to flood the FAQ. For some cases the property talk pages can be used, for others we need a better explanation especially when several properties are involved. Snipre (talk) 11:43, 19 June 2013 (UTC)

I refer to modelisation as the way as we express knowledge into statement into wikidata. When the page grow too large, we will split it into general stuffs and domain specific one. I think we at least need something similar to these freebase types pages to have a broader view than properties by properties to express something in wikidata. TomT0m (talk) 12:39, 19 June 2013 (UTC)

Before any discussion do you know if it is possible to structure properties in a statement ? better start the discussion with the development team to see the feasability and the mainparameters to handle and once you have that insurance we can start the discussion. But clearly here the key of this proposal is the implemention of a structure between the item level and the statement level. And small advice, use property structure or property hierarchy instead of modelisation. Snipre (talk) 15:39, 19 June 2013 (UTC)

I think it's an important thing to do at some point but I'm not sure we've reached that point. There's still quite a bit of creative experimentation going on, we're still creating new properties where we find them lacking and we don't even have all planned datatypes available. Pichpich (talk) 22:32, 19 June 2013 (UTC)

I'm not talking of a normative thing from the very beginning, just a page to be informed of what is going on on this matter and discuus it, it's not so easy to catch up right now. TomT0m (talk) 09:57, 20 June 2013 (UTC)

Then you should probably start that page and see where it goes for now. Like I said, it's clear that we'll need something of the sort eventually. Pichpich (talk) 18:33, 20 June 2013 (UTC)

First check if it's possible with the development team. Snipre (talk) 12:53, 20 June 2013 (UTC)

I don't need anything from development team (of course a technical way to regroup domain specific properties by domain could be usefull) but we just really need wikipages. I'll start something to clarify how I see thing, let's see if some other people follow me, we could still delete later it if it goes nowhere. TomT0m (talk) 18:51, 20 June 2013 (UTC)

 Done Just started with Wikidata:Help:Modeling, the page is quite empty for now, I'm too tired to continue just know :). Feel free to continue. TomT0m (talk) 19:17, 20 June 2013 (UTC)

I structured the page a little more and I linked some items to help to start the discussions. Still work in progress but still can be edited by others. TomT0m (talk) 14:40, 22 June 2013 (UTC)

Wiktionary planning

Heya folks,

We're making progress on the sisterproject front \o/ In addition to the implementation work to support sitelinks to Wikivoyage Denny just published a proposal for how to support Wiktionary in Wikidata in the future. Details are in this mail. Please keep discussions central on Wikidata talk:Wiktionary. --Lydia Pintscher (WMDE) (talk) 14:07, 19 June 2013 (UTC)

\o/ Wikivoyage should be easier to link than Wiktionary, IMHO. --Ricordisamoa 11:32, 22 June 2013 (UTC)

Descriptions-Gadget

Hi guys, I have just moved the descriptions script into the MediaWiki namespace (per [6]). In this recent discussion there was the idea to make it a default gadget, too. Now I would like to ask you to check if the whole community supports this idea, too. If so, I will make it a default gadget. Regards, -- Bene* ^t_a^l_k 18:59, 19 June 2013 (UTC)

•  Support --Tobias1984 (talk) 18:16, 20 June 2013 (UTC)
• Gadgets should not be made default unless operation of the site fails without the gadget being enabled. In this case I think the functionality (or a similar one) should be available in the extension, but the present solution is not important enough to be made default. Jeblad (talk) 10:34, 21 June 2013 (UTC)
•  Weak support per Jeblad. --Ricordisamoa 11:29, 22 June 2013 (UTC)

Book citations on Enwiki

Hi.

I'm not active here, but interested in the project once it gets closer to being 'usable' from other projects.

Specifically, I do a lot of 'isbn fixing' edits on enwiki, and I'm wondering if there is any guidance about how to prepare for the 'activation' of wikidata...specifically, is the 'generic' conversion of SBNs and ISBN-10s to ISBN-13s sufficient, or are there other steps I shoudl be taking? Would the conversion of book citations to the enwiki {{cite isbn}} be a desirable step?

I'm hoping (after some more learning on my part) to create a 'global' bot specifically to convert SBNs and ISBN-10s to the newer format.....knowing how wikidata is going to handle things would be useful information.

FYI, I'm mostly (almost completely) only active on enwiki at this point, so I might not see responses to this right away, though I'll try to remember to check in here...if I 'disappear', a poke there might be helpful after someone replies....it's the same 'unified login'...

(as a note, such 'bot' would be globally useful...ISBNs aren't 'language-dependent') Thanks. Revent (talk) 21:36, 21 June 2013 (UTC)

Hi, this I proposed something about the migrations of some en: templates here. Nothing has moved yet as there is still work to do but I still think it would be a good start. TomT0m (talk) 14:37, 22 June 2013 (UTC)

Yeah, tbh some of people's objections to cite isbn, etc, are kinda poorly thought out...for instance, the way it works you can 'override' fields from the 'template' by defining them in your 'call' to cite isbn in the article (to get the desired 'appearance'). WP /really/ needs a method for 'globally' getting correct bibliographic data for widely used references into articles, though...seeing the same 'source' in 10 or 20 related articles with uniquely mangled versions of the title, authors, etc., makes that really clear. The 'people don't watch them and there would be vandalism' argument is a bit spurious, as the exact same thing applies to /any/ template, and the people importing the biblio data would obviously be watching those pages. Using cite isbn could also 'globalize' such things as "there is a newer edition of this source available" comments, which would be a good thing.

My main concern with using cite isbn on a wider basis, to be honest, is simply my fear that people would 'mangle' the templates when attempting to get a desired appearance or page cite in a specific article, and 'break' the appearance of other articles... that's part of why I think having the 'bibliographic' data on WD would be a good solution (essentially, the part of the 'cite' that would be from somewhere like WorldCat) with the 'specifics' (page and such) on whichever WP. Revent (talk) 16:46, 22 June 2013 (UTC)

P107: are statistics on the use of each GND main type available?

What is the relative breakdown of P107 (P107) usage by GND main type? We know from database reports that GND main type is used in 3,295,134 claims, but how many claims assert 'GND main type: person', 'GND main type: term', etc.? Could someone involved with Wikidata analytics please determine this and let us know? Thanks, Emw (talk) 01:35, 22 June 2013 (UTC)

• Wikidata:Database reports/Constraint violations/P107#Values statistics — Ivan A. Krestinin (talk) 09:01, 22 June 2013 (UTC)

Perfect, thanks! Emw (talk) 10:21, 22 June 2013 (UTC)

I made a lot of statistics about P107 at User:Byrial/P107. Byrial (talk) 10:54, 22 June 2013 (UTC)

Merging two Wikidata items?

Hi, does anybody know how to merge Wikidata item Q910146 with Q7224883? They are both about an Asian festival called w:Qixi Festival, but somehow the English Wikipedia has two articles, one of which is specifically about the Vietnamese variant called w:Ngưu Lang Chức Nữ and the other is a more general article on the festival in many countries. Unfortunately, the Chinese, Japanese and Korean wikipedias are currently cross-linking to the English article that discusses the Vietnamese variant, instead of to the article that discusses the whole thing (which would make more sense for every language except Vietnamese to cross-link to). I wanted to update the cross-link on the Chinese Wikipedia 牛郎织女 article to point to w:Qixi Festival instead of w:Ngưu Lang Chức Nữ, but Wikidata said I can't do that because "Qixi Festival" is already used by another item. What's supposed to happen? does somebody have to delete all the cross-links and redo them? Silas S. Brown (talk) 11:13, 22 June 2013 (UTC)

You can report it to WD:IC. --Ricordisamoa 11:25, 22 June 2013 (UTC)

What you need to do is remove the interwiki link from the item which it is used on and then add it to the item which you want to put it on. See Help:Merge. The "Move" gadget should do the trick for you. --Izno (talk) 13:01, 22 June 2013 (UTC)

OK I moved the Interwikis not sure what the problem was.--Saehrimnir (talk) 13:12, 22 June 2013 (UTC)

Subclass or part-of ?

<mathematical logic (Q1166618)> was a subclass of (P279) if <mathematics (Q395)>. Imho it is a subfield which studies logics, not a class of logics whichs has instances as particular logics, so it should be a part of (P361) of maths. Am I right ? And if so, we probably need to be clearer about the part-of semantics. TomT0m (talk) 15:53, 18 June 2013 (UTC)

I wouldn't have used subclass of (P279) in this case but rather part of (P361). I think it's a better option but one could argue that it's still unsatisfactory. Do we want a ""subfield of" property? Pichpich (talk) 17:29, 18 June 2013 (UTC)

Similarly I'm not sure that mathematics (Q395) are subclass of science (Q336) (the labels in french of english are respectively science is a set of knowlegde (facts) and study and knowledge of the universe, and the answer might be different if we choose the former and the latter :) ) Anyway I do not know what would be an instance of science if it is not maths or physics. Science experiments might be part of science, scientific theories might be either. But if we choose a science as a set of scientific theories and physics as well, then physics is indeed a subclass of science. But a science is more than that. TomT0m (talk) 17:48, 18 June 2013 (UTC)

Anyway these questions are probably classical in ontologies science, where could we find existing ontologies that solves theses questions and source those statements ?

E.g. http://opencyc.org, http://umbel.org/. --4th-otaku (talk) 11:28, 23 June 2013 (UTC)

X!'s Edit Counter

(Sorry for writing in English. You can translate the proposal.)

Should X!'s edit counter retain the opt-in requirement? Your input is strongly encouraged. Voice your input here.——cyberpower ^Chat_Automation 05:10, 23 June 2013 (UTC)

Distributed via Global message delivery. (Wrong page? Fix here.)

Need help for querying

I'd like to get a list of all items, which uses a specific property, no matter which value it has. What to do to reach this goal? --77.239.41.207 15:42, 23 June 2013 (UTC)

• Special:WhatLinksHere/Property:P<XX>--GZWDer (talk) 15:51, 23 June 2013 (UTC)

Social media properties

For individuals, and perhaps for organisations and other entities, it seems sensible to have properties for their social media presence; their Twitter or Facebook profiles or (in the latter case, pages, Google+ accounts, etc.

Should these be very granular:

• Property: Twitter ID
• Property: Facebook profile
• Property: Facebook page

or should we use a more generic property whose value is a full URL:

• Property: Social media presence

or even a very generic URL property, and expect users to parse the URL in the value to determine the host and type of presence? If the former, which services should we start with?

[I have searched for previous discussion; apologies if I've missed anything.] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 21 June 2013 (UTC)

Some of them were may be proposed earlier. Don't know the out come if any.--Vyom25 (talk) 16:57, 21 June 2013 (UTC)

And what value will this information have when these buisnesses are no longer functioning? None.

Quite apart from the value that they currently have, and will have for the foreseeable future, when such businesses are functioning; plenty. Public content on such services is being archived by the US National Archives and others, and may at some point be made available to be queried. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:12, 24 June 2013 (UTC)

Hi Andy, website account on (P553) and website username or ID (P554) are probably what you're looking for. Tim Berners-Lee (Q80) has an example usage. Emw (talk) 10:27, 22 June 2013 (UTC)

Thank you.

Go (verb) and generalisation of the problem

What to do with go (Q5574688) ? Is it about the english verb "to go" or about the notion of going somewhere ? It makes a big difference, for example for the label in other language. Should I label "to go" in french or "aller"? Actually both could make sense as we can have an article in french wikipedia about the english verb ... TomT0m (talk) 19:23, 23 June 2013 (UTC)

My take is that this item is about an English verb and not about a verb. So the French label should be "to go" or "go" and the description should be "verbe anglais". Pichpich (talk) 19:28, 23 June 2013 (UTC)

I did not really checked the proposed future model for wiktionnary and wikidata, but I guess it will clarify such issues. Actually I might ask this question on project chat to have an answer. TomT0m (talk) 19:37, 23 June 2013 (UTC)

 Done asked on questions to developpers. TomT0m (talk)

Viveros de Coyoacán

Hi everyone,

if someone has better technical wiki-experience than I do, please link the Viveros de Coyoacán of DE, EN and No with Viveros de Coyoacán of ES, FR and NL. Thank you very much in advance and best regards,

Chivista (talk) 17:40, 24 June 2013 (UTC)

 Done. --Stryn (talk) 17:56, 24 June 2013 (UTC)

When should we use point coordinates ?

We hopefully are about to get a working datatype for point coordinates (see above). Later on, we will get a geoshape datatype, so that we can add not just one coordinate point for an object, but a detailed specification of its boundaries. We do not know yet when it will be implemented, I presume it is a matter of months. In the mean time, we should decide in which case using the point-coordinate datatype is acceptable :

for single points, like the North Pole, or the highest point of a mountain ?

•  Support of course -Zolo (talk) 15:44, 11 June 2013 (UTC)
•  Support Ajraddatz (Talk) 15:50, 11 June 2013 (UTC)
•  Support Filceolaire (talk) 20:00, 11 June 2013 (UTC)
•  Support can't make a polygon out of a mathematical point --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
•  Support clearly. Sven Manguard Wha? 22:26, 12 June 2013 (UTC)
•  Support pretty much by definition -- The Anome (talk) 09:25, 13 June 2013 (UTC)
•  Support yes... :) ·addshore· ^{talk to me!} 23:10, 25 June 2013 (UTC)

for small objects, like a statue or a famous tree ?

•  Comment how small ? -Zolo (talk) 15:44, 11 June 2013 (UTC)
• I'd be OK with this, with the "how small" question being answered by common sense until an issue comes up with it. It's hard to predict what those issues will be (for me anyway), so we could deal with that at a later time. Ajraddatz (Talk) 15:50, 11 June 2013 (UTC)
•  Support unless the object has a notable shape it should be a point. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
•  Support clearly. Realistically a point works perfectly well for a building; if you drop the point right in the middle of a building, or even in its front yard, we're all going to know what is being pointed to, and I'd still consider it perfectly accurate. Sven Manguard Wha? 22:28, 12 June 2013 (UTC)
•  Support Definitely. The easiest definition would be anything that is unshapable and/or the shape of which would be of little interest. Alexander Doria (talk) 22:37, 12 June 2013 (UTC)
•  Support as per Alexander Doria and Sven Manguard -- The Anome (talk) 09:25, 13 June 2013 (UTC)
•  Support ·addshore· ^{talk to me!} 23:10, 25 June 2013 (UTC)

for large objects like Berlin or the Atlantic Ocean ?

•  Comment we have this in Wikipedia, but geoshapes may make it obsolete. --Zolo (talk) 15:46, 11 June 2013 (UTC)
•  Comment, I think it has some uses, like creating a Wikidata layer in map services, but we should have clear rules on how we choose the point (the object center of gravity, or whatever). --Zolo (talk) 15:44, 11 June 2013 (UTC)

• Depends on how you would like to describe "Berlin". Is it a set of real estates within a geographic area or an administrative unit with an office located somewhere? The second case can give strange results since the administrative center can be located outside the geographic area. -- Lavallen (block) 16:00, 11 June 2013 (UTC)

• I guess it would be something like the territory over which the mayor of Berlin has authority or this sort of thing. Sure, if we use just one point for coordinates, it cannot always be the center (it would look funny for ring roads ;). --Zolo (talk) 08:41, 13 June 2013 (UTC)

• I make some calculations and get that distance between two degree seconds is ~31 metres (40000/360/60/60, where 40000 is Equator length) and between two degree minutes is 1,8 km. So, for cities and big villages we may add only degree and minute without seconds.--Ahonc (talk) 20:47, 11 June 2013 (UTC)
• I think this should be discusses with Wikipedia:WikiProject Geographical coordinates (Q10948883). A task force and guidelines are needed. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)

• I have left messages at the English and French project pages. --Zolo (talk) 08:41, 13 June 2013 (UTC)

• ,Although accurate shapes should always be preferred if possible, I think this makes some sense for even features a few hundred km across, provided an approximate feature size can be provided. Something as big as an ocean or a large country is far too big -- but there are very few features on this sort of scale, and providing shapes for each one is quite feasible in the near term -- The Anome (talk) 09:25, 13 June 2013 (UTC)

I would point out that some cities have well-known "location points", such as the Zero Milestone in Washington, DC. And for many other purposes airport coordinates seem to do pretty well. StevenJ81 (talk) 22:11, 21 June 2013 (UTC)

For everything we have coordinates right now.

• So also for country, we can just have both. In some cases you just want the point and in other cases the shape. Multichill (talk) 19:53, 11 June 2013 (UTC)

•  Support. How small to be decided on a case by case basis. I would encourage point coordinates wherever we don't have shape info. If we get shape info later we can update. Filceolaire (talk) 20:00, 11 June 2013 (UTC)
•  Support Per Multichill and Filceolaire. We can refine later with shapes or whatever will come. Raymond (talk) 20:30, 11 June 2013 (UTC)
• Something to think about: After we get the geoshape datatype are we going to be duplicating the entire OpenStreetMap project here? --Yair rand (talk) 21:10, 11 June 2013 (UTC)

• There is not much overlap. Openstreetmap is about navigation and the current network of streets and buildings. Wikidata on the other hand could have historical maps (Roman empire) or geologic information (extent of the San Andreas Fault). In my opinion Wikidata is the ground work for Wikipedias own spatial information project. --Tobias1984 (talk) 09:18, 12 June 2013 (UTC)

• Yes, and the overlap does not extend too well the other way around : numerous practical informations of OSM are probably not sufficiently encyclopedic to be included on Wikidata (shops, supermaket, post office, phone booth…). Alexander Doria (talk) 23:35, 12 June 2013 (UTC)

•  Oppose shapefiles are better at representing linear or polygon objects. We already have a lot of shapefiles here: w:en:Template:Attached KML. --Rschen7754 21:22, 11 June 2013 (UTC)
•  Support On Wikipedia this works well for now. I guess shape forms will be harder to create anyway. HenkvD (talk) 21:36, 11 June 2013 (UTC)
•  Oppose Simply because it is not correct and wrong data, we need shapes, it is easy to import from OSM, UN ect. it is useful to check Items (is in) lets do things right. --FischX (talk) 22:48, 11 June 2013 (UTC)
•  Support - Work with what we got. --Tobias1984 (talk) 22:03, 12 June 2013 (UTC)
•  Support Indicating the global position of a country/region is still better than nothing. For instance, I'm working on ancient greek administrative subdivision. Nobody can know their shape for sure — if they even had a definite shape, as during the antiquity, borders were seldom clearly determined. Yet, their general location remains an interesting data. Alexander Doria (talk) 22:42, 12 June 2013 (UTC)

• We could allow for polygons with a margin of error for the outlines. What would you say is the uncertainty for ancient Greek borders? Even borders today have a margin of error as seen in numerous territorial disputes. I hope the polygons will allow us to capture that kind of complexity. --Tobias1984 (talk) 22:53, 12 June 2013 (UTC)

• It depends on the geographical features. Some ancient athenian demes are sufficiently known to be drawn with a good deal of margin of error. For many others, we only have the vague notion that it's in the whereabouts of some location (for instance, thanks to some set of epigraphic mentions). So that we cannot draw anything. Alexander Doria (talk) 23:31, 12 June 2013 (UTC)

•  Support It is anyway a useful information. --Paperoastro (talk) 10:19, 13 June 2013 (UTC)

 Oppose On Wikipedia we do this because there's no other option, but I don't think we should rush to fill in Wikidata with misleading data that will have to be fixed later. At the very least, I would prefer some kind of annotation or scale for points that don't represent an object at the specific point. That way a machine consumer of the the data can know that there is not actually an object at the specific point, e.g. that "Greece" is not located on a specific city block. --Delirium (talk) 14:20, 13 June 2013 (UTC)

•  Support --Kolossos (talk) 16:41, 18 June 2013 (UTC)
•  Support Go ahead with what we've got. Geoshapes can be added later. Most applications that use geographical data from Wikidata is not able to handle any other type than single point coordinates anyway. /Esquilo (talk) 10:55, 20 June 2013 (UTC)
•  Oppose, large areas and linear objects cannot be adequately handled by points. This example is a good illustration of why; it represents a highway that is several hundred miles long with one coordinate at its midpoint. Can you pick out which highway it is, and its entire extent, from just the one coordinate? At best, using one point for such a large object is useless, at worst it's misleading. There is no reason to resort to using a single point when we have things like KML that are able to handle features like this much more effectively. —Scott5114↗ [EXACT CHANGE ONLY] 03:14, 24 June 2013 (UTC)
•  Oppose - Why wouldn't we just use the KML technology we already have? TCN7JM 05:14, 24 June 2013 (UTC)
•  Weak oppose as with the above, this isn't the right way to do it, so lets not keep doing it! Shapes are the way forward! ·addshore· ^{talk to me!} 23:11, 25 June 2013 (UTC)

Comment

When using coordinates for point we can (should?) mention by qualifier which point it is. For example: coordinate of Moscow - qualifier point - Kremlin. --Infovarius (talk) 12:07, 20 June 2013 (UTC)

And the qualifier point for Kremlin would be...what? /Esquilo (talk) 12:39, 20 June 2013 (UTC)

Search and diacritics

The autocompletion lists when adding statements (and the autocompletion in the search) are diacritic sensitive in the sense that typing "Jose Mourinho" will leave the impression that there's no item on José Mourinho (of course, there is one). In a multilingual project, it might be useful to have a diacritic-insensitive search but I'm not sure how complicated this could be. Otherwise, would people feel comfortable with bots systematically adding aliases for the diacritic-free approximation of item labels? Pichpich (talk) 18:57, 19 June 2013 (UTC)

•  Support bots adding diacritic free aliases. --Filceolaire (talk) 06:11, 20 June 2013 (UTC)
•  Comment some technical info on this: For the insensitive search and autocompletion to work we need to have Solr working. This is bugzilla:45158. We want to work on this but it'll not happen very soon as datatypes and ranks have priority. We're talking about 3 months probably. --Lydia Pintscher (WMDE) (talk) 10:04, 20 June 2013 (UTC)
•  Comment This should be a rather simple fix as the actual table has a column for normalized text strings. This is used during searches to avoid the upper-/lowercase problem. The same column could strip diacritics, possibly also some other stuff. It is probably nothing more than a one-liner when generating the column data, but it will also be necessary with a one-liner in the search algorithm. Only real problem I can see is that it would be necessary to regenerate the table (I think there is already a script for this) and that some searches would return more hits than the user expect, and that is already a problem. Jeblad (talk) 10:44, 21 June 2013 (UTC)
  • But only if we put there *only* the simplified string version, and also simplify the search accordingly. This means, that a search for "Wört" would return everything that is "Wort" and make it harder to find the actual "Wört". Again, in my understanding, Solr would fix that, and I would like to ask for patience. --Denny Vrandečić (WMDE) (talk) 10:56, 21 June 2013 (UTC)
• I'm not convinced we should make any element of editing diacritic-insensitive. Any aspect of editing should be precise. Deryck Chan (talk) 23:32, 25 June 2013 (UTC)

minimizing Item's UI

minimizing the free space

In my opinion the statement part has much empty space and it should be minimize like this image. for example see Q30 we should scroll many page to langlinks!Yamaha5 (talk) 10:47, 23 June 2013 (UTC)

 Strong support – is it an actual CSS customization or simply a mockup? --Ricordisamoa 10:59, 23 June 2013 (UTC)

 Support - Looks great! :) ·addshore· ^{talk to me!} 11:25, 23 June 2013 (UTC)

 Strong support - I've been wondering about something like this for a while. This looks nice! TCN7JM 12:17, 23 June 2013 (UTC)

 Support, looks better than the current one. --Stryn (talk) 12:28, 23 June 2013 (UTC)

 Comment I think before we change anything now, we should also consider where the UI for the ranking would be placed. Are there any ideas right now already? --Nightwish62 (talk) 15:10, 23 June 2013 (UTC)

+1. Better work on the final format of the UI including all elements. Snipre (talk) 22:03, 23 June 2013 (UTC)

 Support --Paperoastro (talk) 08:19, 24 June 2013 (UTC)

 Support Some pages are likely to contain a lot of data. A minimized presentation would definitely ease consultation. Alexander Doria (talk) 09:44, 24 June 2013 (UTC)

 Comment I fully agree with the intent of this idea. We want to first make the system a bit more feature-complete -- add the missing datatypes, add ranks, add sorting -- before we make a redesign of the UI. Until then, input like these is very welcome.

On the other hand - it is an Open Source project, and if you think this needs to be tackled earlier, feel free to have a try with it :) --Denny (talk) 10:11, 24 June 2013 (UTC)

 Support - دوستدار ایران بزرگ (talk) 11:05, 24 June 2013 (UTC)

 Support - Plus, it would be nice if that whole section would be collapsible, possibly allowing my to define somewhere/somehow whether I want to have it collapsed by default. Often I'm only interested in the labels/descriptions and the sitelinks, but have to scroll down a long way due to the statements. --YMS (talk) 11:46, 25 June 2013 (UTC)

 Question As asked above, is this CSS and styling already working? Are there some files we can look at or at this stage is it just a mockup? ·addshore· ^{talk to me!} 22:55, 25 June 2013 (UTC)

Proposal for Wikimedia Commons

Hey :)

We've just published a proposal for supporting Commons with structured date. We'd love input and comments on it. Please use the talk page of the proposal so we can keep this all in one place. Thanks! --Lydia Pintscher (WMDE) (talk) 12:50, 25 June 2013 (UTC)

Wikidata has a guideline for sourcing

Just to inform you that the RfC about references and sources is closed. Right now the guidelines is available in Help:Sources. There are still some open questions and you are kindly invited to comment your experience or problems you got when sourcing a statement.

It is really important to follow the guidelines or to ask for change if you see a problem because these guidelines will be the structure used to extract source data later in wikipedia.

For the persons who have some difficulties with the present guidelines there is some possibility to change the guidelines but they have to start quickly a new round of discussions. I strongly recommand to read carfully the previous discussions because most of the arguments were already discussed and a new discussion can be successful only if new concepts are proposed.

Finally translators are welcome to translate the new text of Help:Sources Snipre (talk) 17:30, 25 June 2013 (UTC)

It would be helpful to add good examples. --Succu (talk) 17:42, 25 June 2013 (UTC)

Continuation of the RfC: On Source items and supporting Wikipedia sources

I have opened a new RfC to address that were brought up during the discussion of the old RfC on sources. The new discussion is here: Source items and supporting Wikipedia sources. As for the "Guidelines for sourcing statements", Legoktm considers that it has to be left open just in case there are more comments before moving them to Help:Sources. --Micru (talk) 23:06, 25 June 2013 (UTC)

Inconsistencies between the Wikidata UI and the API?

Hi, I've been experimenting with the Wikidata API for a research project lately, and have a couple of questions:

1. The langlinks section in the Wikidata UI only lists proper articles, not redirects: e.g., for David Fernández Ortiz it lists 8 languages, matching the langlinks sidebar on Wikipedia. However, when I query for this article through the API I get about 30 languages. Apparently some of those are redirects. Is there a way to NOT get redirects in return when using the API?
2. The langlinks section also lists the full article name for each item. The result returned by API queries, however, seem to omit text parentheses. For example, the UI page for Q3534639 correctly states the name of the respective article on the English Wikipedia as Napoleon (actor) (stage name of Kumaresan Duraisamy), but the API query returns the English name as "Napoleon" only, a name which obviously directs to the Wikipedia article about the French emperor. This is a major problem as the article name is the only edition-specific unique identifier used by Wikidata and is the only way to map from an Entity ID (Qxxxx...) to an article in a specific language. Is there a workaround for this issue? Claudius972 (talk) 21:54, 25 June 2013 (UTC)

You are querying the wrong data, you have to use prop=sitelinks to get sitelinks (eg. [7]). What you're currently requesting are labels which are only supposed to be a human readable title for the item, not necessary directly related to page titles - Hoo man (talk) 22:03, 25 June 2013 (UTC)

(edit conflict) Basically saying the same. I can swiftly poke you in the right direction from your first query regarding the API. Take a look at this link which uses props=sitelinks instead of props=labels! To see the whole contents of the item remove the props all together! Your link isn't actually looking at the sitelinks from the API instead the labels in various languages for the item! ·addshore· ^{talk to me!} 22:05, 25 June 2013 (UTC)

Thanks for the quick reply guys, this is really helpful! Claudius972 (talk) 00:45, 26 June 2013 (UTC)

Error

I encounter following error while trying to change Cerbera manghas from Bintaro to Pokok Bentan. Error Site link Pokok Bentan already used by item Q12700762. Return to Cerbera manghas (Q714955). Yosri (talk) 00:15, 26 June 2013 (UTC)

 Done, and I deleted the empty item after the merge. TCN7JM 00:19, 26 June 2013 (UTC)

Prevent Wikidata from removing iws without telling the user

A few days ago I found out that I had unknowingly orphaned quite a few Wikidata items by removing interwiki links without even knowing it (they have all been merged and deleted now). If there's two WD items, each with just one iw, the software will automatically remove the iw from one of the items and add it to the other without telling the user.

Here is an example: sv:Seymour Österwall was linked with Q6257978 and en:Seymour Österwall with Q7459247. I used the "Add links" link from the enwp article and added the svwp article. The software "Added link to enwiki: Seymour_Österwall" and "Removed link to enwiki" from the other item. Since only two iws were involved, the software did not warn about any iw conflict (because there was none), but it should had given a warning such as "Error: This interwiki link is already linked to another item." jonkerz ♠talk 21:04, 25 June 2013 (UTC)

My main idea behind doing it in the way it is done was to leave the client interface (the dialog you used) as simple as possible to not confuse any users (linking to an external site already is confusing for many users). Due to this I've decided that it's bearable to let it just blank out items as we have working bots which will requests these items to be deleted automatically without the user having to worry. By the time we have a way to really merge items (or item redirects) I will of course switch the widget to use these, but for now I think this is the best user experience we can provide and I don't really see a problem in just blanking these items. - Hoo man (talk) 21:26, 25 June 2013 (UTC)

Most of the time it is no problem at all to leave an item with no links behind. If they are not found by bots, I find the empty and unused items every 2-3 weeks from the database dumps and make very large bulk requests for deletion of literally thousands of items. However there is a problem if the orphaned items have statements or are used as values in statements in other items, or to a lesser degree if they have labels, descriptions or aliases which are not moved, so a proper merge would be preferable. I suppose that the risk of lost statements will increase over time as the number of statements and properties grow. Byrial (talk) 22:04, 25 June 2013 (UTC)

Yes, that's a (probably increasingly big) problem, but you have to keep in mind that this only concerns items with one sitelink. Those typically don't have much data attached while they're often merged into items with multiple sitelinks which probably already have way more data attached to them. - Hoo man (talk) 22:13, 25 June 2013 (UTC)

I see where you're coming from; Wikidata is complicated as it is, and making it harder to edit probably hurts the project in the long run.

I'd be ok with blank items too, but most items are not 100% blanked. The above example only left one label behind, but I unknowingly left three claims behind on Q7227218 (now merged with Q2843793) and then orphaned the item. I discovered it 12 days later and merged them, but if it would have gone unnoticed for a few more weeks, other editors would probably had started to expand the "new" item, duplicating work already done on the orphan. Would keeping the functionality as is, but adding a feature that linked both items on a central page like Wikidata:Items to be merged be feasible? Something like "==25 June== *Q7459247 → Q6257978" where experienced users could merge the items and nominate for deletion. jonkerz ♠talk 22:17, 25 June 2013 (UTC)

@Byrial: Would your bot be able to find Q7227218? It had claims and labels, but no iws. I mean, items without iws must be allowed on WD? jonkerz ♠talk 22:22, 25 June 2013 (UTC)

Items without sitelinks can indeed exist on wikidata. See Wikidata:N ·addshore· ^{talk to me!} 22:43, 25 June 2013 (UTC)

I could have found it if I had looked for items with no page links, no links from other items, but having statements which is an unusual combination which may call for investigation. But until now I have only looked for items with no page links, no links from other items and no statements, and would not have found it. But even if I change what to look after, I could not have found it if another item had linked to it (that could for instance be a Pomaria species claiming Pomaria as it's genus) because then there would be nothing extraordinary to notice. (Except that at least taxon rank (P105) and taxon name (P225) can also be expected when P70 (P70) and P71 (P71) is used but that is another matter). And for the record: I do not at present use a bot at Wikidata, instead I download and analyze database dumps. Byrial (talk) 23:22, 25 June 2013 (UTC)

That is quite useful and makes it possible to find items that have been blanked/orphaned/duplicated for other reasons not related to the above, but it seems like a waste of time to not log obvious dupes. I noticed the section #How do I go about merging two classes? above and it is just one of many examples of how hard it is to solve iw conflicts. I've added my support for a central page in that section, and with a central page I assume it would be easier to add a log feature. The move could even be logged from the user's account without telling the user since it's kind of a temporary fix. An alternative would be to add a one-click "Request merger" popup. jonkerz ♠talk 23:56, 25 June 2013 (UTC)

@User:Hoo man but could the Widged not use the merge.js now that it is available and thus directly request the delete?--Saehrimnir (talk) 13:34, 26 June 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Sadly this can't be done, for several reasons: First of all it probably wont work from the client wikis as it doesn't use our API abstraction. Furthermore it is Wikidata specific and doesn't belong into the Wikibase extension due to this (nor should the extension know about its existence). On top of these issues we can hardly guarantee for it to be secure and working correctly. - Hoo man (talk) 15:33, 26 June 2013 (UTC)

New batch of book/artwork-related properties for discussion

New batch of books/artwork-related properties for discussion

• main topic of creative work
• collaborator
• Europeana identifier
• DPLA identifier
• Internet Archive identifier
• Google Books identifier

Your comments are always appreciated.--Micru (talk) 14:53, 26 June 2013 (UTC)

Problem in merging

Dear all, Can someone tell me what is the problem in merging a page with another. From last few days I am trying to merge things and it is working almost but at the end it shows an error (error http). So please help me to fix the problem and I would like to know whether this problem is only with me?--☆★Sanjeev Kumar (talk) 16:48, 23 June 2013 (UTC)

You should post it at MediaWiki talk:Gadget-Merge.js for quicker reply by the developers of the tool.--Vyom25 (talk) 20:32, 23 June 2013 (UTC)

Thanks Vyom. I have kept my question as you suggested.--☆★Sanjeev Kumar (talk) 20:42, 26 June 2013 (UTC)

content topic index for items

in my opnion it will much better to have an index (for 1-properties and 2-langlinks) for items.for example for Q797826 the index could be:

1. statments
   1. main type (GND)
   2. instance of
   3. director
   4. cast member
   5. imdb identifier
2. language links

it helps users to find sections in a fast way Yamaha5 (talk) 17:01, 25 June 2013 (UTC)

Do you mean that we should make a new section for each entity? —دوستدار ایران بزرگ (talk) 19:55, 25 June 2013 (UTC)

no. for each property not each entry.Yamaha5 (talk) 08:05, 27 June 2013 (UTC)

subtemplate

Why should subtemplates be excluded? By the way, EdinBot creates many items for subtemplates.--GZWDer (talk) 05:32, 26 June 2013 (UTC)

I have left a message on Edinwikis talk page about this section. Indeed WD:N says no sub template so the bot should probably stop! I have looked over the 3 RFCs we have had for WD:N and I can not actually find anything specifying what should be done with sub templates but perhaps I am missing something! ·addshore· ^{talk to me!} 09:31, 26 June 2013 (UTC)

I'm sorry about this. I was previously not aware of the exclusion of subtemplates specifically. However, the job is already done. What is the best way to fix this? I would gladly fix this myself, but I have obviously not enough rights to do delete these items so I'm afraid someone else will have to. I suggest an adminbot sweeps all these items, based on this category (if that is the policy). I also just want to note that (most?) of the items were already created. See for example Q7655767. In those cases just another link was added. -- Edinwiki (talk) 09:43, 26 June 2013 (UTC)

What sort of sub templates has your bot been creating items for? I am rather interested as as far as I can see there is nothing in the RFCs that specifically says sub templates can not be included (I imagine this has come from a more general sub pages should not be included). ·addshore· ^{talk to me!} 22:54, 26 June 2013 (UTC)

An aside from the link below, yes, there is support for the general notion at least among the admins that we should be avoiding subpages in the "maintenance" space of the pedias. --Izno (talk) 23:45, 26 June 2013 (UTC)

There was support for deletion of subtemplates in Wikidata:Project chat/Archive/2013/04#Notability of items. --Izno (talk) 23:35, 26 June 2013 (UTC)

@addshore: The subtemplates are part of the conversion template Convert. The creation/linking was based on subtemplates in this category. -- Edinwiki (talk) 10:38, 27 June 2013 (UTC)

Ambiguous items and articles

Items about regency (Q173843) (and another related Regent (Q341699)) are ambiguous, they kinf of both speak of a regency and the regent as a person or as a group. The second item is a disambiguation item whose status is kind of weird in the french Wikipedia. I wonder how to solve this problem. Would this require to modify the structure of the Wikipedias themselves ? Users could not like that ... TomT0m (talk) 20:07, 26 June 2013 (UTC)

Doesn't seem to be a problem to me. Both the frwp article and the first item refer to the rule of a monarchy by someone other than the monarch, and the second is a disambiguation of what the word "regent" could mean. The only issue is that the frwp article on the first item is more a list of past regencies than those of other wikipedias, but still has the same scope.

You are right though in that some items do have problems like what you see here (though I disagree that a problem exists in this case). I think that, as time passes and people get more used to Wikidata, Wikipedia editors might be more inclined to match the content of articles in different languages. For now, though, we can't force any Wikipedia to modify their articles to fit in with the "global standard". All we can do is try to get each article linked on the closest possible item. Ajraddatz (Talk) 22:26, 26 June 2013 (UTC)

I disagree, this is a complete mess. See regent (Q477406) linked as I write these lines to https://en.wikipedia.org/wiki/Regent and to imperial regent in frwiki (I won't move things now for this discussion). TomT0m (talk) 09:04, 27 June 2013 (UTC)

Bots problem with auto login

some times when bot wants to login automatically it shows token error but if we login with SSl connection it doesn't have this problem!Yamaha5 (talk) 08:11, 27 June 2013 (UTC)

Items with no ...

There is bots that lists items with no label or description, I think next step would be to list item which are not subclass or instance of something. Should any of the bot owner starts encouraging to fill these properties ? TomT0m (talk) 09:39, 26 June 2013 (UTC)

I think the best person for this would be @Byrial: who seems to be working magic with the dumps creating many great lists! ·addshore· ^{talk to me!} 10:38, 26 June 2013 (UTC)

Well, as you can see at my statement statistics page most of the items have no statements at all. I agree that bots which add statements should also add instance of (P31) or subclass of (P279) when the kind of item is known, but I see no point in making a list with over 8 millions items. Smaller lists with more criterias than just no instance of (P31) or subclass of (P279) might be useful for people who want to add statements, and I am open for suggestions. Byrial (talk) 20:11, 26 June 2013 (UTC)

Ok this is indeed a lot. Maybe a choice to rank items would be to search items with a lot of views on Wikipedia which remains unclassified or unlabeled, this could be helping and a motivation, there is no point into labelling the loads of football clubs, this definitely should be done by bots, so we must find ways to extract items that are difficult to be done just by a bot, it could be one of them (wild guess, maybe popular items are already well formated so it is easy to extract information automatically). TomT0m (talk) 20:21, 26 June 2013 (UTC)

It's true that a huge part of this can be done by bots but in some cases, we have to decide what we want bots to add exactly. This (I'm sure Tom will be happy to hear!) is the sort of issue we want to resolve at Help:Modeling. Once we have cleared up these issues and designed bots to add all the straightforward stuff, these lists will start being useful. Until then, not so much I think. Pichpich (talk) 21:41, 26 June 2013 (UTC)

Yep, it's clear that it is an important step for working with bots. Initial classification seems although a little different, it is important to know what an item IS before we know which kind of data and model we could expect to have (this is why it is one of the next priorities to me) TomT0m (talk) 10:58, 27 June 2013 (UTC)

@Byrial: While we are at it, I have a suggestion to priorize descriptions, we should have in top of the list ambiguous items, that is item which we cannot differentiate by label. And the more similar label there is, the more on top of the list it should be ... Having 15 similar items when you type something do not help to find the right one :) TomT0m (talk) 10:58, 27 June 2013 (UTC)

That sounds reasonable. I will start working on a list of the items with most identical labels and no descriptions for each language. Byrial (talk) 00:47, 28 June 2013 (UTC)

Isn't this exactly what Magnus' Terminator does? It's a straightforward tool but it's really useful. It's also slightly depressing if you stop to consider the numbers. Pichpich (talk) 06:34, 28 June 2013 (UTC)

Sure, I forgot about that. I will not do this as it is already done (at least for 6 languages – I suppose more can be added at request). I do not understand the remark about a stop to consider numbers. What numbers do I not consider? Byrial (talk) 08:17, 28 June 2013 (UTC)

I think you misunderstood the last sentence. I'm just saying that the statistics given by Terminator are a little discouraging because they show that there are over a thousand labels with at least ten items to distinguish. Pichpich (talk) 16:37, 28 June 2013 (UTC)

Events page

Hey :)

Can someone please help me move meta:Wikidata/Events to Wikidata:Events please? I am a bit lost with the translations tbh and it is a page that should now be here instead of on meta. (A redirect should be left though as the other page is still all over the place.) --Lydia Pintscher (WMDE) (talk) 13:00, 28 June 2013 (UTC)

 Done. --Stryn (talk) 14:33, 28 June 2013 (UTC)

Thanks a lot! --Lydia Pintscher (WMDE) (talk) 14:34, 28 June 2013 (UTC)

Wikisource support

I've made a proposal about how Wikidata should support Wikisource. Feel free to discuss it on the talk page. Tpt (talk) 15:27, 28 June 2013 (UTC)

Links to subsections

I must have missed it, but can anyone please tell me what is to be done about interwiki links to subsections? As far as I've seen the work of Addbot (and others), these links are left on the page. -- Edinwiki (talk) 10:24, 26 June 2013 (UTC)

Links to sections on a page must remain on wikipedia articles as they do not currently belong on Wikidata! :) ·addshore· ^{talk to me!} 10:34, 26 June 2013 (UTC)

Are there any plans to include them on Wikidata? -- Edinwiki (talk) 11:15, 26 June 2013 (UTC)

As far as I know there are not any current plans to include them. Sitelinks on wikidata currently should only link between whole pages on various wikipedias. Sections may be something to discuss further, personally I know of many instances where sections are part of an interwiki link between sites. The question is should various wikipedias try to turn these into articles in their own right, or should wikidata come up with a way to allow links to sections. ·addshore· ^{talk to me!} 22:50, 26 June 2013 (UTC)

Subsections are unlikely ever to be added. There is support in the community for redirects to help fix what is called the "Bonnie and Clyde" problem (where we must have an item on both, an item on one, and an item on the other), which would allow wikis which do not have articles on the singles, but do have redirects, to link to the items which have the singles. --Izno (talk) 00:03, 27 June 2013 (UTC)

That seems to be a nice workaround. Is there any task force or some project group working on this? -- Edinwiki (talk) 12:54, 29 June 2013 (UTC)

issue / edition / episode

I'd like to start a property proposal for time statements in fictional events. This property should be used for any kind of publication: books, newspapers, magazines, tv series, etc. But I can't find a generic word, as 'issue' is only for newspaper, 'edition' for books and 'episode' for tv series - I believe. Can someone tell me a word which fits for all kind of publications? So I can propose a new property "<starting at #Word#> 29" / "<ending at #Word#"> 31". --Nightwish62 (talk) 21:10, 28 June 2013 (UTC)

The used word in one specific language doesn't really matter. Lots of properties cannot be properly described with one word in many languages. Just give an explanation of the intended use, preferably with good examples, and then – when or if the proposal – is accepted, labels as good as possible must be found for all languages. The label in English shouldn't matter for the discussion of the proposal. Byrial (talk) 21:43, 28 June 2013 (UTC)

Changing property of state Washington

It seems that the item for the Washington state is using property P158 for the seal image, while all other states are using P94. Is there any reason why this is the case? Can otherwise someone with sufficient rights please remove this property and put the other one there instead? Thanks. -- Edinwiki (talk) 12:51, 29 June 2013 (UTC)

It should be removable by anybody, as it is currently under no form of protection, but I think seal image (P158) looks like a better fit than coat of arms image (P94) because the images are seal images and not coat of arms images. TCN7JM 12:57, 29 June 2013 (UTC)

Thanks! I didn't yet have the opportunity to add or delete these properties to items and thought it was only possible for someone with enough rights. There are other states that also have seal images under property coat of arms image (P94), so I have changed it to keep it consistent. -- Edinwiki (talk) 14:40, 29 June 2013 (UTC)

'Edit links' script

The script which adds interwiki when click 'Edit links' button in article works not correct. For example: we have items Q3077975 and Q12824675 about one town. The second contains one interwiki to Uzbek language. And when I click 'Edit links' in uz:Kegeyli and add iwiki script removes uz-iwiki from Q12824675 and adds it to Q3077975. And item Q12824675 after these actions leave empty. I am experienced user and know that it should be deleted, so I go to my contributions, find empty items and nominate them for deletions. But newbies do not know about this and they leave empty items not deleted (like this - I found it and nominate for deletion today, but it stayed empty during a week). Maybe this script should be improved?--Ahonc (talk) 13:11, 29 June 2013 (UTC)

Please see: #Prevent_Wikidata_from_removing_iws_without_telling_the_user - Hoo man (talk) 14:03, 29 June 2013 (UTC)

I have deleted Q12824675. TCN7JM 14:05, 29 June 2013 (UTC)

How to handle new pages?

Hi everyone, not sure if this is brought up already: How to handle new pages being created at the Wikipedia's? We have batch imported most existing pages, but of course new pages get created on a daily basis. How are we going to keep up with this? I would propose to do this with a bot keeping an eye on the newly created pages. For every real page (not redirect):

1. Does the page have an item? If so, we're done
2. Does the page contain interlanguage links? If these are valid, an item is found and no conflicts: Link to the item and we're done
3. For the pages which don't have an item and no interlanguage links we should probably have a period of 7 (?) days before creating a new item. This gives users the time to add a link.

Is this the right approach? This could of course be more detailed, for example with reporting of pages that are in a conflicted state or automagically merging two items, but that's something we can always add on later. Is someone willing to work on this or maybe already has the code? It would be nice to have this in Pywikipedia so we can have multiple bots working on this in different languages. Multichill (talk) 14:31, 15 June 2013 (UTC)

I definitely agree that some time should spent before going and creating an item for a new page. But I'd suggest 8 days instead of 7. Here's my reasoning: We don't want to create items for WP:PRODed pages, so I'm suggesting 1 day to tag a PROD and 7 days for it to be deleted (or not) should pass before the item is created here. Needless to say, CSDs would be deleted in that timespan, so they would also not be imported here. I'd also say that human editors should be allowed to create items for newer pages at their discretion.

@Multichill, the reason I'm not mentioning anything about giving the creators of pages time to create items is because I just had a look Special:NewPages on ENWP, and I'd say 1/4 to 1/3 of the users creating pages were newbies, meaning they would be unlikely to know (how) to create an item on Wikidata. --Jakob ^{Scream about} _{the things I've broken} 15:26, 15 June 2013 (UTC)

We should have an item creation wizard that looks for existing items and assists people with filling in necessary information. The wizard should only create the item after all the steps are completed (Similar to commons-upload-wizard). The quick creation should be hidden from users until they created e.g. 25 items. --Tobias1984 (talk) 15:33, 15 June 2013 (UTC)

Time for deletion is important yes, for the Dutch Wikipedia this is 14 days so this should probably be decided on a per Wikipedia basis.

I don't expect newbies to link up their pages, but others might be monitoring it. Multichill (talk) 16:21, 15 June 2013 (UTC)

Waiting long enough (whatever that means on each local Wikipedia) makes perfect sense. Another simple idea is to avoid creating an item for an article that is currently part of a deletion process (whatever those processes are on each local Wikipedia). Pichpich (talk) 20:02, 15 June 2013 (UTC)

Some ideas:

• auto-notify page creator if the page doesn't have a linked item after 3-4 days
• auto-link persons with same name and birth/death dates
• Real-Time Unlinked Pages (JS tool?) --Ricordisamoa 03:13, 16 June 2013 (UTC)

I've been moving/merging a lot of items that has been batch imported by bots from ms.wp. So I cannot support any proposal that mass add more one-interwiki items. They do not benefit Wikipedia at all. If there are ways that articles can be associated automatically, by all means do so. For others, I'd suggest a bot-maintained list similiar to Special:UnconnectedPages, but only for new articles. Let each project choose what to do with the list. Aurora (talk) 02:41, 21 June 2013 (UTC)

I raised a similar issue to this in IRC today. As I see it bots such as Sk!dbot are creating many items that simply have a single interwiki link, this links the article to wikidata and to an item that contains no extra information. In my eyes this is quite pointless. May of the items that are created by Sk!dbot I see on RFD a few days after creation as they no longer meet WD:N as their only site link has been deleted due to the article being deleted. I think further discussion is needed on the above issue, the result would hopefully be less items being created and deleted meaning less work for admins and users alike. My initial idea was to change WD:N's at least one valid sitelink to at least two valid sitelinks. Along with the other 3 criteria of wd:N this could solve the above problem. Thoughts? ·addshore· ^{talk to me!} 23:09, 25 June 2013 (UTC)

 Strong oppose otherwise the mass of items at Wikidata:Roads task force/Canada would not be notable. --Rschen7754 23:10, 25 June 2013 (UTC)

I feel as if WD:N should take items similar to those that you have linked to into account. They are not simply a site link as I have described above (or the way I intended to describe the case). After clicking on a few random links from Wikidata:Roads task force/Canada I can see that they hold more data that a single site link (ie. labels in multiple languages) ·addshore· ^{talk to me!} 23:16, 25 June 2013 (UTC)

Thinking about this further I imagine my proposal in a way would be cancelled out by clearly identifiable conceptual or material entity anyway! Generally if there is a site link it also meets this criteria! Perhaps scrap my proposal, more thinking on my part is needed! :) ·addshore· ^{talk to me!} 23:18, 25 June 2013 (UTC)

@Jakob: Makes sense to have a backup time and detection if a page is nominated for deletion. Should be in there

@Aurora: For phase1 (interwiki's) yes, but for phase2 (infoboxes) it makes sense to have them. It's much easier for other languages to start an article about a subject when the infobox data is already in Wikidata.

Started playing with this on the Dutch Wikipedia. I'm not creating new items yet, just replacing old style interwiki links with a link to Wikidata right now. Will publish the bot in Pywikipedia so others can decide to run it in their homewiki too. Multichill (talk) 13:32, 30 June 2013 (UTC)

Worklists and contribute page

Hey :)

I was sitting down together with someone who was really enthusiastic about Wikidata yesterday. He really wanted to get started and help with the project but was lost. The feedback he gave me was that Wikidata:Contribute should be linked a lot more prominently and be updated and extended. Additionally he was looking for tasks he could do that were immediately useful to the community and couldn't find those. I then showed him the reports Byrial for example is creating and those were exactly what he was looking for but couldn't find. So those should probably also be linked more prominently and better explained for new-comers.

Hope that is useful for you. --Lydia Pintscher (WMDE) (talk) 13:07, 28 June 2013 (UTC)

I added a few more suggestions in the "Contribute..." section of the main page (English & French) readily usable for near newcomers, I believe - LaddΩ chat ;) 20:56, 29 June 2013 (UTC)

"old" links to wikis in other languages overlay the new link system created with editor

If there are language links at the end of the lemma e.g.: "[[de:XXX]]" this link seems to overlay the new links! Can somebody solve this? Can't we inform every wikipedian by mail on his/her/its user site that one shouldn't use the old inner wiki language links any more (I for one didn't know but found out some days ago and - at first sight - didn't see the "edit"-button below the languages?!--Dudy001 (talk) 16:07, 29 June 2013 (UTC)

Hi there! If you are talking about other wikipedia sites the links are being removed from the article text as the links get added to wikidata. There have been several noticed about the change in interwiki links on sites already! ·addshore· ^{talk to me!} 16:21, 29 June 2013 (UTC)

But that wasn't the case! How do you prevent wikipedians to add "old" links? - which overlay the new links created with the editor. As I checked the Chinese "兵部" (Ministry of war) link to german wiki I didn't get german "Kriegsministerium" but "Ministerium für öffentliche Arbeiten" (Ministry for public works) but on the german page the backlink was again to Ministry of war instead of "工部" (public work). I edited the german lemma and deleted the "old" links at the bottom. And tried the editor but it striked and didn't want to add the correct link for "Ministry of war". The German "Kriegministerium" had editor links to Česky, Jo 日本語, 한국어, Українська, 粵語. So I checked the englisch "Ministry of war" and there were links for Español, Tiếng Việt (or sth like that). I thought best is to eliminate the editor language links on the english "Ministry of War" and add them again (english included) on the german "Kriegsministerium" page (because there were more languages). That is to say: the editor has problems to add new links if edited links already exist on other pages on other wikis which do not overlap i.e. form an own group of edited links. (Despite this the "Ministry of War" has a link for ukranian which seems to link to the "KOREAN Ministry of War" but I left this as it is because I don't know ukranian.)--Dudy001 (talk) 16:52, 29 June 2013 (UTC)

The unfortunate fact is that some wikis will have certain editors on certain articles who choose to reject the central links in favor of their own preferred links. There's nothing we can do about it; the system was design that way to allow users to override our links. --Izno (talk) 21:21, 29 June 2013 (UTC)

the best way to currently deal with this is to have bots monitor the wikipedia sites for these links and migrate them to Wikidata or flag them up (which is currently being done but is might delayed). I will try to stream line this a bit! ·addshore· ^{talk to me!} 08:50, 30 June 2013 (UTC)

sexual orientation

Hi, I think I need a third party opinion in a discussion User_talk:Dexbot#sexual orientation a user says I have to remove all of imported sexual orientation that my bot added. I think working on a list (this list) and replacing more reliable source is a better option than removing. Some of them are really obvious like w:Adam Lambert, w:Chris Colfer, w:Ellen DeGeneres and so many others. (In my opinion) It's some kind of homophobia, why people are making a big deal of being gay? Amir (talk) 21:28, 29 June 2013 (UTC)

Since I'm the one objecting to this, I'd like to state that I'm really pissed (and I'll refrain from using stronger words) about the suggestion that I'm doing this because I'm homophobic. How do you not understand that sexual orientation can be and often is a private matter and still a potentially contentious one despite recent progress? There's a Wikimedia Board resolution on dealing with biographies (or in our case items) about living people that requires projects to be particularly careful in these cases. Blindly importing statements from an unreliable source such as Wikipedia is not being careful. The counter-argument that the bot is correct in most cases is obviously irrelevant: it's not how many we get right, it's how many we get wrong. It is true that some of the people on this list are openly gay and have been for some time. Well that's good news: when statements are obvious, they're easy to source. So source them. Pichpich (talk) 01:31, 30 June 2013 (UTC)

There is no problem to import data from en: Pyb (talk) 12:44, 30 June 2013 (UTC)

Can you explain how that squares with the board resolution and the sourcing requirements of sexual orientation (P91)? Pichpich (talk) 14:19, 30 June 2013 (UTC)

You should discuss on en: if you have a problem with this category. Pyb (talk) 16:57, 30 June 2013 (UTC)

Seriously, you're not even reading what I write. I don't have a problem with the existence of this category, I don't have a problem with the existence of this property and if there's any doubt about this, I don't have a problem with gay people. I have a problem with poorly referenced statements about biographies of living people, I have a problem with bot operators that don't care about Wikimedia Board resolutions and bot operators who ignore the very explicit sourcing requirements written in the very definition of a property. Pichpich (talk) 19:21, 30 June 2013 (UTC)

What I'm trying to say is sexual orientation is more like gender (sex), it's a trivial property and when you don't want to hide it it becomes really like obvious to people when you marry person of your own sex it's obvious that marking you as "gay" won't breach your privacy and as one of my friends said before, marking English Wikipedia unreliable source and not letting import data from this what-we-have-made wiki just kill this great project in its infancy Amir (talk) 16:15, 30 June 2013 (UTC)

Your personal opinion that sexual orientation should not matter doesn't mean that LGBT people want their sexual orientation to be public. I fully agree that being gay is ok and that saying "I'm gay" should be no different than saying "I was born a Friday" or "I'm allergic to guava jelly". But that's not the reality faced by LGBT people. It's not called "coming out" for nothing: the vast majority of LGBT people start by hiding their sexual orientation because the social pressures are still enormous even in Western democracies. Same-sex marriage is a reality in maybe 10% of the world but it's still criminalized in a larger portion of the world and even in countries where it's legal and widely accepted, being gay can prevent you from holding certain jobs or positions. For many people, being openly gay means being estranged from family. So no, sexual orientation is not a trivial bit of information and in particular it is very much a private matter. Pichpich (talk) 19:21, 30 June 2013 (UTC)

I criticized your action and called it homophobic not you (and It's different) and I think you don't need show your support for LGBT community (really thank you but It's not necessary in this topic), what actually I meant is when people are usually don't care about these things now (being gay doesn't matter for them) I think BLP policy of English Wikipedia and controlling of our partners in English Wikipedia is enough for us, if we can't trust them, we can't made any progress. if we have a board resolution, they had it too and their filter is enough for us. about crime and other things If we want to see things just statistically as you told Chinese should use as international language! and I don't say it's very trivial but after coming out yeah It is Amir (talk) 22:01, 30 June 2013 (UTC)

• First of all, accusing a user of homophobia (or the general actions of them) isn't a good way of developing discussion on Wikidata. Now, onto the specific case. Per numerous discussions previously, a person's sexual orientation on Wikidata can only be placed if they have explicitly stated it themselves and it can be sourced here on Wikidata to that effect. Pichpich is correct in their reasoning, and the ultimate idea behind this citation requirement is to conform with WMF's policy on biographies of living persons. If a bot is importing info from en, per previous discussions it should be acceptable, but it should also have a reference here on Wikidata to confirm that. The fact that the English Wikipedia uses that info isn't reference enough. Ajraddatz (Talk) 21:51, 30 June 2013 (UTC)

  Whoops, forgot to actually say what I wanted to here. The statements should either be removed, or a source added. Ajraddatz (Talk) 21:54, 30 June 2013 (UTC)

our big dispute is I should remove statements and after finding reliable source I should bring back the statement or It's better to make a list and change references from English WP to a more reliable source gradually (I'm not god and I've a life), I say the latter, the other person says the former Amir (talk) 22:08, 30 June 2013 (UTC)

The statement should be removed until there is a reliable source here. That's the requirement of the property, and of the foundation's BLP rules. Ajraddatz (Talk) 22:12, 30 June 2013 (UTC)